Win a copy of Re-engineering Legacy Software this week in the Refactoring forum
or Docker in Action in the Cloud/Virtualization forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

More than one facade ??

 
Jose Jim´┐Żnez
Ranch Hand
Posts: 101
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
author
Ranch Hand
Posts: 608
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Ryan McGuire
Ranch Hand
Posts: 1055
4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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. )
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic