Broker mode
The mediator pattern is a good interpretation of the Dimitri rule, and if you need to correlate any two unrelated objects, you need to do so through a third class. Intermediaries are the encapsulation of a group of objects, shielding the interaction details between classes, so that different classes directly do not need to hold the other side of the reference can also be accessed.
The mediator mediator holds a reference to the colleague class (that is, the object that needs to handle the interaction logic) colleague, and each colleague also holds a mediator reference. This colleague if any request to interact with the other class is sent to mediator, the reorganization object is understood to be coupled. In fact, we usually write the view controller itself is an intermediary, it to control the interaction between different objects.
Application Scenarios
Inter-object interactions, while clearly defined and complex, result in a set of objects that are interdependent and difficult to understand;
Objects are difficult to reuse because they refer to many other objects and communicate with them.
You want to customize a logic or behavior that is distributed across multiple classes, and you don't want to generate too many subclasses.
The pros and cons of intermediaries
Advantages
Mediator appears to reduce the coupling of each colleague, allowing individual colleague classes and mediator to be independently changed and reused, by abstracting how objects are written, and by encapsulating the mediator as an independent concept and enclosing it in an object. The object of such attention shifts from the behavior of the objects themselves to the interaction between them, that is, to stand in a more macroscopic view of the system.
Disadvantages
Because Concretemediator controls centralization, it turns the interaction complexity into the complexity of the mediator, which makes the intermediaries more complex than any one concretecolleague.
Demo
Colleague
#import<Foundation/Foundation.h>@classMediator;@interfaceColleague:nsobject@property (nonatomic, weak) mediator*Mediator;-(Instancetype) Initwithmediator: (Mediator *) mediator;-(void) Notifyanother;-(void) Notified: (NSString *) message;@end#import "Colleague.h"#import "Mediator.h"@implementationcolleague-(Instancetype) Initwithmediator: (Mediator *) mediator{ Self=[Super Init]; if(self) {_mediator=Mediator; } returnSelf ;}-(void) Notified: (NSString *) message{NSLog (@"%@", message);}-(void) notifyanother{[Self.mediator notify:self];}@end#import "Colleague.h"@interfaceConcretecolleaguea:colleague@end#import "ConcreteColleagueA.h"@implementationConcretecolleaguea@end#import "Colleague.h"@interfaceConcretecolleagueb:colleague@end#import "ConcreteColleagueB.h"@implementationConcretecolleagueb@end
In OC, in order to avoid reference loops, the colleague Mediator object modifier is used with weak
Mediator
#import<Foundation/Foundation.h>#import "ConcreteColleagueA.h"#import "ConcreteColleagueB.h"@interfaceMediator:nsobject@property (nonatomic, strong) Concretecolleaguea*Colleaguea, @property (nonatomic, strong) Concretecolleagueb*Colleagueb;-(void) Notify: (NSObject *) obj;@end#import "Mediator.h"@implementationMediator-(ID) init{ Self=[Super Init]; if(self) {}returnSelf ;}-(void) Notify: (NSObject *) obj{if(obj = =Self.colleaguea) {[Self.colleagueb notified:@"B notified"]; } Else{[Self.colleaguea notified:@"A notified"]; }}@end
Client
Mediator *mediator = [[Mediator alloc] init]; *colleaguea = [[Concretecolleaguea alloc] initwithmediator:mediator]; *colleagueb = [[Concretecolleagueb alloc] initwithmediator:mediator]; = Colleaguea; = Colleagueb; [Colleaguea Notifyanother]; [Colleagueb Notifyanother];
--+:42.508 mediator[3888:1799182 ] B notified--:42.509 mediator[3888:1799182] A notified
Objective-c design Pattern-Mediator Mediator (object decoupling)