Karl SeguinのFoundations of Programmingには、工場パターンの使用に関する小さなセクションがあります。彼は "あなたはコンストラクタのオーバーロードで同じ機能を果たすことができる"と述べることでこの節を閉じますが、いつ、あるいは、いつ、なぜですか？オーバーロードされたコンストラクタではなく、ファクトリパターンを使用してオブジェクトをインスタンス化するのはいつより理にかなっていますか？
したがって、オブジェクトをインスタンス化するためにオーバーロードされたコンストラクタではなく、ファクトリパターンを使用する方が適切なのはいつですか？
あなたは疎結合を持っているしたい場合は、その後だけで、自動車工場を呼び出すSUVの列挙に渡し、正しいクラスが返されることができて、その後工場は、より理にかなっています。あなたのアプリケーションは、あなたのニーズを満たす限り、実際に返されたクラスを気にしません。
ファクトリを引数として受け入れるオブジェクトも、作成メソッドの呼び出しを行います。 – JaredCacurak
ファクトリでは、いくつかの異なるサブクラスのうちの1つを構築する必要があります（呼び出し元には基本クラスについて知ってもらいたいが、サブクラスについては知りません）。また
、時折私の代わりにオーバーロードされたコンストラクタのクラスの静的メソッドを使用します別の静的メソッドは、同じパラメータ型を取る（したがって、コンストラクタだけでは、パラメータの種類に基づいて、オーバーロードできない場合）。ここでは不自然な例です：
Department
{
//static factory methods
public static Department createFromBoss(string bossName) { ... }
public static Department createFromLocation(string locationName) { ... }
}
私は工場が便利な状況が1つあります。私は、ビデオで動作するようにビデオエフェクトをインスタンス化する必要があります。ビデオの種類に応じて、ビデオエフェクトは異なる具体的なクラスを持ちます。
具体的なクラスをインスタンス化すると、後でインスタンス化コードを変更せずにビデオエフェクトを追加する機能が失われます。
ビデオエフェクトを追加するときは、適切な具象クラスを選択するためにファクトリを変更するだけです。
これは意味がありますか？
工場では、返されるタイプのサブタイプが生成されることがあります。あなたはコンストラクタでこれを行うことはできませんでしたが、工場では柔軟性があります。
Dependency Injectionを実行しているが、依存関係内で必要に応じて依存関係のインスタンスを作成する必要がある場合は、クラスファクトリにインターフェイスを挿入する方法もあります。ファクトリは、インタフェースまたは抽象クラスを返すことができます。これにより、柔軟性、テスト容易性、およびデカップリングがいくらか複雑になります。
確かに、一部の言語でFactory/Builderの種類がなくてもVirtual Constructionを実現することはできません（C++） –
私は彼の声明に同意しません。異なるコンストラクタは、コンストラクタを構築/初期化するさまざまな方法がある場合に使用されます。ファクトリパターンは、初期化の基準によって異なるオブジェクトを作成する場合に使用します。
多型をメソッドを使用して実装する場合は、ファクトリパターンを使用してサブクラスを使用する方が理にかなっています。
Department b = Department.createFromBoss();
Department l = Department.createFromLocation();
の両方が、その後、部門の異なるサブクラスを返す場合は、
例えばb.Close()
と
l.Close()
は（あなたがしようとすると閉じる必要があった場合メシエされるであろう、さまざまなアクションを取ることができます）コンストラクタのオーバーロードによって単一のオブジェクト。
カールの防衛では、彼はファクトリパターンが読みやすくすると言っていますが、彼は "腸"と "味"を決定要因として使います。 – JaredCacurak