2

クラスが常にFooオブジェクトを作成するとは限らない場合、クラスをFooFactoryと呼ぶのは間違っていますか？たとえば、次のインターフェイスがある場合：

public interface IFooFactory
{
    Foo Create();
}

次のように実装します。

public class FooFactory : IFooFactory
{
    public IFoo Create()
    {
        return ServiceLocator.Current.GetInstance<IFoo>();
    }
}

次に、このクラスは、IoCコンテナの構成方法に応じてFooを作成する可能性があります。'XxxFacotry'の名前を実際のファクトリ用に予約する必要がある場合、インターフェイスとクラスを何と呼ぶ必要がありますか？

明白な答えはIFooProviderですが、「XxxProvider」は使いすぎて曖昧すぎるため、避けたいと思います。一方、IFooServiceLocatorはあまりにも具体的です。

代替の命名提案は大歓迎です。

4

3 に答える 3

3

クラスはを提供しますがIFilter、これは作成を伴う場合と伴わない場合があります。FilterProvider漠然としすぎているのがわかりません。

気に入らない場合はどうFilterSourceですか？

正直なところ、それを呼ぶのはそれほど悪いことではないと思いますFilterFactory; つまり、誰がそれがどのように実装されるかをそれほど気にしますか？誰かがあなたのメソッドを呼び出した場合、結果をキャッシュしている可能性があります。これにより、新しいオブジェクトが実際に最初からインスタンス化されていないCreateことを知っているかどうかに関係なく、かなり議論の余地があります。Create

いずれにせよ、正しいことは、クラスの実際の機能を文書化することです。これには、クラスを利用するものに関連する詳細が含まれます（実際、無関係または重要でない詳細は省略されます）。

于 2010-08-25T12:34:28.590 に答える
3

それが時々ケーキを作るなら、あなたは何かをクッキーファクトリーと呼びますか？

于 2010-08-25T12:56:15.370 に答える
0

これまでのところ、50/50のようです。したがって、私が受け入れている答えは、「はい」を意味するものです。常に新しいFooオブジェクトが作成されるとは限らない場合は、FooFactoryという名前を付けるのは誤りです。これは、私自身の好みがそこにあるためです。

于 2010-08-26T17:54:10.860 に答える