The difference between facade and mediator model

Http://www.cnblogs.com/sweetdream/archive/2005/12/19/299983.html

The façade (facade) model and the Mediator (mediator) model have a common purpose. They are all communications that provision a set of mutually-coupled objects. However, the façade mode is concerned with how this group of complex objects communicates with the outside world, while the mediator pattern is the provision of communication between this complex set of objects.

Façade (facade) mode
Façade mode can be used when you want to provide a simple and specific interface for a set of complex and comprehensive interface objects for external use.
The façade pattern is not difficult to understand, but finding the right size of the façade is not so easy. [GOF95] said: "A common design goal is to minimize inter-subsystem communication and interdependence to achieve the least way to achieve this goal is to introduce a façade object, which provides a single and simple interface for the more general facilities in the subsystem. "I think that although users do not have to deal directly with the classes in the subsystem, they are also indirectly connected through the façade (this may be possible to isolate changes with adapter mode). The main purpose of façade mode I don't think it's about reducing dependencies (if you include indirect dependencies), but simplifying the user interface. Façade mode is inconsistent with the principle of interface isolation. But then again, if the size of the façade selection is appropriate, then the advantages outweigh the disadvantages.

Application of Façade mode:
When you want to provide a simple interface for a complex subsystem. Subsystems tend to become more complex as they evolve. Most patterns will produce more and smaller classes when used. This makes the subsystem more reusable and easier to customize the subsystem, but it also brings some usability difficulties to users who do not need to customize the subsystem. Facade can provide a simple default view that is sufficient for most users, and those who need more customization can cross the facade layer.
The introduction of facade separates this subsystem from customers and other subsystems, which can improve the independence and portability of subsystems.
When you need to build a hierarchical subsystem, use the facade pattern to define the entry points for each layer in the subsystem, and if the subsystems are interdependent, you can allow them to communicate only through facade, simplifying their dependencies.

The structure of the façade pattern:

Façade (facade) role: The client can invoke the method of this role. This role is aware of the functions and responsibilities of the related (one or more) subsystems. Under normal circumstances, this role will delegate all requests from the client to the appropriate subsystem.

subsystem (SUBSYSTEM) Role: You can have one or more subsystems at the same time. Each subsystem is not a separate class, but a collection of classes. Each subsystem can be called directly by the client or by a façade role. Subsystems do not know the presence of the façade, for the subsystem, the façade is just another client only.
Note that façade can be implemented with abstract classes and its specific subclasses correspond to different subsystem implementations, which can further reduce the coupling between the client and the subsystem. This allows the client to communicate with the subsystem through an abstract façade class interface. This abstract coupling makes the client unaware that it is using a subsystem to achieve that.

Mediator (mediator) mode
A mediation object is used to encapsulate the interaction of a series of objects called colleague in this pattern. The mediator makes the objects not need to be referenced by each other, so that they are loosely coupled and can independently change the interaction between them (only the mediator class is changed). <<java and Model >> have a comparative image of the example, is China's accession to the WTO, and foreign trade do not have to negotiate with each country, and as long as the agreement with the WTO can be. The WTO has played an intermediary role here.
Consider a form in which there are many controls, such as Button,textbox,listbox, which are interactive, such as if there are no characters in the TextBox, then the state of the Button is unenable, and when the option to change the listbox The item selected in the ListBox is displayed in the TextBox. If the relationship between these objects is usually designed to be complex and poorly managed, there is no third party to organize them, creating a high degree of coupling, and in the worst case, every object needs to know about other objects, maintainability is compromised, and the logic of interaction is encapsulated in its own class. The likelihood of reuse is greatly compromised.
We can avoid this problem by encapsulating the collective behavior in a separate mediator object. The mediator is responsible for controlling and coordinating the interaction between a set of objects. The mediator acts as a mediator so that the objects in the group no longer display references to each other. These objects only know the mediator, thereby reducing the number of interconnected connections.

The structure of the mediator pattern:


Mediator (intermediary)
A mediator defines an interface for communicating with each colleague (colleague) object.
Concretemediator (Specific intermediary)
The specific mediator realizes the collaborative behavior by coordinating the colleagues ' objects.
Understand and maintain all of its colleagues.
Colleague (colleague Class)
Each colleague class is aware of its mediator object.
Each colleague object communicates only with its intermediaries when it is necessary to communicate with other colleagues.

Collaboration: A colleague sends and receives requests to a mediator object. The mediator forwards the request appropriately among colleagues to achieve collaborative behavior.
From the structure chart we can see that the mediator knows all the colleague classes, so that they can dispatch them, so it is possible to say that the mediator pattern is the complexity of changing the complexity of the interaction into a mediator. Each colleague class, in turn, knows its intermediary object so that it can notify the mediator when its state changes, thus affecting other colleague classes.  (Here are two ways to implement 1.)  Can use the observer mode; 2. A special notification interface is defined in mediator, where each colleague invokes the interface directly and passes itself as a parameter to mediator to identify the sender. )。 Such coupling seems to violate the principle of interface isolation like the façade model: if the interface of a colleague class changes, then the intermediary will also change, so that all the colleague classes have to change. Here is a cyclic dependency, and each class interface change can cause all classes to change. But one of the main purposes of this model is to simplify the means of communication rather than isolate changes in the colleague class. Let's see Gof describes the applicability of this pattern:
1. A set of objects is well-defined (note here that it is well-defined, if the colleague class needs to change the interface frequently, be careful) but the complex way to communicate. The resulting interdependence structure is confusing and difficult to understand.
2. An object that references many other objects and communicates directly with those objects makes it difficult to reuse the object. (An object is difficult to reuse if it is associated with too many other objects)
3. Want to customize a behavior that is distributed across multiple classes without having to generate too many subclasses. (as mentioned above, changing the state of a control can cause other controls to change)

Advantages and disadvantages of the broker pattern:
1. Reducing the generation of subclasses mediator the behavior that is originally distributed across multiple objects. Changing these behaviors requires only the generation of mediator subclasses.
2. The decoupling of each colleague mediator is advantageous to the loose coupling among the colleague classes. You can change and reuse each colleague class and the Mediator class independently.
3. It simplifies the object protocol to replace many-to-many interactions with a one-to-many interaction between the mediator and the colleague. A one-to-many relationship is easier to understand. Maintenance and expansion.
4. It abstracts how objects work together and encapsulates the mediation as a separate concept into an object, allowing you to shift your attention from the behavior of the objects themselves to the interactions between them. This helps to figure out how the objects in a system interact.
5. It makes the control centralization of the mediator pattern the complexity of the interactions into intermediaries. Because the broker encapsulates the protocol, it can be more complex than any one colleague. This may make intermediaries themselves a hard-to-maintain behemoth.

Facade mode is an object association relation between decoupling system and inside system (unidirectional), and mediator mode is the correlation relation between each object in the decoupling system (bidirectional).