¿Se recomienda el uso del patrón mediador?

Question

Actualmente estoy leyendo http://addyosmani.com/resources/essentialjsdesignpatterns/book/#mediatorpatternjavascript

Entiendo el patrón del mediador como un tipo de objeto que configura la funcionalidad de publicar y suscribir.

Normalmente estoy configurando objetos que ya proporcionan métodos de suscripción(), publish(). Los objetos concretos extienden este objeto base para que suscribir() y publicar() siempre se registren como atributos de prototipo.

Como entiendo bien, el patrón del mediador se usa para agregar los métodos publish-subscribe a un objeto.

¿Cuál es el beneficio de esta práctica? ¿No es una práctica mejor proporcionar un objeto base con funciones de publicación y suscripción que dejar que un mediador configure en la construcción?

¿O he entendido mal el patrón del mediador?

Saludos

Answer 1

como lo que he aprendido de mensajes similares hace algún tiempo:

• El patrón mediador proporciona una API estándar para módulos de usar.

  Tengamos un ejemplo: miles

  Tu de aplicaciones de módulos dependen en gran medida de jQuery $.post. Si, de repente, su empresa tuviera problemas de licencia y decidiera pasar a, por ejemplo, MooTools o YUI, ¿buscaría todo el código que usa $.post y los reemplazaría con algo como MooTools.post?

  El patrón del mediador soluciona esta crisis mediante la normalización de la API. Lo que saben los módulos es que su mediador tiene una función de publicación que puede hacer publicaciones AJAX independientemente de la biblioteca que se haya utilizado.

  //module only sees MyMediator.post and only knows that it does an AJAX post 
  //How it's implemented and what library is used is not the module's concern 
  
  jQuery.post -> MyMediator.post -> module 
  MooTools.post -> MyMediator.post -> module 
  YUI.post  -> MyMediator.post -> module 
  

• El mediador sirve como el "medio-hombre" para la comunicación intermódulos.

  Un problema en el desarrollo JS novato es cuando los módulos son interdependientes. Es decir, cuando:

  MyClassA.something = MyClassB.method(); 
  MyClassB.something = MyClassA.method(); 
  

  Pero lo que si algo está mal en MyClassB y el desarrollador lo sacó de la construcción. ¿Buscaría y eliminaría todo el código en MyClassA que usa MyClassB para que no se rompa debido a la ausencia de MyClassB?

  El patrón del mediador publish y subscribe resuelve este patrón haciendo que el módulo se suscriba a un evento en lugar de interactuar directamente con los otros módulos. El mediador actúa como una colección de devoluciones/suscripciones que se activan cuando se publican los eventos.

  Esta suscripción "anónima" da como resultado parcial flojo-acoplamiento. Los módulos aún necesitarían saber qué módulos escuchar o al menos un conjunto de eventos para escuchar, pero están conectados de manera que no se rompen si se saca alguno de ellos.Todo lo que saben es que se suscribieron al evento y se ejecutarán cuando ocurra ese evento, independientemente de quién lo dispare, si se dispara o si el activador existe.

Answer 2

Puede lograr la mediación sin utilizar eventos (pub/sub). En flujos complejos/sofisticados, puede ser un reto depurar o razonar sobre un código puramente basado en eventos.

Para un ejemplo de cómo se puede crear un mediador sin pub/sub, puede echar un vistazo a mi proyecto jQueryMediator: https://github.com/jasonmcaffee/jQueryMediator