2

私はインターフェースIMessageと、次のようなさまざまなタイプのメッセージを作成するためのいくつかのメソッドを持つクラスを持っています。

class MessageService
{
    IMessage TypeAMessage(param 1, param 2)
    IMessage TypeBMessage(param 1, param 2, param 3, param 4)
    IMessage TypeCMessage(param 1, param 2, param 3)
    IMessage TypeDMessage(param 1)    
}

このクラスにこれらのメッセージを作成するためのすべての作業を行わせたくないので、指定されたタイプに応じて（メッセージTypeA、TypeB、TypeCなどのタイプに基づく列挙）MessageCreatorFactory を生成するに委任するだけです。IMessageCreator

interface IMessageCreator
{
     IMessage Create(MessageParams params);
}

IMessageCreatorだから私は：TypeAMessageCreator、、、TypeBMessageCreatorの4つTypeCMessageCreatorの実装を持っていますTypeDMessageCreator

MessageParamsタイプごとに異なるパラメーターが必要なため、4つの異なるパラメーターに対して4つのプロパティを含むオブジェクトを作成する必要がありましたが、それぞれで使用されるのは一部のみであるという事実を除いて、これで問題ありませんIMessageCreator。

これに代わるものはありますか？私が持っていたもう1つの考えは、Createメソッドのパラメーターとしてパラメーター配列を使用することでしたが、パラメーターが何であるかわからないため、これはさらに悪いようです。または、インターフェイスでCreateのオーバーロードをいくつか作成し、それらが特定の実装に適していない場合に例外をスローするようにします（つまり、より多くのパラメーターを必要とするメソッドを呼び出したため、他のオーバーロードの1つを呼び出す必要があります）。

これは大丈夫ですか？より良い解決策はありますか？

4

3 に答える 3

5

これは実際にはファクトリメソッドパターンの精神に違反しています。異なるタイプの構築に異なるパラメーターが必要な場合は、どのタイプが構築されているかを事前に呼び出し元に暗黙的に認識させることになります。これにより、このパターンの利点が完全になくなります。

たとえば、列挙型（TypeA、TypeB、TypeC）を指定している場合は、TypeAを直接作成することもできます。複数のサブクラスがTypeAを実装できるようにする場合は、TypeA専用のファクトリを作成します...

于 2010-04-02T16:13:24.807 に答える
0

私の意見では、IMessage Createのオーバーロードが4つある方が、MessageParamを含む1つのメソッドがあるよりもはるかに優れています。

作成者の実装でサポートされていないメソッドの例外をスローするだけです。

その結果、コードを再度開くと、おそらく1週間または1か月で大きなメリットが得られます。この実装は、現在の実装よりもわかりやすくなります

于 2010-04-02T16:11:32.380 に答える
0

TypeXMessageCreatorクラスが共通のインターフェースを実装する必要がある理由はわかりません。私は完全に取り除き、オブジェクトIMessageCreatorを作成するための4つの別々のファクトリを持っていIMessageます。

オブジェクトの作成にIMessageいくつかの共通ロジックが必要な場合は、そのロジックを別のクラスに配置して、ファクトリ内から使用できます。

継承はコードの再利用ではないことに注意してください。

于 2010-04-02T16:14:25.387 に答える