¿Es confuso llamar a esta clase una "fábrica"?

Question

Mi comprensión de una fábrica es que encapsula la creación de instancias de clases concretas que todas heredan una clase o interfaz abstracta común. Esto permite que el cliente se desacople del proceso de determinar qué clase concreta crear, lo que a su vez significa que puede agregar o eliminar clases concretas de su programa sin tener que cambiar el código del cliente. Puede que tenga que cambiar la fábrica, pero la fábrica está "construida a propósito" y realmente solo tiene una razón para cambiar: se ha agregado/eliminado una clase concreta.

He creado algunas clases que, de hecho, encapsulan la instanciación de objetos, pero por una razón diferente: los objetos son difíciles de crear. Por el momento, llamo a estas clases "fábricas", pero me preocupa que pueda ser un término inapropiado y que podría confundir a otros programadores que podrían ver mi código. Mis clases de "fábrica" ​​no deciden qué clase concreta crear, garantizan que una serie de objetos se instanciará en el orden correcto y que las clases correctas se pasarán a los constructores correctos cuando llame al new().

Por ejemplo, para un proyecto de MVVM en el que estoy trabajando, escribí una clase para asegurarme de que mi SetupView se instanciara correctamente. Se ve algo como esto:

public class SetupViewFactory 
{ 
    public SetupView CreateView(DatabaseModel databaseModel, SettingsModel settingsModel, ViewUtilities viewUtilities) 
    { 
     var setupViewModel = new SetupViewModel(databaseModel, settingsModel, viewUtilities); 
     var setupView = new SetupView(); 
     setupView.DataContext = setupViewModel; 
     return setupView; 
    } 
} 

Es confuso para llamar a esto una "fábrica"? No decide entre varias clases concretas posibles, y su tipo de devolución no es una interfaz o tipo abstracto, pero encapsula la instanciación de objetos.

Si no es una "fábrica", ¿qué es?

---

Editar

Varias personas han sugerido que este es en realidad el Builder.

La definición del Builder de dofactory es el siguiente:

independiente la construcción de un objeto complejo de su representación de manera que el mismo proceso de construcción pueden crear diferentes representaciones.

Esto también parece un poco exagerado. Lo que me molesta son las "diferentes representaciones". Mi propósito no es abstraer el proceso de construcción de una Vista (no es que esa no sea una meta digna). Simplemente trato de poner la lógica para crear una vista específica en un solo lugar, de modo que si alguno de los ingredientes o el proceso para crear esa vista cambian, solo tengo que cambiar esta clase. El patrón de construcción realmente parece decir: "Creemos un proceso general para crear Vistas, luego puede seguir el mismo proceso básico para cualquier Vista que cree". Bien, pero eso no es lo que estoy haciendo aquí.

---

Editar 2

Acabo de encontrar un ejemplo interesante en un Wikipedia article on Dependency Injection.

En "La dependencia inyectado de forma manual", que contiene la clase siguiente:

public class CarFactory { 

    public static Car buildCar() { 
     return new Car(new SimpleEngine()); 
    } 

} 

Esto es casi exactamente el uso que tengo (y no, no he escrito el artículo de wiki :)).

Curiosamente, este es el comentario siguiente este código:

En el código anterior, la fábrica tiene la responsabilidad de montar el coche, e inyecta el motor en el coche. Esto libera al automóvil de saber cómo crear un motor, aunque ahora el CarFactory tiene que saber sobre la construcción del motor. Uno podría crear una EngineFactory, pero eso simplemente crea dependencias entre las fábricas. Así que el problema persiste, pero al menos se ha cambiado a fábricas, o constructores objetos. [mi énfasis]

Así que, esto me dice que al menos no soy el único que pensó en crear una clase para ayudar con la inyección de material en otra clase, y no soy el único que intentó para nombrar a esta clase como una fábrica.

Answer 1

Esto no suena muy diferente a mí que un constructor para una instancia de SetupView. Tal vez se eliminó demasiado contexto de código de su ejemplo, pero no veo por qué lo que tiene allí no puede simplemente escribirse como un constructor, y los argumentos pasan como args al constructor.

A juzgar estrictamente de patrones GoF, creo que pierde la marca de fábrica por dos razones:

1. no hay familia de objetos/dependientes relacionadas
2. la clase concreta es, de hecho, se especifica

Con respecto a Builder, creo que se pierde en el aspecto de la varianza de los productos.

Cuando enseño cursos de Diseño de patrones, les digo a los estudiantes que observen no solo la intención de un patrón cuando intentan determinar el "mejor ajuste", sino más bien observar la aplicabilidad y la estructura/participantes. El propósito puede ayudarlo a descartar las cosas, pero la aplicabilidad & estructura/participantes es lo que lo ayudará a su casa.

Si puede identificar qué parte de su diseño cumple las diversas funciones de los participantes en (Resumen) Fábrica o Constructor, entonces ha hecho un buen caso para usar esa nomenclatura.

Answer 2

GoF llaman "Builder"

Answer 3

creo, es una "fábrica". Cuando miro la declaración de clase, me alegra ver que se trata de una "fábrica" ​​y, además, es una "fábrica" ​​de objetos SetupView. Así que sé que esta Factory me dará instancias de SetupView concretas y construidas correctamente.

Answer 4

Se ve a mí como lo que tiene que hay más de un patrón Builder que un patrón de fábrica.

Answer 5

Podría llamarlo "asistente".

Answer 6

Una "fábrica" ​​es todo lo que encapsula la creación de instancias de objetos nuevos. Por qué, o qué son los objetos, no importa. El uso más común es el que usted describe, pero otros propósitos que no se ajustan a esa descripción también se pueden llamar Fábrica. La idea fundamental, (que no creo que el desarrollador más anal o quisquilloso pueda malinterpretar), es que la cosa crea nuevos objetos para usted ...

Answer 7

Esto me parece un poco extraño. No es una fábrica abstracta, pero tampoco encaja en el patrón del Constructor. Lo que tendría más sentido para mí es que en lugar de tener SetupViewFactory con el método CreateView, movería este método a la clase SetupView y lo convertiría en estático. Entonces usted tendría ...

public class SetupView 
{ 
    public static SetupView CreateView(DatabaseModel databaseModel, SettingsModel settingsModel, ViewUtilities viewUtilities) 
    { 
     var setupViewModel = new SetupViewModel(databaseModel, settingsModel, viewUtilities); 
     var setupView = new SetupView(); 
     setupView.DataContext = setupViewModel; 
     return setupView; 
    } 
} 

Ahora tiene lo que se conoce como la fábrica estática o un método de fábrica. Puede dar un paso más y privatizar los constructores de SetupView para que la única forma de obtener una instancia de SetupView sea llamar al método de fábrica.

En respuesta al comentario de OP:

Si hay tal necesidad de la separación que evitaría la creación de la SetupViewModel en cualquier lugar en esta parte del código. En su lugar, simplemente pase el SetupViewModel que desea asociar con su SetupView en lugar de las propiedades de los constituyentes para pasar al constructor de SetupViewModel. Entonces el código se convierte ...

public class SetupView 
{ 
    public static SetupView CreateView(SetupViewModel model) 
    { 
     var setupView = new SetupView(); { DataContext = model }; 
     return setupView; 
    } 
} 

Answer 8

Me gustaría estar de acuerdo con Jason anterior. Para mí, es más como un patrón de generador pero si convertiste a SetupView en una interfaz, sería más como un patrón de fábrica. La clave del patrón Factory es dejar que el patrón Factory haga todo el trabajo para decidir qué devolver desde la llamada a la función. Entonces, creo que tendrías que tener un interruptor seleccionando entre varias opciones dados los parámetros de entrada.

Answer 9

¿Por qué no dos clases con constructores simples?

public class SetupViewModel { 
     public SetupViewModel(DatabaseModel databaseModel, SettingsModel settingsModel, ViewUtilities viewUtilities) { 
      this.DatabaseModel = databaseModel; 
      this.SettingsModel = settingsModel; 
      this.ViewUtilities = viewUtilities; 
     } 
} 

y

public class SetupView {   
     public SetupView(SetupViewModel model) {    
      this.DataContext = model; 
     } 
} 

De esta manera, las dos clases claramente indican lo que necesitan para ser construido.