直接オブジェクト構築の代わりにファクトリクラスを使用する必要があるのはなぜですか？

GitHubとCodePlexでいくつかのС＃とJavaクラスライブラリプロジェクトの歴史を見てきました。オブジェクトの直接インスタンス化とは対照的に、ファクトリクラスに切り替える傾向が見られます。

なぜファクトリクラスを広範囲に使用する必要があるのですか？クラスのパブリックコンストラクターを呼び出すことで、昔ながらの方法でオブジェクトが作成される、非常に優れたライブラリがあります。最後のコミットで、著者は数千のクラスのすべてのパブリックコンストラクターCreateXXXをすぐに内部に変更し、クラスの内部コンストラクターを呼び出して新しいオブジェクトを返すだけの数千の静的メソッドを持つ1つの巨大なファクトリークラスを作成しました。外部プロジェクトAPIは壊れており、よくできています。

なぜこのような変更が役立つのでしょうか？このようにリファクタリングのポイントは何ですか？パブリッククラスコンストラクターの呼び出しを静的ファクトリメソッド呼び出しに置き換えることの利点は何ですか？

いつパブリックコンストラクターを使用する必要があり、いつファクトリーを使用する必要がありますか？

ファクトリクラスは、プロジェクトがSOLIDの原則により厳密に従うことができるため、しばしば実装されます。特に、インターフェイスの分離と依存関係の逆転の原則。

ファクトリーとインターフェースは、はるかに長期的な柔軟性を可能にします。これにより、より分離された、したがってよりテスト可能な設計が可能になります。このパスをたどる理由の完全なリストは次のとおりです。

• Inversion of Control（IoC）コンテナを簡単に導入できます
• インターフェイスをモックできるため、コードのテストが容易になります
• アプリケーションを変更するときに柔軟性が高まります（つまり、依存コードを変更せずに新しい実装を作成できます）

この状況を考慮してください。

アセンブリA（->は依存することを意味します）：

Class A -> Class B
Class A -> Class C
Class B -> Class D

クラスBをアセンブリAに依存するアセンブリBに移動します。これらの具体的な依存関係があるため、クラス階層全体のほとんどを移動する必要があります。インターフェイスを使用すると、痛みの多くを回避できます。

アセンブリA：

Class A -> Interface IB
Class A -> Interface IC
Class B -> Interface IB
Class C -> Interface IC
Class B -> Interface ID
Class D -> Interface ID

これで、クラスBをアセンブリBに移動しても、まったく苦労することはありません。アセンブリAのインターフェイスに依存します。

IoCコンテナーを使用して依存関係を解決すると、さらに柔軟性が高まります。クラスの依存関係を変更するたびに、コンストラクターの各呼び出しを更新する必要はありません。

インターフェイス分離の原則と依存関係の反転の原則に従うことにより、柔軟性の高い分離アプリケーションを構築できます。これらのタイプのアプリケーションのいずれかに取り組んだら、newキーワードの使用に戻ることは二度とありません。

同様whatsisname私はこれがの場合であると考えて、言ったカーゴ・カルトのソフトウェア設計。ファクトリー、特に抽象類は、モジュールがクラスの複数のインスタンスを作成し、このモジュールのユーザーに作成するタイプを指定できるようにする場合にのみ使用できます。この要件は実際には非常にまれです。ほとんどの場合、1つのインスタンスが必要なだけで、明示的なファクトリを作成する代わりに、そのインスタンスを直接渡すことができるからです。

実は、工場（およびシングルトン）は非常に簡単に実装できるため、必要のない場所でも多くの人が使用します。プログラマーが「このコードで使用する必要があるデザインパターンは何ですか？」彼の頭に浮かぶのはファクトリーです。

「たぶん、いつか、これらのクラスを異なる方法で作成する必要がある」ことを念頭に置いて、多くの工場が作成されます。これはYAGNIの明らかな違反です。

また、IoCは単なるファクトリーであるため、IoCフレームワークを導入すると工場は廃止されます。また、多くのIoCフレームワークは、特定のファクトリーの実装を作成できます。

また、CreateXXXコンストラクターのみを呼び出すメソッドを持つ巨大な静的クラスを作成するというデザインパターンはありません。そして、特にファクトリ（または抽象ファクトリ）と呼ばれていません。

Factoryパターンの流行は、「new」キーワードの使用は不適切であり、すべてのコスト（または最小集中化）。これは、単一責任原則（SOLIDの「S」）、および依存関係反転原則（「D」）の非常に厳密な解釈に由来しています。簡単に言えば、SRPは理想的にはコードオブジェクトには「変更する理由」が1つだけあるべきだと言っています。「変更の理由」がそのオブジェクトの中心的な目的であり、コードベースでの「責任」であり、コードの変更を必要とするものはすべて、そのクラスファイルを開く必要はありません。DIPはさらにシンプルです。コードオブジェクトが別の具体的なオブジェクトに依存することはありません。

適切な例として、「new」とパブリックコンストラクターを使用して、呼び出し元のコードを特定の具象クラスの特定の構築メソッドに結合しています。コードは、クラスMyFooObjectが存在し、文字列とintを受け取るコンストラクタを持っていることを知る必要があります。そのコンストラクターがさらに情報を必要とする場合は、コンストラクターのすべての使用法を更新して、現在記述しているものを含むその情報を渡す必要があるため、渡すために有効なものが必要です。それを取得するために変更する（消費オブジェクトに責任を追加する）。さらに、コードベースでMyFooObjectがBetterFooObjectに置き換えられた場合、古いクラスではなく新しいオブジェクトを作成するために、古いクラスの使用法をすべて変更する必要があります。

したがって、代わりに、MyFooObjectのすべてのコンシューマーは、MyFooObjectを含むクラスを実装する動作を定義する「IFooObject」に直接依存する必要があります。現在、IFooObjectsのコンシューマーは、IFooObjectを構築することはできません（特定の具体的なクラスが必要ないIFooObjectであるという知識がないため）。外部から、状況に応じて正しいIFooObjectを作成する方法を知る責任がある別のオブジェクトによって。このオブジェクトは、この用語では通常ファクトリと呼ばれます。

さて、ここで理論が現実と出会うところです。オブジェクトを常にすべての種類の変更に対して閉じることはできません。代表的な例として、IFooObjectはコードベース内の追加のコードオブジェクトになり、コンシューマーまたはIFooObjectsの実装に必要なインターフェイスが変更されるたびに変更する必要があります。これにより、この抽象化を介してオブジェクトが相互にやり取りする方法を変更することに伴う新しいレベルの複雑さが導入されます。さらに、インターフェース自体が新しいインターフェースに置き換えられた場合、コンシューマーはさらに変更する必要があり、さらに深くする必要があります。

優れたコーダーは、デザインを分析し、特定の方法で変更する必要がある可能性が非常に高い場所を見つけて、より寛容になるようにリファクタリングすることで、YAGNI（「あなたは必要ない」）とSOLIDのバランスを取る方法を知っていますその場合、「あなたはそれを必要としている」からです。

コンストラクタは、短くシンプルなコードが含まれていれば問題ありません。

初期化がいくつかの変数をフィールドに割り当てる以上の場合、ファクトリは意味をなします。利点のいくつかを次に示します。

• 長くて複雑なコードは、専用クラス（ファクトリー）でより理にかなっています。多数の静的メソッドを呼び出すコンストラクターに同じコードを配置すると、メインクラスが汚染されます。

• 一部の言語および場合によっては、コンストラクターに例外をスローすることは、バグを引き起こす可能性があるため、本当に悪い考えです。

• コンストラクターを呼び出すとき、呼び出し元であるユーザーは、作成するインスタンスの正確なタイプを知る必要があります。これは常にそうではありません（aとして、それを供給するためにFeederを構築する必要がありAnimalます;それがa Dogかa かは気にしませんCat）。

インターフェイスを操作する場合、実際の実装から独立したままでかまいません。多くの異なる実装の1つをインスタンス化するように、ファクトリーを構成できます（プロパティー、パラメーター、またはその他の方法を使用）。

簡単な例：デバイスと通信したいが、それがイーサネット、COM、USBのいずれを経由するかわからない場合。1つのインターフェースと3つの実装を定義します。実行時に、必要なメソッドを選択すると、ファクトリが適切な実装を提供します。

頻繁に使用する...

これは、Java / C＃のモジュールシステムの制限の症状です。

原則として、同じコンストラクターとメソッドシグネチャを持つクラスの実装を別の実装に交換できない理由はありません。これを可能にする言語があります。ただし、JavaおよびC＃では、すべてのクラスに一意の識別子（完全修飾名）が必要であり、クライアントコードには最終的に依存関係がハードコードされます。

あなたはできる種類のものがように、ファイルシステムおよびコンパイラオプションをいじることでこれを回避com.example.Foo別のファイルにマップが、これは驚くべきことであり、直感的です。あなたがそうする場合でも、あなたのコードがされ、まだクラスの唯一の実装に縛ら。すなわち、クラスFooに依存するクラスを記述する場合、コンパイル時にのMySet実装を選択できますが、の2つの異なる実装を使用してをMySetインスタンス化することはできません。FooMySet

この残念な設計上の決定により、人々はinterfacesを不必要に使用して、後で何か別の実装が必要になる可能性や、単体テストを容易にするためにコードを将来的に保証します。これは常に実行可能ではありません。クラスの2つのインスタンスのプライベートフィールドを参照するメソッドがある場合、それらをインターフェイスに実装することはできません。そのため、たとえば、unionJavaのSetインターフェースには表示されません。それでも、数値型とコレクション以外では、バイナリメソッドは一般的ではないため、通常はこれで十分です。

もちろん、呼び出すnew Foo(...)場合はまだclassに依存しているため、クラスでインターフェイスを直接インスタンス化できるようにするにはファクトリが必要です。ただし、通常はコンストラクターでインスタンスを受け入れ、使用する実装を他の人に決定させる方が良いでしょう。

インターフェイスとファクトリーでコードベースを肥大化する価値があるかどうかを判断するのはあなた次第です。一方、問題のクラスがコードベースの内部にある場合、将来別のクラスまたはインターフェイスを使用するようにコードをリファクタリングするのは簡単です。状況が発生した場合は、YAGNIを呼び出して後でリファクタリングできます。ただし、クラスが公開したライブラリのパブリックAPIの一部である場合、クライアントコードを修正するオプションはありません。を使用せずinterface、後で複数の実装が必要な場合は、岩と難しい場所の間で立ち往生します。

私の意見では、彼らは単純なファクトリを使用しているだけです。これは適切なデザインパターンではなく、抽象ファクトリやファクトリメソッドと混同しないでください。

そして、彼らは「何千ものCreateXXX静的メソッドを備えた巨大なファブリッククラス」を作成したので、それはアンチパターンに聞こえます（多分、神のクラスでしょうか？）。

場合によっては、Simple Factoryおよび静的作成メソッド（外部クラスを必要としない）が役立つと思います。たとえば、オブジェクトの構築に、他のオブジェクトのインスタンス化などのさまざまな手順が必要な場合（たとえば、合成を優先する場合）。

私はそれをファクトリーと呼ぶことさえしませんが、接尾辞「Factory」を持つランダムなクラスにカプセル化されたメソッドの束だけです。

ライブラリのユーザーとして、ライブラリにファクトリメソッドがある場合は、それらを使用する必要があります。ファクトリメソッドは、ライブラリの作成者に、コードに影響を与えずに特定の変更を行う柔軟性を提供すると仮定します。たとえば、ファクトリメソッドでサブクラスのインスタンスを返す場合がありますが、単純なコンストラクターでは機能しません。

ライブラリの作成者として、自分でその柔軟性を使用する場合は、ファクトリメソッドを使用します。

あなたが説明する場合、コンストラクタをファクトリメソッドに置き換えることは無意味であるという印象を持っているようです。関係者全員にとって確かに苦痛でした。非常に正当な理由がない限り、ライブラリはAPIから何も削除すべきではありません。そのため、ファクトリメソッドを追加した場合、ファクトリメソッドがそのコンストラクタを呼び出さず、プレーンコンストラクタを使用したコードの動作が本来よりも劣るまで、既存のコンストラクタを使用可能にしたまま、おそらく非推奨にしました。あなたの印象は非常に正しいかもしれません。

これはScalaと関数型プログラミングの時代には時代遅れになったようです。機能の強固な基盤は、膨大な数のクラスに取って代わります。

また{{、ファクトリを使用する場合、Javaのdouble はもう機能しません。

someFunction(new someObject() {{
    setSomeParam(...);
    etc..
}})

これにより、匿名クラスを作成してカスタマイズできます。

時間空間のジレンマでは、高速CPUのおかげで時間係数が非常に小さくなり、機能プログラミングによりスペースの縮小が可能になり、コードサイズが実用的になりました。