Wednesday, February 25, 2009

Tom’s Patterns Cheat Sheet, Part 4 – Façade and Bridge Patterns

For this post I'm reverting to the original patterns Bible as my primary source, the GoF Design Patterns tome.

Façade

The Façade Pattern

Provides a simple interface to a complex subsystem. Helps decouple clients from the individual elements of a subsystem. Useful for enforcing layering of subsystems. Web service interfaces to legacy systems are good examples of the façade pattern:

Web Services Example of The Façade Pattern

Bridge Pattern

The Bridge Pattern

"Decouples an abstraction from an implementation." In other words, allows you to create a separate class hierarchy for the object model that the client cares about (the "abstraction") and for the object model that internally implements its functionality.

A trivial example might be a Customers class that internally uses an ADO recordset for data access:

Trivial application of the Bridge Pattern

This is a trivial case because the implementer can't be subclassed, but it could still be useful for cases where you want to be able to inject ADO recordsets with different data sources into your Customers object, without having to change the Customers class itself.

We can make this example slightly more sophisticated by replacing the recordset with a generic data access class that could be specialized to use ADO, XML, flat files or whatever:

Application of the Bridge Pattern

A good code sample of this type of application of the bridge pattern can be found here.

This is useful when

  • You would like to reuse the implementer outside the context of the abstraction. A recordset implementer is a good example of this.
  • You need the ability to swap out implementations at runtime. A recordset that can be configured to use multiple data sources is an example. Machine- or OS-specific implementations are another example, e.g. an XP v. Vista implementations.
  • You want to simplify the class hierarchies and/or provide greater extensibility flexibility by splitting up the system into separate class hierarchies for the abstraction and its implementation.

No comments:

Post a Comment

Followers