23 Design Modes (7): Broker mode

Source: Internet
Author: User

Definition: Encapsulates a series of object interactions with a mediator object, which causes the objects to be loosely coupled and can independently change the interaction between them without displaying the interaction of the objects.

Type: Behavior class pattern.

Class Diagram:

The structure of the mediator pattern:

The mediator pattern, also known as the mediator pattern, is divided into 3 parts from the class diagram:

Abstract 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.

Why to use the Mediator mode:

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 changes, then 4 objects will be affected. If object 2 changes, then 5 objects will be affected. In other words, the design of the direct association between colleague classes is not good.

If you introduce the mediator pattern, then the relationship between the colleague classes becomes a star structure, and you can see that the change of any one class only affects the class itself and 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.

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 {Protectedint number;PublicIntGetNumber () {return number; }PublicvoidSetnumber (int number) {This.number = number; }Abstract method, modifying the associated object at the same time when modifying a numberPublicAbstractvoidSetnumber (int number, Abstractcolleague coll); } class Colleaguea extends abstractcolleague{PublicvoidSetnumber (int number, Abstractcolleague coll) {This.number = number; Coll.setnumber (number*100); }} class Colleagueb extends abstractcolleague{PublicvoidSetnumber (int number, Abstractcolleague coll) {This.number = number; Coll.setnumber (number/100); } }PublicClass 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.

Abstract class Abstractcolleague {Protectedint number;PublicIntGetNumber () {return number; }PublicvoidSetnumber (int number) {This.number = number; }Note that the argument here is no longer a colleague class, but a mediatorPublicAbstractvoidSetnumber (int number, abstractmediator am); } class Colleaguea extends abstractcolleague{PublicvoidSetnumber (int number, abstractmediator am) {This.number = number; Am. AAFFECTB (); }} class Colleagueb extends abstractcolleague{@OverridePublicvoidSetnumber (int number, abstractmediator am) {This.number = number; Am. Baffecta (); } }Abstract class Abstractmediator {protected Abstractcolleague A;protected Abstractcolleague B;PublicAbstractmediator (Abstractcolleague A, Abstractcolleague b) {a = A; b = b; }PublicAbstractvoidAAFFECTB ();PublicAbstractvoidBaffecta (); } class Mediator extends Abstractmediator {PublicMediator (Abstractcolleague A, Abstractcolleague b) {super (A, b);}Dealing with the effect of A on BPublicvoidAAFFECTB () {int number = A.getnumber (); B.setnumber (number*100); }Dealing with the effect of B on aPublicvoidBaffecta () {int number = B.getnumber (); A.setnumber (number/100); } }PublicClass Client {PublicStaticvoidMain (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 ( 1000, AM); System. out.println ("the number value of CollA is:" +colla.getnumber ()); System. out.println ("COLLB's number is a  10 times times:" +collb.getnumber ()); System. out.println ("========== by setting B effect a=========="); Collb.setnumber ( 1000, AM); System. out.println ("the number value of COLLB is:" +collb.getnumber ()); System. out.println ("CollA's number value is B's  0.1 times times:" +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 of the broker mode:

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

2, using the mediator pattern can transform one-to-many associations between objects into one-to-one associations, making relationships between objects easy to understand and maintain.

3, the use of the mediator mode can be the object's behavior and collaboration to abstract, can be more flexible to deal with the interaction between objects.

Applicable scenarios:

1, 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.

2, the intermediary mode is a more commonly used mode, 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.

23 Design Modes (7): Broker mode

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.