ドメイン駆動設計でファクトリ パターンを備えたインターフェイスをどのように使用しますか?

Question

デフォルトでドメイン オブジェクト ファクトリのインターフェイスを使用するのは理にかなっていますか、それとも必要な場合にのみインターフェイスをファクトリ クラス用に予約する必要がありますか?

public IUserFactory
{
    User CreateNewUser();
}

public UserFactory : IUserFactory
{
    public User CreateNewUser()
    {
        return new User();
    }
}

Answer 1

同じ問題をJavaに翻訳したものがここにあります。

オリジナルの例

public interface UserFactoryIF
{
   User createNewUser();
}

次にファクトリの実装

public class UserFactory implements UserFactoryIF
{
     public User createNewUser()
     {
         // whatever special logic it takes to make a User
         // below is simplification
         return new User();
     }
}

一元化されたプロデューサーに対して単一のインターフェースを定義しているため、ファクトリーのインターフェースを定義しても特別な利点はありません。通常、同じ種類の製品のさまざまな実装を作成する必要があり、工場ではさまざまな種類のパラメーターを使用する必要があります。つまり、次のようになります。

public interface User
{
    public String getName();
    public long getId();
    public long getUUID();
    // more biz methods on the User
}

ファクトリは次のようになります。

public class UserFactory {

    public static User createUserFrom(Person person) {
        // ...
        return new UserImpl( ... );
    }

    public static user createUserFrom(AmazonUser amazonUser) {
         // ... special logic for AmazonWS user
        return new UserImpl( ... );          
    }

    private static class UserImpl implements User {
       // encapsulated impl with validation semantics to
       // insure no one else in the production code can impl
       // this naively with side effects
    }
}

これがポイントを獲得することを願って。

Answer 2

あなたが与えた例では、なぜFactoryに行く必要があるのか​​さえわかりません。

工場パターンの本質は、「オブジェクトを作成するためのインターフェイスを定義するが、サブクラスにどのクラスがインスタンス化されるかを決定させることです。工場の方法により、クラスはサブクラスへのインスタンス化を延期できます。 "-wikipedia

別のタイプのユーザーがいますか、それともユーザー自体が何かのタイプです。もしかしたら、明確に詳しく説明していなかったかもしれません。私たちが普段使っているのは インターフェース で 抽象的なファクトリ メソッド パターン, ここでは、関連オブジェクトの複数のファミリーを処理する必要があります。

注記：忘れないでください。パターンは私たちを助けるために存在します。必要かどうかに関係なく、入手可能なからといって必ず使用しなければならないというわけではありません。

Answer 3

すべてがインターフェースを持っている必要はありません。何かの単一の実装があり、他に実装する理由がない場合、なぜインターフェイスを定義するのかわかりません。

Answer 4

2つのこと：（1）インターフェースを作成する前に代替実装が必要になる（または迫り来る必要性が見られる）まで待ち、（2）インターフェースはほとんど常にユニットテストを簡単にします。すぐにインターフェイスが必要になることがよくあります。

Answer 5

インターフェイスからファクトリを作成すると、モッククラスでテストをはるかに簡単にできるようになり、IoCアプリケーションをより簡単に使用できるようになります。インターフェースを介したクラス。

単体テストやIoCパターンを考慮していない場合（宗教的な意見は別として）、私はおそらく気にしません。

少なくともVisual Studioでこれらを使用する場合の最大の苦痛は、プロパティまたは関数の[定義に移動]がクラス定義ではなくインターフェイス定義にジャンプすることです。