pattern patron observer ejercicio diseño language-agnostic design-patterns facade

language-agnostic - patron - observer pattern



Uso del patrón de fachada (3)

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 patrón estructural . Vea aquí: http://en.wikipedia.org/wiki/Facade_pattern

El patrón de plantilla, por otro lado, es un patrón de comportamiento que lo ayudará cuando se trate de la implementación interna de un componente. Vea aquí: http://en.wikipedia.org/wiki/Template_method_pattern

¿Cómo puedo saber que necesito un Patrón de fachada en un punto del desarrollo de mi aplicación?

¿Cómo puedo trazar la línea entre el patrón de fachada y el patrón de plantilla?

Por ejemplo: en [este] 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í?


Facade 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 trata de 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 ''rellena los espacios en blanco'' de su propia manera específica.

Entonces, ¿por qué el autor no usa el patrón de plantilla aquí?

Tendría sentido hacer que placeOrder un método de plantilla si hubiera varias versiones similares de la operación. Tal vez algunos métodos como placePhoneOrder , placePhoneOrder , placeManuallyEnteredOrder puedan refactorizar en una sola plantilla placeOrder con algunas subclases que implementen solo las diferencias específicas de {phone, internet, manual}.


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 única 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.