design-patterns - gof design patterns

Fachada vs. Mediador

Question

He estado investigando la diferencia entre estos dos patrones.

Entiendo que la fachada encapsula el acceso a un subsistema y el mediador encapsula las interacciones entre los componentes.

Entiendo que los componentes del sistema secundario no conocen la fachada, ya que los componentes son obviamente conscientes del mediador.

Actualmente estoy usando una fachada para encapsular el método de recuperación de información de configuración, por ejemplo, App.Config, configuración de usuario almacenada en SQL, información de ensamblaje, etc., y un mediador para navegar entre diferentes formularios de Windows.

Sin embargo, la mayoría de los sitios señalan que el mediador "agrega funcionalidad". ¿Qué quieren decir con esto? ¿Cómo agrega el mediador la funcionalidad?

Answer 1

... la mayoría de los sitios señalan que el mediador "agrega funcionalidad" ...

La fachada solo expone la funcionalidad existente desde una perspectiva diferente.

El mediador "agrega" funcionalidad porque combina diferentes funcionalidades existentes para crear una nueva.

Toma el siguiente ejemplo:

Usted tiene un sistema de registro. Desde ese sistema de registro, puede iniciar sesión en un archivo, en un socket o en una base de datos.

Usando el patrón de diseño de fachada, "ocultaría" todas las relaciones de la funcionalidad existente detrás de una única "interfaz", la que expone la fachada.

Codigo del cliente:

 Logger logger = new Logger();
 logger.initLogger("someLogger");
 logger.debug("message");

La implementación puede involucrar la interacción de muchos objetos. Pero al final, la funcionalidad ya existe. Probablemente el método de "depuración" se implementa de la siguiente manera:

Implementación:

 class Logger { 

      private LoggerImpl internalLogger;
      private LoggerManager manager;

      public void initLogger( String loggerName ) {
          this.internalLogger = manager.getLogger( loggerName ); 
      }

      public void debug( String message ) { 
          this.internalLogger.debug( message );
      }     
 }

La funcionalidad ya existe. La fachada solo lo oculta. En este caso hipotético, LoggerManager maneja la creación del registrador correcto, y LoggerImpl es un objeto privado de paquete que tiene el método "debug". De esta manera, Facade no agrega funcionalidad, solo delega en algunos objetos existentes.

Por otro lado, el mediador agrega la nueva funcionalidad combinando diferentes objetos.

Mismo código de cliente:

 Logger logger = new Logger();
 logger.initLogger("someLogger");
 logger.debug("message");

Implementación:

 class Logger { 

      private java.io.PrintStream out;
      private java.net.Socket client;
      private java.sql.Connection dbConnection;
      private String loggerName;


      public void initLogger( String loggerName ) {
               this.loggerName = loggerName;
               if ( loggerName == "someLogger" ) { 
                    out = new PrintStream( new File("app.log"));
               } else if ( loggerName == "serverLog" ) { 
                    client = new Socket("127.0.0.1", 1234 );
               } else if( loggerName == "dblog") { 
                    dbConnection = Class.forName()... .
               }

      }

      public void debug( String message ) { 

               if ( loggerName == "someLogger" ) { 
                    out.println( message );
               } else if ( loggerName == "serverLog" ) { 
                    ObjectOutputStrewam oos = 
                           new ObjectOutputStrewam( client.getOutputStream());
                    oos.writeObject( message );
               } else if( loggerName == "dblog") { 
                    Pstmt pstmt = dbConnection.prepareStatment( LOG_SQL );
                    pstmt.setParameter(1, message );
                    pstmt.executeUpdate();
                    dbConnection.commit();
               }
      }
 }

En este código, el mediador es el que contiene la lógica de negocios para crear el "canal" apropiado para iniciar sesión y también para hacer el registro en ese canal. El mediador está "creando" la funcionalidad.

Por supuesto, hay mejores formas de implementar esto usando el polimorfismo, pero el punto aquí es mostrar cómo el mediador "agrega" nuevas funcionalidades combinando la funcionalidad existente (en mi muestra no mostró mucha pena) pero imagine al mediador, lea desde la base de datos el host remoto donde se registra, luego crea un cliente y finalmente escribe en ese flujo de impresión del cliente el mensaje de registro. De esta forma, el mediador estaría "mediando" entre los diferentes objetos.

Finalmente, la fachada es un patrón estructural, es decir, describe la composición de los objetos, mientras que el mediador es un comportamiento, es decir, describe la forma en que los objetos interactúan.

Espero que esto ayude.

Answer 2

A partir del libro "Patrones de diseño", la CLAVE del patrón del mediador se describe de la siguiente manera: "It (un mediador) actúa como un HUB de comunicación para widgets (es decir, ''un'' grupo de objetos interdependientes)".

En otras palabras, un objeto mediador es el único superobjeto que conoce todos los demás objetos en un grupo de objetos colaboradores y cómo deben interactuar entre sí. Todos los demás objetos deben interactuar con el objeto mediador, en lugar de uno con el otro.

Por el contrario, una fachada es una "interfaz unificada" para un conjunto de interfaces en un subsistema, para uso de los consumidores del subsistema, y ​​no entre los componentes del subsistema.

Answer 3

Ambos imponen algún tipo de política en otro grupo de objetos. Facade impone la política desde arriba, y Mediator impone la política desde abajo. El uso de Facade es visible y restrictivo, mientras que el uso de Mediator es invisible y habilitante.

El patrón de fachada se utiliza cuando desea proporcionar una interfaz simple y específica a un grupo de objetos que tiene una interfaz compleja y general.

El patrón de Mediator también impone una política. Sin embargo, mientras que Facade impuso su política de una manera visible y restrictiva, Mediator impone sus políticas de una manera oculta y sin restricciones.

Desarrollo ágil de software, principios, patrones y prácticas Robert C. Martin.

Answer 4

Estoy usando un mediador para agregar funcionalidad de archivo de registro.

Funciona así:

• Obj A le dice al mediador que necesita algo hecho.
• El mediador envía el mensaje a varios objetos del cliente.
• Obj B hace lo que Obj A necesita y envía un mensaje apropiado a través del mediador.
• Mientras tanto, Obj C también recibe mensajes del mediador y registra los resultados. De esta forma, podemos obtener estadísticas de usuario de los archivos de registro.
• Obj D también podría ser un corrector de errores, de modo que si el Obj B responde que la petición del Obj A es imposible, Obj D podría ser lo que informa al usuario. Los errores ahora se pueden registrar en un archivo diferente al de la actividad regular, y podrían usarse otros medios para comportarse (pitidos, lo que sea) que el Obj A no debería preocupar realmente.

Answer 5

Pensé que la distinción era direccional: la fachada es una comunicación unidireccional entre el cliente y la fachada; El mediador puede ser una conversación bidireccional, con mensajes que fluyen hacia adelante y hacia atrás entre el cliente y el mediador.

Answer 6

Puede encontrar detalles sobre el patrón de fachada en esta pregunta SE:

¿Qué es el patrón de diseño de fachada?

Facade proporciona una interfaz simple y unificada para un sistema complejo.

El ejemplo del mundo real ( vuelo de cleartrip + reserva de hotel ) está disponible en esta publicación:

¿Qué es el patrón de diseño de fachada?

Patrón de mediador : define un objeto que encapsula cómo interactúa un conjunto de objetos. El mediador promueve el acoplamiento flexible evitando que los objetos se refieran entre sí de forma explícita, y le permite variar su interacción de forma independiente.

Un ejemplo del mundo real de la topología de red Mesh se ha proporcionado en la siguiente pregunta SE:

Mediator Vs Observer Patrones de diseño orientados a objetos

En cuanto a su consulta sobre Mediator agrega responsabilidad:

1. Facade proporciona solo una interfaz para subsistemas existentes . Los subsistemas existentes no conocen la clase de Fachada en sí.

2. El mediador conoce los objetos del colega . Permite la comunicación entre diferentes colegas. En el ejemplo que he citado en una pregunta vinculada, ConcreteMediator ( NetworkMediator ) envía notificaciones de registro y anulación del registro de un colega a todos los demás colegas.

Answer 7

Tome una simple analogía:

Fachada: como un estacionamiento, cuando llame

parkingLot.Out(car1);

mab ser una simple cadena funciona:

{
  car1.StartEngin();      
  attendant.charge();
  car1.driverOut();
}

Mediador: como semáforo.

Hay interacciones entre la luz y el automóvil,

y los autos están controlados por su estado.

Pensé que tal vez este es el mediador "agrega funcionalidad"

Y sobre la definición:

Tipo de fachada: estructural

Tipo de mediador: comportamiento

fachada más preocupada por los componentes que estaban contenidos en la interfaz unificada ,

y el mediador se preocupan por cómo interactúan un conjunto de objetos.

Answer 8

bajo patrones relacionados, gof dice: Facade (185) difiere de Mediator en que abstrae un subsistema de objetos para proporcionar una interfaz más conveniente. Su protocolo es unidireccional; es decir, los objetos de fachada hacen solicitudes de las clases de subsistema, pero no al revés. Por el contrario, Mediator permite el comportamiento cooperativo que los objetos del colega no pueden o no pueden proporcionar, y el protocolo es multidireccional.