¿Cuáles son los usos prácticos de Factory Method Pattern?

Question

Soy bastante nuevo en Patrones de diseño. Acabo de encontrar el Patrón de diseño de fábrica. Entendí que delega la creación de instancias en subclases. Pero no obtuve la aplicación real del patrón. En qué escenarios se puede utilizar este patrón con buenos resultados. He oído hablar de abuso de patrones y no me gustaría complacerme en eso. ¿Alguien puede mencionar un ejemplo del mundo real donde se usa comúnmente?

Answer 1

Lo he usado para complementos de aplicaciones ... de esta manera puede hacer que su aplicación principal llame a la fábrica de clases para instanciar el complemento específico que implementa alguna interfaz que haya desarrollado en su aplicación principal. De esta manera, puede codificar la parte principal de su aplicación sin tener que saber qué se va a enchufar.

Answer 2

Acabo de utilizarlo en una aplicación de programación, donde las tareas que se programarán están en ensamblajes separados, y el planificador no sabe nada sobre las tareas ... Recibe el nombre del ensamblado desde el que se define la tarea una fuente externa, y luego carga el ensamblaje dinámicamente, instancia una clase en ese ensamblado utilizando una interfaz bien definida. Un método de fábrica en el programador, que toma el nombre del ensamblado como un parámetro de entrada, devuelve una instancia de la clase en el ensamblaje cargado ...

.. pero hay tantos usos y maneras de usar ... esto patrón.

Answer 3

El patrón de fábrica es muy útil para asignar una capacidad a un controlador apropiado.

Answer 4

Supongamos que tiene una cola que contiene objetos del tipo task.

Ahora, puede la subclase task por varias razones. Si está cargando sus tareas desde alguna fuente como una base de datos, puede usar una fábrica para determinar qué tipo de tarea cargar.

Por ejemplo:

private IEnumerable<Task> GetTasks(DataTable Table){ 

    Task NewTask; 

    foreach(DataRow Row in Table){ 
    switch(tasktype){ 
     case tasktypes.TaskTypeA: 
     NewTask = NewTaskA(...); 
     break; 

     case TaskTypes.TaskTypeB: 
     NewTask = NewTaskB(...); 
     break; 
     ... 
    } 

    yield return NewTask; 
    } 
} 

Más tarde, a continuación, podría llamar a los métodos virtuales en las tareas en la cola, como "consumir" o "proceso", por ejemplo.

La ventaja del enfoque de fábrica (en este caso) es que solo tiene que activar el tipo de tarea una vez (cuando se crea la tarea) y dejar que el polimorfismo maneje casi todo lo demás.

Answer 5

Ciertamente, la necesidad de utilizar los detalles de implementación más dolorosos descritos por el patrón se eliminó gracias a la forma en que C# funciona, pero mi funcionalidad SQL DAL pasa alrededor de fábricas de objetos (y comandos SQL) a funciones de utilidad que usan las fábricas para generar objetos Si no estuviera usando C#, supongo que podría haber usado una clase de fábrica explícita que generara los objetos.

Answer 6

es decir, en uno de los 2 casos:

1. su clase no se conoce el tipo de objeto que se quiere crear, pero sólo quiere un objeto que va a 'hacer el trabajo'. EMF salta a la mente ya que usa mucho este patrón.
2. desea las subclases de su clase para determinar el tipo de objeto que se utilizará. es decir, si está escribiendo su clase para padres sin saber qué producto concreto se creará, será responsabilidad del creador concreto.