¿Puede alguien proporcionarme una respuesta canónica sobre las diferencias entre an Observery a Mediator, y un resumen de cuándo debe usar un patrón sobre el otro?
No estoy seguro de qué tipo de situación requeriría una Observery qué tipo requeriría unaMediator
Respuestas:
En el libro original que acuñó los términos Observador y Mediador, Patrones de diseño, Elementos de software orientado a objetos reutilizables , dice que el patrón de Mediador puede implementarse utilizando el patrón de observador. Sin embargo, también puede implementarse haciendo que los colegas (aproximadamente equivalentes a los patrones de los sujetos del observador) tengan una referencia a una clase de mediador o una interfaz de mediador.
Hay muchos casos en los que desea utilizar el patrón de observador, la clave es que el objeto no debe saber qué otros objetos están observando su estado.
El mediador es un poco más específico, evita que las clases se comuniquen directamente, sino a través de un mediador. Esto ayuda al principio de Responsabilidad Única al permitir que la comunicación se descargue a una clase que solo maneja eso.
Un ejemplo clásico de Mediator está en una GUI, donde el enfoque ingenuo puede conducir a un código en un evento de clic de botón que dice "si el panel Foo está deshabilitado y el panel Bar tiene una etiqueta que dice" Ingrese la fecha "y luego no llame al servidor de lo contrario, adelante ", donde con el patrón de Mediador podría decir" Solo soy un botón y no tengo ningún negocio terrenal que sepa sobre el panel Foo y la etiqueta en el panel de la Barra, así que solo preguntaré a mi mediador si llamo al servidor está bien ahora ".
O, si se implementa utilizando el patrón de observador, el botón diría "Hola, observadores (que incluiría al mediador), mi estado cambió (alguien me hizo clic). Haga algo al respecto si le importa". En mi ejemplo, eso probablemente tiene menos sentido, pero a veces lo sería, y la diferencia entre Observer y Mediator sería más una intención que una diferencia en el código mismo.
El patrón de Observador funciona bien cuando no es necesaria la coordinación entre los observadores y la relación de observación va en un sentido.
Por ejemplo, deje que los objetos B y C observen el objeto A. Cuando el objeto A dispara el evento X, el objeto B debe ejecutar el método Y () y el objeto C debe ejecutar el método Z (). Si los métodos BY () y CZ () son totalmente independientes y no requieren coordinación, entonces siga adelante y use el patrón de observador.
Por otro lado, si BY () debe ejecutarse antes que CZ (), entonces querrá usar el patrón Mediator donde el mediador encapsula esta coordinación. En este escenario, el mediador M observaría el objeto A y tendría referencias a los objetos B y C. Cuando A dispara el evento X, M manejará el evento y llamará BY () y CZ () en el orden prescrito.
Además, si los objetos A, B y C necesitan observarse entre sí, el uso de un mediador como intermediario contribuirá en gran medida a desacoplar estos objetos y evitar el código de espagueti.
El Observerpatrón se usa cuando una acción tomada en una clase (la clase observada) necesita producir una reacción en otra clase (la clase observadora) pero no es deseable que la clase observada se acople a la clase observadora. Este es un patrón muy común. El analizador XML SAX puede ser un buen ejemplo. Para usar el analizador SAX, un cliente implementa la ContentHandlerinterfaz para "observar" la operación del analizador. A medida que el analizador encuentra elementos del documento XML, llama a métodos de ContentHandler. El analizador puede invocar el código del cliente, pero el analizador no está acoplado al código del cliente.
El Mediatorpatrón es una encapsulación de un patrón de uso de un conjunto de objetos. El código del cliente solo está acoplado al mediador, en lugar de estar acoplado a varias otras clases. Es similar a la agregación, excepto que la vida útil de los objetos encapsulados es independiente de la vida útil del mediador.
En términos simples (que uso para recordarlo):
Observador: se usa cuando un objeto quiere ser informado de los cambios de estado en otro (estrictamente hablando, el uso de eventos es Observador)
Para comprender el mediador, me resulta más fácil cuando considera Facade primero: Facade agrega la funcionalidad de clases separadas (a veces subsistemas completos) y proporciona esa funcionalidad en una sola interfaz.
Mediador: Igual que Facade, excepto que combina la funcionalidad de todas las clases agregadas para producir una nueva funcionalidad. (Buena explicación aquí )