This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
With facade pattern you simplify an interface.
For example, imagine an app in wich you can have 3 situations A, B and C. In situation A you must call 4 methods of four different objects of differents classes, in situation B you should call 2 methods from classes X1 and X2, or 3 methods from classes Y1, Y2 and Y3 depending on a return value from another method on another object. In situation C you must call an asynchronous method from another object and then call another method passing as argument an event that resulted from previous asynchronous call. Sorry for such a crazy sample. It would be easier to have a class Facade that offered 3 methods, one for each situation. This Facade class should know all the mentioned classes and methods, that are unknown by the client: they're strangers for the client who only knows the facade (remember GRASP principle, don't talk to strangers).
With a mediator you have set of classes in wich every class could end up calling any other class methods in the set, UNLESS you avoid it with a mediator. This mediator would be the only dependece of all the rest of the classes in the set. You can see the mediator like a city in the center of a country: all the roads would connect this central city with another one (radial distribution). Or you can see it (I don't like at all this example) like a JMS topic to wich you send messages forgetting about who will receive them (the topic itself would be the mediator).
See the difference? The facade is like the only door for the clients who call from outside. Is a dependence for other classes outside my package. On the other hand, the mediator is like the post office to wich all people give mail in order not to go to every house they need to send a mail. Is a dependence for all the classes in the set, but is the only dependence.
Hope I helped you. Now I must go to bed, now it's very late in Spain jajaja ;) Bye
I feel there must be far better ways to do what I do... that makes learning even funnier
Joined: Apr 24, 2001
Muchas gracias Antonio. I am still not convinced though. Sorry about that.
Referring to the class diagrams and descriptions in MZs notes, is it fair to say that a Facade simplifies the interface between two sub-systems (an existing sub-system and a system under development). A Mediator on the other hand keeps objects in a sub-system from referring to each other explicitly i.e. it avoids coupling within a sub-system, while a Facade avoids coupling between sub-systems.
In general terminology, Facade is like a gateway and collects information or interacts with various sub-systems and pass the result back to client.
i.e. It is Unidirectional ; client and other sub-systems are separated by facade.
Where as Mediator sits at the center of all sub-systems , sub-systems inform specific information to mediator and mediator co-oridinates other sub-systems.
i.e. It is Multidirectional ; Mediator is surrounded by all sub-systems.
Hope this helps.
Joined: Aug 07, 2008
Prasanna Wamanacharya wrote:... is it fair to say that a Facade simplifies the interface between two sub-systems (an existing sub-system and a system under development).
Not just for a system under construction, but for every client that uses it. But remember, the classes inside that system/component/package don't know anything about the client, it's unidirectional like Srees Nivas said. It's only the client who knows about the system and access it via its facade without knowing the inner classes. Srees Nivas exlpained it perfectly, it's like a gateway.
Prasanna Wamanacharya wrote:A Mediator on the other hand keeps objects in a sub-system from referring to each other explicitly i.e. it avoids coupling within a sub-system
I absolutely agree.
I recommend you to read about GRASP if you didn't do it. Many of its principles are shown in this example: high cohesion, loose coupling, controller... It helps understand design patterns not by their structure, but by their intention, so that you can easily recognise the scenarios in wich to use each pattern. In fact, if you care much about a pattern's structure, then strategy, command and state patterns are almost the same one: you inject a behavior or another to a receiver class. Would you say the three patterns are the same one?
Prasanna Wamanacharya wrote:Except the fact that Facade is a structural pattern, and Mediator is a behavioral pattern, both the patterns look very similar to me.
I hope that we won't get both of them as choices in a question, and asked to choose one of them as the correct answer.
This is what I see is a difference in both:
If you have an API that needs to be used by your client hide the nitty gritties of understanding and handling the plethora of classes instead give a facade class to get the specific functions implemented for the application
I can see this more as a controller
and as you said both these are in different genere but look very similar.
Joined: Apr 24, 2001
Thank you Srees, Antonio and Sabarish. Your comments have been most helpful in understanding the differences and finer details.
Antonio, I will certainly read GRASP. Thanks for the tip.
In fact, if you care much about a pattern's structure, then strategy, command and state patterns are almost the same one: you inject a behavior or another to a receiver class. Would you say the three patterns are the same one?