¿Cómo puedo saber que necesito un patrón de fachada en un punto del desarrollo de mi aplicación?Uso del patrón de fachada
¿Cómo puedo trazar la línea entre el patrón de fachada y el patrón de plantilla?
Por ejemplo: En [this] artículo, vemos que, int placeOrder(int CustomerID, List<BasketItem> Products) tiene una serie de pasos predefinidos en el algoritmo. Entonces, ¿por qué el autor no usa el patrón de plantilla aquí?
La fachada se ocupa de la interfaz, no de la implementación. Su propósito es ocultar la complejidad interna detrás de una única interfaz que parece simple en el exterior. En el ejemplo de su pregunta, la fachada oculta cuatro clases (Order, OrderLine, Address, BasketItem) detrás de un único método.
El método de la plantilla se refiere a la implementación. Su propósito es extraer el algoritmo común de varios que difieren solo en un 'relleno en blanco'. El método de la plantilla en la superclase implementa el algoritmo común y cada subclase 'completa los espacios en blanco' de su propia manera específica.
¿Por qué el autor no usa el Patrón de plantilla aquí?
Tendría sentido hacer placeOrder un método de plantilla si hubiera varias versiones similares de la operación. Tal vez algunos métodos como placePhoneOrder, placeInternetOrder, placeManuallyEnteredOrder podrían refactorizarse en una sola plantilla placeOrder con algunas subclases que implementan únicamente las diferencias específicas de {teléfono, internet, manual}.
¡Excelente! Encuentro exactamente lo que necesitaba de él. – anonymous
Supongamos que tiene algunos servicios, bibliotecas o lo que sea. Estas bibliotecas necesitan interoperación para realizar algunos servicios de nivel superior. Luego, tal vez desee ajustar esas llamadas y el código de inicialización que suelen ir juntos y ofrecer un conjunto de funciones para ocultar esos detalles y simplificar el uso de esos servicios para escenarios específicos. Entonces es un buen uso para el patrón de fachada.
ACTUALIZACIÓN: En el artículo mencionado, el método PlaceOrder tiene una sola implementación que funciona para todos los pedidos. El patrón de plantilla pretende prescribir una serie de pasos que deben seguirse, pero permite que las subclases ofrezcan su implementación personalizada de esos pasos fijos. Por ejemplo, si necesita que los pedidos de televisores se procesen de manera diferente a los pedidos de microondas, puede usar el patrón de plantilla para redefinir algún método imaginario de DispatchParcel (para enviar microondas como un paquete simple pero televisión con servicio adicional para ayudar a levantar el dispositivo pesado al piso superior). En nuestro caso, no es necesario volver a implementar los pasos de ProcessOrder para que no haya necesidad de un patrón de plantilla, ya que una sola implementación se adapta a todos los tipos de órdenes.
El patrón de fachada es apropiado cuando tiene un sistema complejo que desea exponer a los clientes de una manera simplificada, o si desea crear una capa de comunicación externa sobre un sistema existente que es incompatible con su sistema. Es un estructural patrón. Ver aquí: http://en.wikipedia.org/wiki/Facade_pattern
El patrón de plantilla, por el contrario, es un comportamiento patrón que le ayudará cuando se trata de la implementación interna de un componente. Vea aquí: http://en.wikipedia.org/wiki/Template_method_pattern
¿Qué quiere decir con dibujar la línea entre Fachada y Plantilla? La fachada es un patrón estructural y la plantilla es un patrón de comportamiento: no veo cómo se pueden relacionar los dos. – RichardOD