1

これは、この Builder 実装で instanceof を取り除く方法に関するフォローアップ スレッドです。

このデザインにはまだいくつかの問題があります。新しいパラメータが導入されるたびに、新しい ConcereteParameter クラスを作成する必要があります。

それは問題ではありません。ただし、 CommandBuilder にもメソッドを追加する必要がありappend(ConcreteParameter)ます。そして、私はその依存関係があまり好きではありません。

要約する

  • コマンドはパラメーターで構成できます。すべてのコマンドが同じパラメーターを受け取るわけではありません。したがって、いくつかは無視する必要があります。コマンドに適用される場合 (この実装では、これはUnsupportedOperationException

  • 特定のクラスに適用できるパラメーターは、それらのクラスでは異なる方法で使用されます (FTPCommand と HTTPCommand のように、IpParameter を別の方法で使用する場合があります)。

  • 将来、新しいコマンドとパラメータが導入される可能性があります

更新 現在の実装worksです。しかし、約 30 個のパラメーターがある場合、パラメーターごとに個別のメソッドが必要になるのはやり過ぎではありませんか?

ある場合、これを達成するためのよりクリーンで柔軟な方法/パターンは何ですか?

4

2 に答える 2

1

あなたにとってのパラメーターとは何ですか? また、パラメーターの型とは何ですか? パラメータとして実際にさまざまな種類のオブジェクトがあり、それらに対してさまざまな操作を実行できる場合、それらを処理するためにさまざまなクラスが必要になることは避けられません。パラメータがコマンドの解釈方法のみが異なり、それ以外のほとんどがStringandIntegerまたは何でもある場合、可能な意味ごとに追加のクラスを用意するのは確かにやり過ぎです。そして、パラメーターがキーと値のペアの何らかの形式である場合、それらをそのように表現します。パラメーターの名前と値を含む単一のクラス (または妥当な値の型ごとに 1 つ) です。

上記を使用してパラメーターの型の数を減らすことができる場合は、実際のコマンド ビルドのリフレクションを検討することをお勧めします。@Parameterコマンドクラスのセッターメソッドを装飾するために使用する注釈を付けることができます。たとえば@Parameter void setIP(String)、コマンドが文字列パラメーターを受け入れ、それを IP アドレスとして解釈することを意味します。キーと値のパラメーターを使用する場合は、メソッド名からキーを派生させるか、アノテーションに値を追加するか、またはその両方を行うことができます。このようなフレームワークを使用すると、適切なセッターへのパラメーターの供給を処理する単一のコマンド ビルダーを持つことができます。

于 2012-08-03T11:07:37.213 に答える
0

受け入れられた答えがありますが、別のオプションに注意する必要があると思います.

a をコンテキスト オブジェクトとして使用しMap、コンテキストをexecuteコマンドのメソッドに渡します。Mapこのコマンドは、必要なパラメーターをby Stringから単純に引き出します。

public interface Command {
   public void execute(Map<String, Object> context);
}

class OneCommandImpl extends Command {
    public void execute(Map<String, Object> context) {
        context.get('p1');
        context.get('p2');
    }
}

このアプローチの利点は、単純であることと、リフレクションの必要がないことです。この 1 つのインターフェイスを使用して、任意の数の引数を必要とする任意のコマンドを作成できます。主な欠点は、マップ内の値の型が特定されていないことです。

于 2012-08-03T12:58:17.087 に答える