The mediator pattern for Java design Patterns

This article continues The 23 design pattern series of the intermediary model.

definitionencapsulating a series of object interactions with a mediator object, the mediator makes the objects do not need to be shown to interact with each other, which makes the coupling loose and can change the interaction between them independently.
roleAbstract Mediator: Defines the interface of the colleague class object to the mediator object for communication between the individual colleague classes. Typically includes one or several abstract event methods, and is implemented by subclasses. The Mediator implementation class: inherits from the abstract mediator and implements the event method defined in the abstract mediator. Receives a message from a colleague class and then affects other concurrent classes through the message. colleague Class: If an object affects other objects and is also affected by other objects, these two objects are called colleague classes. In the class diagram, the colleague class has only one, this is actually the omission of reality, in the actual application, the colleague class generally consists of many, they influence each other and depend on each other. The more co-workers, the more complex the relationship. Also, a colleague class can be represented as a set of implementations that inherit the same abstract class. In the mediator mode, the peer class must pass through the mediator to deliver the message.
Where applicable

In general, the relationship between colleague classes is more complex, and when multiple colleague classes are interrelated, their relationship is presented as a complex network structure, an overly-coupled architecture that is not conducive to the reuse of classes and is not stable. For example, there are six colleague class objects, and if object 1 is changed, 4 objects will be affected. If object 2 changes, then 5 objects are affected. In other words, the design of the direct association between colleague classes is not good.

If the intermediary mode is introduced, then the relationship between the colleague classes becomes the star structure, and the changes of any class will only affect the class itself, as well as the mediator, thus reducing the coupling of the system. A good design must not encapsulate all of the object relational processing logic in this class, but instead use a specialized class to manage behaviors that are not theirs.

Application

We use an example to illustrate what a colleague class is: There are two classes A and B, each with a number in the class, and to ensure that the number in class B is always 100 times times the number in Class A. That is, when you modify the number of Class A, multiply this number by 100 and assign it to Class B, while modifying Class B assigns the number divided by 100 to Class A. Class A b affects each other and is called a colleague class. The code is as follows:

Abstract class Abstractcolleague {      protected int number;        public int GetNumber () {          return number;      }        public void Setnumber (int number) {          this.number = number;      }      Abstract method, modify the number while modifying the associated object public      abstract void setnumber (int numbers, Abstractcolleague coll);  }  

Class Colleaguea extends abstractcolleague{public      void Setnumber (int number, Abstractcolleague coll) {          This.number = number;          Coll.setnumber (number*100);      }  }  

class COLLEAGUEB extends abstractcolleague{public void Setnumber (int. number, Abstractcolleague coll) {this          . Number = number;      Coll.setnumber (number/100); }  } 

public class Client {public      static void Main (string[] args) {            Abstractcolleague CollA = new Colleaguea ();          Abstractcolleague collb = new Colleagueb ();                    System.out.println ("========== set a influence b==========");          Colla.setnumber (1288, collb);          SYSTEM.OUT.PRINTLN ("Number Value of CollA:" +colla.getnumber ());          SYSTEM.OUT.PRINTLN ("Number Value of COLLB:" +collb.getnumber ());            System.out.println ("========== set B affects a==========");          Collb.setnumber (87635, CollA);          SYSTEM.OUT.PRINTLN ("Number Value of COLLB:" +collb.getnumber ());          SYSTEM.OUT.PRINTLN ("Number Value of CollA:" +colla.getnumber ());      }  }  

In the above code, Class A B has a relationship through a direct association, and if we want to use the mediator pattern, the Class A Class B is not directly related, they must be through a mediator to achieve the purpose of the association.

Colleague Class

Abstract class Abstractcolleague {      protected int number;        public int GetNumber () {          return number;      }        public void Setnumber (int number) {          this.number = number;      }      Note that the parameter here is no longer a colleague class, but a mediator public      abstract void Setnumber (int number, abstractmediator am);  } class Colleaguea Extends abstractcolleague{public        void Setnumber (int number, abstractmediator am) {          this.number = number;          Am. AAFFECTB ();      }  }    Class Colleagueb extends abstractcolleague{        @Override public      void Setnumber (int number, abstractmediator am) {          this.number = number;          Am. Baffecta ();      }  }  

Abstract Mediator Class

Abstract class Abstractmediator {      protected abstractcolleague A;      protected Abstractcolleague B;            Public Abstractmediator (Abstractcolleague A, Abstractcolleague b) {          a = A;          b = b;      }        public abstract void Aaffectb ();            public abstract void Baffecta ();    }  

Intermediary class

Class Mediator extends Abstractmediator {public        mediator (Abstractcolleague A, Abstractcolleague b) {          super (A, B );      }        The effect of A on B is dealt with public      void Aaffectb () {          int number = A.getnumber ();          B.setnumber (number*100);      }        Deal with the effect of B on a public      void Baffecta () {          int number = B.getnumber ();          A.setnumber (number/100);      }  }  

Client

public class Client {public      static void Main (string[] args) {          Abstractcolleague CollA = new Colleaguea ();          Abstractcolleague collb = new Colleagueb ();                    Abstractmediator am = new Mediator (CollA, collb);                    System.out.println ("========== by setting a influence b==========");          Colla.setnumber (AM);          SYSTEM.OUT.PRINTLN (the number value of the CollA is: "+colla.getnumber ());          System.out.println ("The number of the COLLB is 10 times times the value of a:" +collb.getnumber ());            System.out.println ("========== by setting B influence a==========");          Collb.setnumber (AM);          SYSTEM.OUT.PRINTLN (the number value of the COLLB is: "+collb.getnumber ());          System.out.println ("CollA" is 0.1 times times the number of B: "+colla.getnumber ());                }  

Although the code is relatively long, but it is relatively easy to understand, in fact, the original processing object relationship code to a mediation class, through this intermediary class to deal with the relationship between objects.

Advantages

Proper use of the mediator pattern avoids over-coupling between colleague classes, making it possible to use the peer classes relatively independently.

Using the mediator pattern, you can transform a one-to-many association between objects into one-to-one associations, making relationships between objects easy to understand and maintain.

Using the mediator pattern, you can abstract the behavior and collaboration of objects, and be able to manipulate the interaction between objects more flexibly.

Summarize

In object-oriented programming, a class is bound to have dependencies on other classes, and completely independent classes are meaningless. It is also quite common for a class to rely on multiple classes at the same time, since there is a case that a one-to-many dependency has its rationality, and proper use of the mediator pattern can make the original messy object relationship clear, but if abused, it can have a reverse effect. In general, the use of the mediator pattern is only considered if the relationship between the peer class is a network structure. The mesh structure can be transformed into a star-like structure, making the relationship between colleague classes clearer.

The intermediary mode is a kind of more commonly used pattern, and it is also a more easily abused mode. For most cases, the relationship between colleague classes is not complex to a cluttered network structure, so in most cases it is possible to encapsulate the dependencies between objects within a colleague class, and there is no need to introduce a mediator pattern. Abusing the broker model will only make things more complicated.

More Design Patterns:23 design Mode series

jason0539

Blog: http://blog.csdn.net/jason0539 (reprint please indicate the source)

Recommended scan code pay attention to the public number, the different things

The mediator pattern for Java design Patterns