Come si utilizzano le interfacce con il modello di fabbrica nella progettazione guidata dal dominio?

Question

Ha senso utilizzare le interfacce per le fabbriche di oggetti di dominio per impostazione predefinita o le interfacce dovrebbero essere riservate alle classi di fabbrica solo quando ne hai bisogno?

public IUserFactory
{
    User CreateNewUser();
}

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

Answer 1

Ecco una traduzione dello stesso problema in Java.

Esempio originale

public interface UserFactoryIF
{
   User createNewUser();
}

Quindi l'implementazione della Factory

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

Non vedo alcun vantaggio speciale nel definire un'interfaccia per la fabbrica, dal momento che stai definendo un'unica interfaccia per un produttore centralizzato. In genere trovo che devo produrre diverse implementazioni dello stesso tipo di prodotto e la mia fabbrica deve consumare molti diversi tipi di parametri. Cioè, potremmo avere:

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

La fabbrica sarebbe simile a questa:

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

Spero che questo ottenga il punto.

Answer 2

Nel tuo esempio, non vedo nemmeno perché devi andare in Factory.

  

L'essenza del modello di fabbrica è   per " Definire un'interfaccia per la creazione   un oggetto, ma lascia che le sottoclassi   decidere quale classe istanziare. Il   Il metodo factory consente a una classe di differire   istanza in sottoclassi. " - Wikipedia

Hai un diverso tipo di utenti o l'utente stesso è un tipo di qualcosa. Forse non hai elaborato chiaramente la cosa. Solitamente utilizziamo interfaccia nel modello di metodo di fabbrica astratto , dove dobbiamo trattare con più famiglie di oggetti correlati.

NOTA: non dimenticare, i modelli sono lì per aiutarci, non significa che dobbiamo usarli perché sono disponibili, che ne abbiamo bisogno o meno.

Answer 3

Non tutto deve avere un'interfaccia; se hai una singola implementazione di qualcosa e non hai motivo di averne un'altra, non vedo perché definire un'interfaccia.

Answer 4

Due cose: (1) aspetterei fino a quando avessi bisogno (o vedessi un'esigenza incombente) un'implementazione alternativa prima di creare l'interfaccia e (2) le interfacce per rendere quasi sempre più facili i test delle unità, specialmente con il derisione, quindi Spesso mi viene subito in mente la necessità di un'interfaccia.

Answer 5

La creazione della factory da un'interfaccia rende molto più semplice testarli con classi simulate, oltre a rendere più semplice l'uso delle applicazioni IoC, quindi mentre potrei non averne necessariamente bisogno per la funzionalità dell'applicazione, generalmente costruisco e chiamo la maggior parte classi tramite interfacce.

Se non stai prendendo in considerazione test unitari o modelli IoC (opinioni religiose a parte), probabilmente non mi preoccuperei.

Trovo il più grande problema nell'usarli, almeno in Visual Studio, è che "Vai alla definizione" su una proprietà o funzione passa alla definizione dell'interfaccia, non alla definizione della classe.