Diferencias entre el patrón de generador y el método de plantilla (constructor vs plantilla)

Question

El patrón de plantilla proporciona un algoritmo en la clase base cuyos pasos se pueden modificar en la clase derivada. En el patrón de Constructor, el constructor de concreto expone métodos para construir un producto que son llamados desde la clase Director.

Entiendo que hay una diferencia con respecto al propósito de usar estos patrones. El patrón de plantilla es un patrón de comportamiento que cambia uno o más pasos en una plantilla, mientras que el patrón de construcción es un patrón de creación.

Además de la diferencia mencionada anteriormente, ¿hay alguna otra diferencia?

No es director en el patrón del generador que actúa como una plantilla base en el patrón de la plantilla. Los constructores de concreto actúan como clases derivadas en el patrón de plantilla con pasos sustituibles?

¿Puede alguien aclarar por favor. Gracias.

Me refiero método Plantilla http://www.dofactory.com/Patterns/Patterns.aspx

Answer 1

es en realidad una forma de definir algunos métodos que cada subclase debe definir.

El patrón de generador se utiliza para construir un objeto más complejo.

Digamos que queremos construir diferentes modelos de Saab (marca de automóviles). Cada modelo tiene diferentes motores, luces, etc.

Si tuviéramos que usar el patrón de método de plantilla, teníamos que crear una clase para cada combinación de automóviles o usar algunas jerarquías de herencia desagradables. Muchos de esos métodos también contendrían código duplicado.

Con el patrón de construcción, en su lugar, podemos tomar diferentes partes y unirlas en un automóvil completo. Por lo tanto, podemos reutilizar un motor para cada modelo si es necesario y también podemos personalizar cada parte del automóvil.

Answer 2

Encontré la misma pregunta muy interesante.

El ejemplo del coche Saab es interesante, pero no se ajusta a la descripción del patrón del Constructor en "Banda de cuatro" (Patrones de diseño).

Utilizaré la terminología de "Gang of Four".

En Gang of Four, no puede haber una mezcla de constructores de hormigón por cada invocación de aDirector->Construct() por lo que el ejemplo de Saab, si bien es interesante, no responde la pregunta realmente para mí.

veo algunas:

La separación del objeto del administrador de la jerarquía Builder es una diferencia clave. En la fábrica de plantillas, tanto el método que incorpora el flujo generalizado como los métodos modificados son miembros de la misma clase. Esto hace que el patrón del generador sea mejor para encapsular las etapas internas del proceso, ya que es menos probable que el código del cliente entre en contacto con dichos métodos si se accede solo al objeto director. El patrón de generador también permite una formulación del proceso de ensamblaje completamente independiente de la jerarquía del generador, lo que permite un reemplazo más flexible de la instancia del generador cuando sea necesario. Por ejemplo, una vez que tenga una instancia de director a la mano, puede construir fácilmente varias representaciones del producto, cada vez reemplazando dinámicamente el generador de concreto. Entonces el constructor es más dinámico y encapsula mejor el funcionamiento interno del constructor de concreto.

Además, si desea detallar el objeto Director por herencia, puede hacerlo sin multiplicar su jerarquía. Por ejemplo, puede tener un proceso expreso de construcción para ahorrar tiempo antes de la construcción final: puede subclasificar el objeto Director o incluso usar el "Método de plantilla" en él para personalizarlo por herencia sin tener que volver a implementar sus constructores de hormigón.

Pero esto nos lleva a considerar otro patrón que está estrechamente relacionado con "Template Factory" - el patrón de "Estrategia".

La estrategia se parece mucho a Template Factory, con dos claras diferencias: también separa un objeto de contexto de la jerarquía de estrategias, permitiendo el cambio de algoritmos para una sola instancia de problema en tiempo de ejecución. Otra diferencia es que los ejemplos parecen sugerir que la invocación de la Estrategia no implica necesariamente un proceso complejo o estructurado como en "Método de plantilla".

Pero lo traigo aquí como análogo de Builder para llegar a otro punto - Si "Estrategia" es paralelo en su estructura de clases a Builder, entonces el patrón creacional paralelo a "Método de plantilla" debería ser "Método de fábrica" . Esto es claro, no solo por su nombre, pero, curiosamente, las discusiones de ambos capítulos del libro "Método de fábrica" ​​y "Método de plantilla" usan ejemplos casi idénticos (una aplicación para editar documentos).

Entonces, sin entrar en la cuestión de cuál es la diferencia entre los patrones creacionales y de comportamiento, tiendo a pensar que tanto el Builder como el Factory Method son básicamente casos específicos y refinamientos de Strategy y Template Method, respectivamente.

Entonces la pregunta es - si usted no ve ninguna diferencia entre Builder y la plantilla de la fábrica - tratar de responder a estas preguntas:

1. ¿Qué perspectiva prefiere tener en esa parte particular del sistema? ¿Es "comportamiento" o "creación"? y

2. ¿Necesita una fuerte encapsulación, o el reemplazo dinámico o despliegue o ajuste de una instancia de generador, por un lado, o espera que la complejidad (por herencia, composición u otra) evolucione alrededor del proceso de creación o método de la plantilla? Si la respuesta a cualquiera de estas preguntas va con la estructura del Constructor/Estrategia. De lo contrario, use un polimorfismo simple de relación o comportamiento en los patrones del Método XX.

Answer 3

Antes de empezar, mi línea universal para todas mis respuestas: "Cualquier concepto de programación en cualquier idioma requiere entender de tres maneras (a) Desde la perspectiva del diseño (b) la perspectiva de tiempo de ejecución (c) Desde la perspectiva de la memoria. .

Habiendo dicho que las personas que hacen una declaración basada en (a) pueden no estar de acuerdo con (b) y viceversa (o puede ser que alguien dé una explicación circular para contaminar la definición clara.) Fabricante de pizza, constructor de restaurante, Constructor de coches o plantilla de interfaz de usuario, la plantilla de flujo de trabajo no tiene sentido cuando en un proyecto empresarial le piden que implemente un patrón de compilación/plantilla (puede que estos patrones no estén maduros para definirse a sí mismos). La razón del fracaso es si conozco algunos objeto tiene que ser compilado en 4 pasos, entonces ¿por qué voy a comenzar a crear instancias desde el vacío y llenarlo paso a paso con el director? ¿Qué pasará si no quiero que el paso 3 o demasiadas excepciones ocurran en el paso 2. En cambio, crearé el objeto final cuando se realicen los 4 pasos (esto me sucedió exactamente a lo largo de mi carrera y por eso el patrón de construcción es no adoptado por los desarrolladores). Aquí las personas pueden argumentar en sistemas distribuidos donde se requiere una conducta asínmica, entonces Builder puede ayudar; pero si ese es el caso, entonces seguiría confiando onreadystatechange == 4 y luego instanciaría mi builderObj. Entonces, ¿no deberíamos usar Builder? La respuesta en mi humilde opinión es "NO".

Según tengo entendido, en .net tenemos ControllerBuilder, SqlConnectionStringBuilder, UriBuilder; todos están personalizando ControllerFactory, Sql, Uri Factories; entonces mi programa principal puede usar esas fábricas para generar Controladores, ConnStrings, Uries. Entonces, ¿el patrón Builder es para la personalización de la configuración de fábrica? ¿Necesitamos la personalización de la configuración de fábrica? Probablemente nunca; en cambio, lo mejor que haré es crear 4 métodos asíncronos y encadenarlos con los parámetros del paso 2 (en los parámetros del segundo paso de encadenamiento ...). Qué patrón de plantilla abt (plantilla de flujo de trabajo asp.net o plantilla jQuery o plantilla enlatada). Para mí, ambos son iguales, pero en comparación con el constructor, la plantilla es de naturaleza más rígida (casi todo está arreglado, muy pocas propiedades deben cambiar para definir un tmplt específico) y una vez que se define la plantilla, luego la fábrica. Otro rumor que también he visto para estos dos es capaz de "Cualquier fábrica-> Cualquier producto" como When would you use the Builder Pattern?; pero eso no es cierto porque es similar al anterior .Net ControllerBuilder, sql, uri escenario con el concepto "Factory of Factory". Lo cual está en contra de muchos principios de diseño (SRP, LSP, mala encapsulación). Espero que mis escritos completos sobre estos dos ayuden desde principiante hasta avanzado.