Package with a series of object interaction objects intermediary, intermediaries keeping objects displayed interacts, so that loose coupling, and can be changed independently of the interaction between them.
Intermediary model yet mediator pattern, as viewed from the class diagram, divided into three parts:
- Abstract Mediator: colleague defined class object to the interface object intermediary for communications between the various classes colleagues. Typically include one or more abstract event methods by subclasses to achieve.
- Mediator implementation class: inherited from the abstract Mediator, Mediator abstract realization event methods defined. Receiving a message from a colleague class, then the class by simultaneously affect other message.
- Colleagues categories: If an object can affect other objects, will also be affected by other objects, then these two objects called colleagues class. In the class diagram, there is only one class colleagues, this is actually the reality of omission, in practical application, colleagues class generally consists of multiple components, they affect each other, are interdependent. The more colleagues class, the more complex relationships. And colleagues class can also be expressed as a composition with a group of inherited implement an abstract class. In the intermediary model, the class must to colleagues for messaging through intermediaries.
Why use intermediary model
In general, the relationship between colleagues class is more complex, interrelated when colleagues across multiple classes, the relationship between them will appear as a complex network structure, which is an over-coupled architecture, that is not beneficial reuse category, not stable. For example in the figure, there are six colleagues class object, if the object 1 changes, then there will be four objects affected. If the object 2 changes, then there will be five objects are affected. In other words, design a direct correlation between colleagues class is bad.
If the introduction of intermediary model, the relationship between colleagues class will become the star structure can be seen from the figure, a change in any class, it will only affect the class itself, as well as intermediaries, thus reducing the system coupling. A good design, will not put all the object-relational processing logic is encapsulated in this class, but the use of a special class to manage behavior that is not his own.
Source
#include <iostream>
#include <string>
#include <unordered_map>
namespace mediator_pattern {
class abstract_mediator;
class abstract_colleague
{
public:
virtual void send_message(int, std::string) = 0;
virtual void receive_message(std::string) = 0;
virtual void set_mediator(abstract_mediator* mediator) {
mediator_ = mediator;
}
protected:
abstract_mediator *mediator_;
}; // class abstract_colleague
class abstract_mediator {
public:
virtual void operation(int, std::string) = 0;
virtual void register_colleague(int, class abstract_colleague
*) = 0;
};// class abstract_mediator
class concrete_colleague_1 : public abstract_colleague{
public:
void send_message(int id, std::string message) override {
std::cout << "concrete_colleague_1 will send message: [" << message << "] to " << std::to_string(id) << std::endl;
mediator_->operation(id, message);
}
void receive_message(std::string message) override {
std::cout << "concrete_colleague_1 => receive_message : [" << message << "]" << std::endl;
}
}; // class concrete_colleague_1
class concrete_colleague_2 : public abstract_colleague{
public:
void send_message(int id, std::string message) override {
std::cout << "concrete_colleague_2 will send message: [" << message << "] to " << std::to_string(id) << std::endl;
mediator_->operation(id, message);
}
void receive_message(std::string message) override {
std::cout << "concrete_colleague_2 => receive_message : [" << message << "]" << std::endl;
}
}; // class concrete_colleague_2
class concrete_mediator : public abstract_mediator {
public:
void operation(int id, std::string message) override {
std::cout << "concrete_mediator - operation => will send message: [" << message << "] to " << std::to_string(id) << std::endl;
lists_[id]->receive_message(message);
}
void register_colleague(int id, abstract_colleague* colleague) override {
lists_[id] = colleague;
colleague->set_mediator(this);
}
private:
std::unordered_map<int, abstract_colleague *> lists_;
}; // class concrete_mediator
}// namespace mediator_pattern
int main() {
mediator_pattern::concrete_mediator _concrete_mediator;
mediator_pattern::concrete_colleague_1 _concrete_colleague_1;
mediator_pattern::concrete_colleague_2 _concrete_colleague_2;
_concrete_mediator.register_colleague(1, &_concrete_colleague_1);
_concrete_mediator.register_colleague(2, &_concrete_colleague_2);
_concrete_colleague_1.send_message(2, "message from _concrete_colleague_1 to _concrete_colleague_2");
std::cout << std::endl;
_concrete_colleague_2.send_message(1, "message from _concrete_colleague_2 to _concrete_colleague_1");
return 0;
}
The output is:
concrete_colleague_1 will send message: [message from _concrete_colleague_1 to _concrete_colleague_2] to 2
concrete_mediator - operation => will send message: [message from _concrete_colleague_1 to _concrete_colleague_2] to 2
concrete_colleague_2 => receive_message : [message from _concrete_colleague_1 to _concrete_colleague_2]
concrete_colleague_2 will send message: [message from _concrete_colleague_2 to _concrete_colleague_1] to 1
concrete_mediator - operation => will send message: [message from _concrete_colleague_2 to _concrete_colleague_1] to 1
concrete_colleague_1 => receive_message : [message from _concrete_colleague_2 to _concrete_colleague_1]
to sum up
A little dizzy, need information when submitting a request to the mediator.
As for who process information, there may be two:
- Mediator Custom
- The person requesting information requirements
Is that right? ?
If a request belonging to a particular behavior, specify a particular recipient? ?
