File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes OO, Patterns, UML and Refactoring and the fly likes More than one facade ?? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "More than one facade ??" Watch "More than one facade ??" New topic

More than one facade ??

Jose Jim�nez
Ranch Hand

Joined: Jun 15, 2005
Posts: 101
Is correct for example create one only facade BookingFacade to expose methods about Customer, Order , and Cart .

Or is more correct create one facade for each entity (Customer, Order, ... )??

Why ??? Thanks .

Scott Ambler
Ranch Hand

Joined: Dec 12, 2003
Posts: 608
You might want to create several facades for an entity to reflect their usage. You could have an AdministrationFacade and a OnlineShoppingFacade for example.

- Scott

<a href="" target="_blank" rel="nofollow">Scott W. Ambler</a><br />Practice Leader Agile Development, IBM Rational<br /> <br />Now available: <a href="" target="_blank" rel="nofollow">Refactoring Databases: Evolutionary Database Design</a>
Ryan McGuire
Ranch Hand

Joined: Feb 18, 2005
Posts: 1044
Given the information you/ve supplied, I would say that if you want a facade, then you want only one facade to wrap all the lower level classes.

The purpose of the Facade Pattern is to provide a single point of access to a subsystem of implementation classes. If you provide a separate facade for each class of object in the subsystem (so that client objects need to know and track which object implements any given piece of functionality), then you're going against the whole reason for using the Facade Pattern in the first place.

If one of the implementation classes (Customer, Order, etc.) changes, do the client objects also have to change? If so, then there's a problem with your design of the Facade Pattern. If the implementation classes change, then the facade object might have to change, but the interface that the facade object presents to the outside world should stay the same.

However, this might be just a terminology issue. When you talk about one facade for Customer, one for Order, etc., I suspect that you're talking about some kind(s) of wrappers for the objects. For instance I could see someone (mistakenly) calling an EJB a "facade" for Order records in the database. While having an Order EJB, a Customer EJB, etc. is reasonable, those EJBs don't really count as facades.

Of course you might have multiple facades that wrap the implmentation object in different ways or for different purposes. The example that the GoF use the Facade Pattern is a Compiler facade that wraps the pieces that go into a compiler (parser, code generator, linker, etc.). I could see another facade around those same classes if they could be used in other contexts. For instance, perhaps a word processor could use the parser to perform "mail merge" functionality. In this case you could have a TextProcessorFacade in addition to the original CompilerFacade.

Summary: The Facade Pattern is used when you want to hide the complexity of a subsystem of classes/objects, not when you're wrapping just a single class/object.

(I see that Mr. Ambler replied to the original post while I was composing my reply. It's heartwarming to see that we covered some of the same ground. )
I agree. Here's the link:
subject: More than one facade ??
It's not a secret anymore!