Wird die Verwendung des Mediatormusters empfohlen?

Question

http://addyosmani.com/resources/essentialjsdesignpatterns/book/#mediatorpatternjavascript

Ich verstehe das Mediator-Muster als eine Art von Objekt, das Publish und Subscribe-Funktionalität eingerichtet.

Normalerweise richte ich Objekte ein, die bereits die Methoden subscribe(), publish() bereitstellen. Concrete Objects erweitern dieses Basisobjekt, sodass subscribe() und publish() immer als Prototypattribute registriert werden.

Wie ich richtig verstehe, wird das Mediator-Muster verwendet, um einem Objekt die publish-subscribe-Methoden hinzuzufügen.

Was ist der Vorteil dieser Praxis? Ist es nicht besser, ein Basisobjekt mit Publish- und Subscribe-Funktionen auszustatten, als einen Mediator bei der Konstruktion einzurichten?

Oder habe ich das Mediatormuster falsch verstanden?

Grüße

Answer 1

Als das, was ich einige Zeit von ähnlichen Beiträgen vor gelernt habe:

• Die Mediator-Muster zu verwenden, um Module einen Standard-API zur Verfügung stellen.

  ein Beispiel Lassen Sie haben:

  Ihre App tausende Module stützen sich stark auf jQuery $.post. Wenn Ihr Unternehmen plötzlich Probleme bei der Lizenzierung hat und sich entschieden hat, zum Beispiel zu MooTools oder YUI zu wechseln, würden Sie nach dem ganzen Code suchen, der $.post verwendet, und sie durch etwas wie MooTools.post ersetzen?

  Das Mediatormuster löst diese Krise, indem es die API normalisiert. Was die Module wissen, ist, dass Ihr Mediator eine Post-Funktion hat, die AJAX veröffentlichen kann, unabhängig davon, welche Bibliothek verwendet wurde.

  //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 
  

• Der Mediator dient als „Mann in der Mitte“ für Zwischenmodulkommunikation.

  Ein Problem in der Entwicklung von Newbie-JS ist, wenn Module voneinander abhängig sind. Das ist, wenn:

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

  Aber was, wenn etwas nicht in Ordnung ist in MyClassB und der Entwickler hat sie aus dem Build. Würdest du den gesamten Code in MyClassA suchen und entfernen, der MyClassB verwendet, so dass er aufgrund der Abwesenheit von MyClassB nicht bricht?

  Die Muster publish und subscribe des Mediatormusters lösen dies, indem das Modul ein Ereignis abonnieren lässt, anstatt direkt mit den anderen Modulen zu kommunizieren. Der Mediator fungiert als eine Sammlung von Callbacks/Abonnements, die ausgelöst werden, wenn Ereignisse veröffentlicht werden.

  Diese "anonyme" Anmeldung resultiert in teilweise lose-Kopplung. Module müssen immer noch wissen, auf welche Module sie hören sollen oder zumindest eine Reihe von Ereignissen, die sie hören können, aber sie sind so miteinander verbunden, dass sie nicht kaputt gehen, wenn einer von ihnen herausgenommen wird.Alles, was sie wissen, ist, dass sie das Ereignis abonniert haben und ausführen werden, wenn dieses Ereignis eintritt - unabhängig davon, wer es auslöst, ob es überhaupt feuert oder ob der Auslöser existiert.

Answer 2

Sie können eine Mediation ohne Verwendung von Eventing (Pub/Sub) erreichen. In komplexen/komplexen Abläufen kann es schwierig sein, Code zu debuggen oder zu begründen, der rein ereignisgesteuert ist.

Für ein Beispiel, wie man einen Mediator ohne pub/sub erstellen kann, können Sie einen Blick auf meinem Projekt jQueryMediator nehmen: https://github.com/jasonmcaffee/jQueryMediator