¿Cómo se utilizan las interfaces con el patrón de fábrica en el diseño controlado por dominio?

Question

¿Tiene sentido usar interfaces para las fábricas de objetos de su dominio de forma predeterminada, o las interfaces deben reservarse para las clases de fábrica solo cuando las necesita?

public IUserFactory
{
    User CreateNewUser();
}

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

Answer 1

Aquí hay una traducción del mismo problema a Java.

Ejemplo original

public interface UserFactoryIF
{
   User createNewUser();
}

Luego la implementación de la Fábrica

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

No veo ningún beneficio especial para definir una interfaz para la fábrica, ya que está definiendo una interfaz única para un productor centralizado. Por lo general, encuentro que necesito producir muchas implementaciones diferentes del mismo tipo de producto, y mi fábrica necesita consumir muchos tipos diferentes de parámetros. Es decir, podríamos tener:

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

La fábrica se vería así:

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

Espero que esto te haga entender.

Answer 2

En tu ejemplo dado, ni siquiera veo por qué necesitas ir a Factory.

  

La esencia del patrón de fábrica es   para " Definir una interfaz para crear   Un objeto, pero deja las subclases.   decidir qué clase para instanciar. los   Método de fábrica permite a una clase diferir   instanciación a las subclases. " - Wikipedia

¿Tiene un tipo diferente de Usuarios o Usuario es en sí mismo un tipo de algo? Puede que no hayas elaborado la cosa con claridad. Usualmente usamos interface en patrón de método de fábrica abstracto , donde necesitamos tratar con múltiples familias de objetos relacionados.

NOTA: No olvide, los patrones están ahí para ayudarnos, no significa que debamos usarlos porque están disponibles, ya sea que los necesitemos o no.

Answer 3

No todo tiene que tener una interfaz; Si tiene una implementación única de algo, y no hay razón para tener otra, no puedo ver por qué definir una interfaz.

Answer 4

Dos cosas: (1) esperaría hasta que necesitara (o viera una necesidad inminente) una implementación alternativa antes de crear la interfaz y (2) las interfaces casi siempre facilitan las pruebas unitarias, especialmente con burlas, así que Con frecuencia se me ocurre una necesidad de una interfaz de inmediato.

Answer 5

Crear la fábrica de una interfaz permite que sea mucho más fácil probarlos con clases simuladas, así como simplificar el uso de aplicaciones IoC, así que aunque no necesariamente las necesito para la funcionalidad de la aplicación, generalmente construyo y llamo más Clases a través de interfaces.

Si no estás considerando las Pruebas unitarias o los patrones de IoC (aparte de las opiniones religiosas), probablemente no me molestaría.

Encuentro que el mayor problema al usarlos, al menos en Visual Studio, es que 'Ir a la definición' en una propiedad o función salta a la definición de la interfaz, no a la definición de la clase.