ファクトリパターン-CreateInstanceが静的かどうか。
これはファクトリーパターンについてです。私は少し混乱しています。
createInstance()メソッドが静的である実装と、静的ではない一部の実装を見ました。
「スタイル」や「味」に依存する人もいれば、そうでない人もいます。ギャングオブフォーによれば、ウィキペディアはそれが非静的であるべきだと言っており、 http://www.dofactory.com/Patterns/PatternFactory.aspx も非静的であるべきだと言っています。
私の質問は、静的な方法で実装されている場合、スタイルとテイストに依存しますか、それともファクトリーパターンに違反しますか？何が正しい？
静的メソッドはパターンに違反しませんが、他の多くのオブジェクト指向のプラクティス（1つの例として、制御の反転+依存性注入）に反するため、インスタンスを使用する方が適切です。
編集：
私はこの答えのバッジを取得しましたが、それを読んだとき、自分の目を信じることができませんでした。 GoFファクトリのメソッドパターンについて厳密に説明するのは誤りであり、修正する必要があります。
型のインスタンスを作成するための静的CreateInstanceメソッドを持つことができます-それについて何も問題はありません-人々はしばしばそれをファクトリーメソッドと呼びますが、それはファクトリーメソッドと呼ばれるものではありませんパターン。何らかの条件に応じて異なるタイプのインスタンスを作成するためにこのメソッドにロジックを配置し始めると、GoFによって記述されたファクトリメソッドパターンが実際に必要になる場合があります。
GoFファクトリーメソッドパターンのポイントは、CreateInstance内の条件付きロジックを継承とポリモーフィズムに置き換えることです。したがって、これを静的にすることはできません。ファクトリメソッドはインスタンスメソッドであり、さらに仮想メソッドです。通常、基本タイプには抽象CreateInstanceがあり、条件付きロジックは継承ツリーに置き換えられます。継承ツリーでは、各サブタイプがCreateInstanceをオーバーライドし、そのサブタイプの特定の製品のみを作成します。
私は「インスタンスと静的」を好みの問題として分類することを非常にためらっています。この種のことは、お気に入りの色のように美的であること、またはパスカルケースと比較してキャメルケースのように美的であることを意味します。
インスタンスと静的との比較は、トレードオフの問題です。任意の種類のインスタンスメンバーを使用すると、インスタンスとインスタンスメンバーがある場合にインターフェイスを実装し、他のクラスから継承できるため、ポリモーフィズムのすべての利点を得ることができます。静力学では、これらの利点は得られません。一般に、静的とインスタンスは、事前の単純さとダウンストリームの単純さのトレードオフです。静的はグローバルにアクセス可能であり、「いつこれを誰がインスタンス化する必要があるか」などを考慮する必要がないため、簡単です。アクセサー/ミューテーターまたはコンストラクターでそれらを渡す必要はありません。また、API looksをよりクリーンにします。これにより、事前の推論が容易になります。ただし、メンテナンスや将来の実装が難しくなります。
静的メソッド（ケースのファクトリメソッドなど）があり、後で特定の状況で別の方法で動作させたい場合は、一種の不便です。 2つ目の方法を作成し、変更したい機能を除いた機能をコピーして貼り付け、クライアントにそれを理解させる必要があります。または、さらに悪いことに、グローバル変数を公開し、メソッドの使用前と使用後にクライアントがこれを設定し、グローバルがメソッドに動作方法を指示します。
インスタンスルートを前もって行っていれば、これは簡単です。最初のファクトリメソッドを継承してオーバーライドし、新しい機能が必要な場合に派生クラスを提供するだけです。クライアントコードに追加の負荷をかけず、既存のクラスにほとんど変更を加えません（オープン/クローズの原則）。
私のアドバイスは、将来あなたや他のメンテナに好意を示し、インスタンス実装を使用することです。ギャングオブフォーや他の誰かが何を望んだり好んだりするかは問題ではありません-コードの腐敗に直面したときのあなた自身の正気の問題です。
abstract factoryその後、インスタンスレベルは正常です。また、インスタンスレベルの機能は、staticレベルよりもモックおよび単体テストが簡単になる傾向があります