design-patterns - オブジェクトをインスタンス化するために、オーバーロードされたコンストラクターではなくファクトリ パターンを使用する方が理にかなっているのはどのような場合ですか?

Question

Karl Seguin のFoundations of Programmingには、ファクトリ パターンの使用に関する小さなセクションがあります。彼は「コンストラクターのオーバーロードで同じ機能を実現できる」と述べて一節を締めくくっていますが、時期や理由は示していません。

では、オブジェクトをインスタンス化するために、オーバーロードされたコンストラクターではなくファクトリ パターンを使用する方が理にかなっているのはいつでしょうか?

Answer 1

より疎結合にしたい場合は、ファクトリの方が理にかなっています。自動車ファクトリを呼び出して suv enum を渡すだけで、正しいクラスが返されるからです。アプリケーションは、ニーズを満たす限り、実際に返されたクラスを気にしません。

Answer 2

依存性注入を行っているが、依存関係内で必要に応じて依存関係のインスタンスを作成する必要がある場合、1 つのオプションは、クラス ファクトリへのインターフェイスを注入することです。ファクトリは、インターフェイスまたは抽象クラスを返すことができます。これにより、多少の複雑さを犠牲にして、柔軟性、テスト容易性、および分離が提供されます。

Answer 3

ファクトリにいくつかの異なる可能なサブクラスの 1 つを構築させたい場合にファクトリを使用します (また、呼び出し元に基本クラスについては知ってもらいたいが、サブクラスについては知らないようにしたい)。

---

また、異なる静的メソッドが同じパラメーターの型を取る場合 (したがって、パラメーターの型だけに基づいてコンストラクターをオーバーロードすることはできません) は、オーバーロードされたコンストラクターの代わりにクラスの静的メソッドを使用することがあります。これは不自然な例です:

Department
{
  //static factory methods
  public static Department createFromBoss(string bossName) { ... }
  public static Department createFromLocation(string locationName) { ... }
}

Answer 4

私は彼の発言に同意しません。コンストラクターの構築/初期化の方法が異なる場合は、異なるコンストラクターが使用されます。ファクトリ パターンは、初期化基準により、構築するオブジェクトが異なる場合に使用します。

Answer 5

ファクトリが、返される型のサブタイプを生成することがあります。コンストラクターではこれを行うことはできませんが、ファクトリには柔軟性があります。

Answer 6

また、メソッドを介してポリモーフィズムを実装する場合は、ChrisW が示したように、ファクトリ パターンを使用してサブクラスを使用する方が理にかなっています。もしも

Department b = Department.createFromBoss();
Department l = Department.createFromLocation();

どちらも Department の異なるサブクラスを返します。

b.Close()

と

l.Close()

たとえば、コンストラクターのオーバーロードを介して単一のオブジェクトを試行して Close() する必要がある場合、さまざまなアクションを実行できます。

Answer 7

ファクトリが役立つ状況が 1 つあります。ビデオで実行するには、ビデオ エフェクトをインスタンス化する必要があります。ビデオの種類に応じて、ビデオ エフェクトの具象クラスは異なります。

具象クラスをインスタンス化すると、後でインスタンス化コードを変更しなければビデオ エフェクトを追加できなくなります。

ビデオ エフェクトを追加するときは、ファクトリを変更して適切な具象クラスを選択するだけです。

これは理にかなっていますか？