静的ファクトリーとシングルトンとしてのファクトリー

私のコードのいくつかでは、次のような静的ファクトリーがあります。

public class SomeFactory {

    // Static class
    private SomeFactory() {...}

    public static Foo createFoo() {...}

    public static Foo createFooerFoo() {...}
}

コードのレビュー中に、これはシングルトンであることが提案され、注入されました。したがって、次のようになります。

public class SomeFactory {

    public SomeFactory() {}

    public Foo createFoo() {...}

    public Foo createFooerFoo() {...}
}

強調すべきいくつかのこと：

• 両方の工場はステートレスです。
• メソッド間の唯一の違いは、スコープ（インスタンスと静的）です。実装は同じです。
• Fooは、インターフェースを持たないBeanです。

静的にするための引数は次のとおりです。

• クラスはステートレスであるため、インスタンス化する必要はありません
• ファクトリをインスタンス化するよりも静的メソッドを呼び出す方が自然なようです

シングルトンとしてのファクトリの引数は次のとおりです。

• すべてを注入するのが良い
• 工場の無国籍にもかかわらず、注入によりテストが簡単になります（簡単にモックできます）
• 消費者をテストするとき、それはock笑されるべきです

どのメソッドも静的であってはならないことを示唆しているように見えるため、シングルトンアプローチにはいくつかの深刻な問題があります。また、ユーティリティをStringUtilsラップしてインジェクトする必要があることも示唆しているようですが、これはばかげているようです。最後に、ある時点で工場をモックする必要があることを意味しますが、これは正しくないと思われます。いつ工場をモックする必要があるのか​​考えられません。

コミュニティはどう思いますか？私はシングルトンアプローチが好きではありませんが、それに対してひどく強い議論を持っているようには見えません。

作成したオブジェクト型からファクトリを分離するのはなぜですか？

public class Foo {

    // Private constructor
    private Foo(...) {...}

    public static Foo of(...) { return new Foo(...); }
}

これは、ジョシュアブロッホが著書「Effective Java」の5ページにある彼のアイテム1として説明しているものです。Javaは、余分なクラスやシングルトンなどを追加しなくても十分に冗長です。別のファクトリクラスが理にかなっている場合もありますが、それらはほとんどありません。

コンストラクターとは異なり、Joshua BlochのItem 1を言い換えると、静的ファクトリーメソッドは次のことができます。

• 特定の種類のオブジェクト作成を説明できる名前を付けます（Blochは例としてprobablePrime（int、int、Random）を使用します）
• 既存のオブジェクトを返します（たとえば、flyweight）
• 元のクラスのサブタイプまたは実装するインターフェースを返します
• 冗長性を減らす（型パラメーターを指定する-たとえばBlochを参照）

短所：

• パブリックコンストラクターまたは保護されたコンストラクターのないクラスはサブクラス化できません（ただし、保護されたコンストラクターおよび/または項目16を使用できます：継承よりも合成を優先します）
• 静的ファクトリーメソッドは、他の静的メソッドから際立っていません（of（）またはvalueOf（）などの標準名を使用します）

本当に、Blochの本をコードレビュアーに渡して、2人がBlochのスタイルに同意できるかどうかを確認してください。

私の頭の中で、Javaの静的に関する問題のいくつかを次に示します。

• 静的メソッドは、OOPの「ルール」によって再生されません。クラスに特定の静的メソッドを強制的に実装することはできません（私の知る限り）。したがって、同じシグネチャを持つ同じ静的メソッドのセットを実装する複数のクラスを持つことはできません。だから、あなたはそれがやっていることのいずれかで立ち往生しています。静的クラスを実際にサブクラス化することもできません。ポリモーフィズムなどはありません

• メソッドはオブジェクトではないため、静的メソッドを渡すことはできず、使用することはできません（大量の定型コーディングを行わない限り）。ただし、それらにハードリンクされたコードを除きます。結合。（公平を期すために、これは単に静的な問題ではありません）。

• 静的フィールドはグローバルにかなり似ています

あなたは言った：

どのメソッドも静的であってはならないことを示唆しているように見えるため、シングルトンアプローチには重大な問題がいくつかあります。また、StringUtilsなどのユーティリティをラップして挿入する必要があることを示唆しているようですが、これはばかげているようです。最後に、ある時点で工場をモックする必要があることを意味しますが、これは正しくないと思われます。いつ工場をモックする必要があるのか​​考えられません。

それで私はあなたに尋ねたいと思うようになります：

• あなたの意見では、静的メソッドの利点は何ですか？
• それStringUtilsは正しく設計および実装されていると思いますか？
• なぜ工場をモックする必要がないと思いますか？

構築しているアプリケーションは、かなり複雑でないか、ライフサイクルの比較的早い段階にあると思います。あなたが静的の問題にまだ遭遇していなかったと私が考えることができる他の唯一のシナリオは、あなたのファクトリについて知っているコードの他の部分を1つか2つの場所に制限することができた場合です。

アプリケーションが進化し、場合によってはFooBar（Fooのサブクラス）を生成する必要があることを想像してください。今、あなたはあなたのことを知っているコード内のすべての場所SomeFactoryを調べてsomeCondition、SomeFactoryまたはを見て呼び出したりするロジックを書く必要がありSomeOtherFactoryます。実際、サンプルコードを見ると、それよりも悪いです。さまざまなFoosを作成するためにメソッドを追加するだけで、クライアントコードはすべて、どのFooを作成するかを判断する前に条件をチェックする必要があります。つまり、すべてのクライアントはあなたのFactoryがどのように動作するかを熟知している必要があり、すべてのクライアントは新しいFooが必要（または削除！）されるたびに変更する必要があります。

作成したばかりの場合は今想像しIFooFactoryますことをIFoo。今、異なるサブクラスまたは完全に異なる実装を作成することは子供の遊びです-チェーンの上位の正しいIFooFactoryにフィードし、クライアントがそれgimmeAFoo()を取得すると、適切なFactoryを取得したため、適切なfooを呼び出して取得します。

これが実稼働コードでどのように機能するか疑問に思われるかもしれません。私が取り組んでいるコードベースから1つの例を挙げると、プロジェクトをわずか1年ほどクランクアウトした後、平準化し始めています。質問データオブジェクトを作成するために使用される工場がたくさんあります（プレゼンテーションモデルのようなものです））。私が持っているQuestionFactoryMap基本的には使用時に質問ファクトリを検索するためのハッシュだということを。そこで、さまざまな質問をするアプリケーションを作成するために、さまざまなファクトリーをマップに追加しました。

質問は、指示または演習（両方とも実装IContentBlock）で提示できるため、それぞれInstructionsFactoryまたはExerciseFactoryQuestionFactoryMapのコピーを取得します。次に、さまざまな命令と演習のファクトリが、ContentBlockBuilderいつ使用するかのハッシュを再度保持します。そして、XMLがロードされると、ContentBlockBuilderはハッシュからエクササイズまたはインストラクションファクトリを呼び出してに要求しcreateContent()、次にファクトリは何に基づいて内部QuestionFactoryMapから引き出したものにでも質問の構築を委任します各XMLノードとハッシュにあります。残念ながら、そのことはあるBaseQuestionの代わりに、IQuestion、しかし、それはあなたがデザインに注意しているときでさえ、あなたがラインにあなたを悩ませることができる間違いを犯すことができることを示すことになります。

あなたの腸は、これらの静力学があなたを傷つけることをあなたに告げています、そして確かにあなたの腸をサポートするための文献にはたくさんあります。ユニットテストにのみ使用する依存関係注入を行うことで決して失われることはありません（良いコードを作成してもそれ以上使用しないと信じているわけではありません）が、静的関数は能力を完全に破壊する可能性がありますコードをすばやく簡単に変更できます。なぜそこに行くのでしょうか？