Sunday, November 18, 2012

Facade Design Pattern

Although they are lots of books and articles about Design Patterns, yet I like to share my point of view about common design patterns with you, and would be happy to have your thoughts or questions on comments. This post introduces GoF Facade design pattern.

Definition
Provide a unified interface to a set of interfaces in a subsystem. Fa├žade defines a higher-level interface that makes the subsystem easier to use. (dofactory)


  • Facade knows which subsystem classes are responsible for a request and delegates client requests to appropriate subsystem objects.
  • Subsystem classes implement subsystem functionality, handle work assigned by the Facade object and have no knowledge of the facade and keep no reference to it.



Applicability
  • A system has several identifiable subsystems and It is required to hide complexity and providing a simple API to client.
  • As the concept behind facade is to simplify an interface, service oriented architectures make use of the facade pattern.

Consequences
  • Wrap a complicated subsystem with a simpler interface.
  • Make a software library easier to use, understand and test, since the facade has convenient methods for common tasks and make the library more readable, for the same reason;
  • Reduce dependencies of outside code on the inner workings of a library, since most code uses the facade, thus allowing more flexibility in developing the system;
  • Wrap a poorly designed collection of APIs with a single well-designed API (as per task needs).

Downsides
  • By introducing the Facade into your code, you will be hardwiring subsystems into the Facade. This is fine if the subsystem never changes, but if it does, your Facade could be broken. Therefore, developers working on the subsystem should be made aware of any Facade around their code.
  • The Facade object should be a fairly simple advocate or facilitator. It should not become an all-knowing oracle or “god” object.

Sample Code

Related Patterns
  • Facade defines a new interface, whereas Adapter uses an old interface. Remember that Adapter makes two existing interfaces work together as opposed to defining an entirely new one. Adapter and Facade are both wrappers; but they are different kinds of wrappers. The intent of Facade is to produce a simpler interface, and the intent of Adapter is to design to an existing interface. While Facade routinely wraps multiple objects and Adapter wraps a single object; Facade could front-end a single complex object and Adapter could wrap several legacy objects.
  • Whereas Flyweight shows how to make lots of little objects, Facade shows how to make a single object represent an entire subsystem.
  • Mediator is similar to Facade in that it abstracts functionality of existing classes. Mediator abstracts/centralizes arbitrary communications between colleague objects. It routinely “adds value”, and it is known/referenced by the colleague objects. In contrast, Facade defines a simpler interface to a subsystem, it does not add new functionality, and it is not known by the subsystem classes.
  • Abstract Factory can be used as an alternative to Facade to hide platform-specific classes.
  • Facade objects are often Singletons because only one Facade object is required.

References
http://www.dofactory.com/Patterns/PatternFacade.aspx
http://en.wikipedia.org/wiki/Facade_pattern
http://sourcemaking.com/design_patterns/facade
http://java.dzone.com/articles/design-patterns-uncovered-1

Further readings
http://ayende.com/blog/159681/design-patterns-in-the-test-of-time-faccedil-ade
http://javapapers.com/design-patterns/facade-design-pattern/
http://blog.apigee.com/detail/api_facade_design_pattern_overview

No comments :

Post a Comment