Wie verwenden Sie Schnittstellen mit dem Factory-Muster in Domain-Driven Design?

Question

Macht es Sinn Schnittstellen standardmäßig für Ihre Domain Objekt Fabriken zu verwenden, oder sollten Schnittstellen für die Factory-Klassen reserviert werden nur dann, wenn man sie braucht?

public IUserFactory
{
    User CreateNewUser();
}

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

Answer 1

Hier ist eine Übersetzung des gleichen Problems in Java.

Original Beispiel

public interface UserFactoryIF
{
   User createNewUser();
}

Dann wird die Umsetzung der Fabrik

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

Ich sehe keinen besonderen Vorteil eine Schnittstelle für die Fabrik zu definieren, da Sie eine einzelne Schnittstelle für eine zentralisierte Hersteller sind zu definieren. Normalerweise finde ich, dass ich viele verschiedene Implementierungen der gleichen Art von Produkt produzieren muß, und meine Fabrik braucht viele verschiedene Arten von Parametern zu konsumieren. Das heißt, wir haben könnte:

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

Die Fabrik würde wie folgt aussehen:

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
    }
}

Hope this erhält den Punkt herüber.

Answer 2

In Ihrem gegebenen Beispiel sehe ich nicht einmal, warum Sie Fabrik gehen müssen.

  

Das Wesen der Fabrik Muster ist   auf „eine Schnittstelle definiert zum Erstellen   ein Objekt, aber lassen Sie die Unterklassen   entscheiden, welche Klasse zu instanziiert. Das   Factory-Methode ermöglicht eine Klasse defer   Instanziierung Unterklassen.“- Wikipedia

Haben Sie eine andere Art von Benutzer haben oder Mitglied ist selbst eine Art von etwas. Mai werden Sie die Sache eindeutig nicht erarbeiten. Wir verwenden normalerweise Schnittstelle in abstrakten Factory-Methode Mustern , wo wir mit mehreren Familien von verwandten Objekten befassen müssen.

Hinweis: Vergessen Sie nicht, Muster gibt es, uns zu helfen, bedeutet es nicht, dass wir sie benutzen müssen, weil sie zur Verfügung stehen, ob wir sie brauchen oder nicht

.

Answer 3

Nicht alles hat eine Schnittstelle haben; wenn Sie eine einzelne Implementierung von etwas haben, und keinen Grund, andere zu haben, ich kann nicht sehen, warum eine Schnittstelle definieren.

Answer 4

Zwei Dinge: (1) Ich würde warten, bis ich brauchte (oder sah einen sich abzeichnenden Bedarf) eine alternative Implementierung, bevor ich die Schnittstelle schaffen würde und (2) Schnittstellen fast immer Einheit machen Testen einfacher, vor allem mit spöttischen, so ich häufig sofort mit einem Bedarf an einer Schnittstelle kommen.

Answer 5

Aus einer Schnittstelle die Fabrik Erstellen ermöglicht es viel einfacher, sie mit gespielter Klassen zu testen, sowie macht es einfacher IoC Anwendungen zu verwenden, also während ich nicht unbedingt, sie für die Anwendungsfunktionalität benötigen, ich in der Regel bauen und nennen die meisten Klassen über Schnittstellen.

Wenn Sie nicht Unit-Tests oder IoC-Muster (religiöse Meinungen beiseite) unter Berücksichtigung, würde ich wahrscheinlich nicht stören.

ich den größten Schmerz finde bei der Verwendung von ihnen in Visual Studio ist zumindest, dass ‚Geh zu Definition‘ auf einer Eigenschaft oder Funktion springt auf die Schnittstellendefinition, nicht die Klassendefinition.