12 Design Patterns:


Date: 01/sep/03






FAADE Pattern:

         Knows which subsystem classes are responsible for a request.

         Delegates client requests to appropriate subsystem objects.

         Implement subsystem functionality.

         Handle work assigned by the Facade object.

         Have no knowledge of the facade; that is, they keep no references to it.

         You want to provide a simple interface to a complex subsystem. Subsystems often get more complex as they evolve. Most patterns, when applied, result in more and smaller classes. This makes the subsystem more reusable and easier to customize, but it also becomes harder to use for clients that don't need to customize it. A facade can provide a simple default view of the subsystem that is good enough for most clients. Only clients needing more customizability will need to look beyond the facade.

         There are many dependencies between clients and the implementation classes of an abstraction. Introduce a facade to decouple the subsystem from clients and other subsystems, thereby promoting subsystem independence and portability.

         You want to layer your subsystems. Use a facade to define an entry point to each subsystem level. If subsystems are dependent, then you can simplify the dependencies between them by making them communicate with each other solely through their facades.

1.       Abstract Factory can be used with Facade to provide an interface for creating subsystem objects in a subsystem-independent way. Abstract Factory can also be used as an alternative to Facade to hide platform-specific classes.

2.       Mediator is similar to Facade in that it abstracts functionality of existing classes. However, Mediator's purpose is to abstract arbitrary communication between colleague objects, often centralizing functionality that doesn't belong in any one of them. A mediator's colleagues are aware of and communicate with the mediator instead of communicating with each other directly. In contrast, a facade merely abstracts the interface to subsystem objects to make them easier to use; it doesn't define new functionality, and subsystem classes don't know about it.

3.       Usually only one Facade object is required. Thus Facade objects are often Singletons .








Proxy Pattern:


ADAPTER Pattern:


         Also Known As Wrapper ( Decorator is also known as Wrapper )

         Intent to convert the interface of a class into another interface clients expect.

         Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.


o        Target defines the domain-specific interface that Client uses.

o        Client collaborates with objects conforming to the Target interface.

o        Adaptee defines an existing interface that needs adapting.

o        Adapter adapts the interface of Adaptee to the Target interface.

         Clients call operations on an Adapter instance. In turn, the adapter calls Adaptee operations that carry out the request.

         Use the Adapter pattern when

o        You want to use an existing class, and its interface does not match the one you need.

o        You want to create a reusable class that cooperates with unrelated or unforeseen classes, that is, classes that don't necessarily have compatible interfaces.

o        (Object adapter only) you need to use several existing subclasses, but it's impractical to adapt their interface by subclassing every one. An object adapter can adapt the interface of its parent class.

         Vs Bridge has a structure similar to an object adapter, but Bridge has a different intent: It is meant to separate an interface from its implementation so that they can be varied easily and independently. An adapter is meant to change the interface of an existing object.

         Vs Decorator enhances another object without changing its interface. A decorator is thus more transparent to the application than an adapter is. As a consequence, Decorator supports recursive composition, which isn't possible with pure adapters.

         Vs Proxy defines a representative or surrogate for another object and does not change its interface

         class adapter

o        Adapts Adaptee to Target by committing to a concrete Adapter class. As a consequence, a class adapter won't work when we want to adapt a class and all its subclasses.

o        Lets Adapter override some of Adaptee's behavior, since Adapter is a subclass of Adaptee.

o        Introduces only one object and no additional pointer indirection is needed to get to the adaptee.

         object adapter

o        Lets a single Adapter work with many Adaptees that is, the Adaptee itself and all of its subclasses (if any). The Adapter can also add functionality to all Adaptees at once.

o        Makes it harder to override Adaptee behavior. It will require subclassing Adaptee and making Adapter refer to the subclass rather than the Adaptee itself.

         Pluggable adapters classes with built-in interface adaptation a class is more reusable when you minimize the assumptions other classes must make to use it. Interface adaptation lets us incorporate our class into existing systems that might expect different interfaces to the class.

         Two-way adapters to provide transparency an adapted object no longer conforms to the Adaptee interface, so it can't be used as is wherever an Adaptee object can. Two-way adapters can provide such transparency. Specifically, they're useful when two different clients need to view an object differently.



Clients use the Component class interface to interact with objects in the composite structure. If the recipient is a Leaf, then the request is handled directly. If the recipient is a Composite, then it usually forwards requests to its child components, possibly performing additional operations before and/or after forwarding

COMMAND Pattern:



         The client creates a ConcreteCommand object and specifies its receiver.

         An Invoker object stores the ConcreteCommand object.

         The invoker issues a request by calling Execute on the command. When commands are undoable, ConcreteCommand stores state for undoing the command prior to invoking Execute.

         The ConcreteCommand object invokes operations on its receiver to carry out the request.

         Command decouples the invoker from the receiver (and the request it carries out).


         Command declares an interface for executing an operation.


         Client (Application) creates a ConcreteCommand object and sets its receiver.

         Invoker asks the command to carry out the request.

         Receiver knows how to perform the operations associated with carrying out a request. Any class may serve as a Receiver.

BRIDGE Pattern:




MEMENTO Pattern:



o        stores internal state of the Originator object. The memento may store as much or as little of the originator's internal state as necessary at its originator's discretion.

o        protects against access by objects other than the originator. Mementos have effectively two interfaces. Caretaker sees a narrow interface to the Mementoit can only pass the memento to other objects. Originator, in contrast, sees a wide interface, one that lets it access all the data necessary to restore itself to its previous state. Ideally, only the originator that produced the memento would be permitted to access the memento's internal state.


o        creates a memento containing a snapshot of its current internal state.

o        uses the memento to restore its internal state.


o        is responsible for the memento's safekeeping.

o        never operates on or examines the contents of a memento.

         A caretaker requests a memento from an originator, holds it for a time, and passes it back to the originator, as the following interaction diagram illustrates

         Sometimes the caretaker won't pass the memento back to the originator, because the originator might never need to revert to an earlier state.

         Mementos are passive. Only the originator that created a memento will assign or retrieve its state.

         The Memento pattern has several consequences:

o        Preserving encapsulation boundaries. Memento avoids exposing information that only an originator should manage but that must be stored nevertheless outside the originator. The pattern shields other objects from potentially complex Originator internals, thereby preserving encapsulation boundaries.

o        It simplifies Originator. In other encapsulation-preserving designs, Originator keeps the versions of internal state that clients have requested. That puts all the storage management burden on Originator. Having clients manage the state they ask for simplifies Originator and keeps clients from having to notify originators when they're done.

o        Using mementos might be expensive. Mementos might incur considerable overhead if Originator must copy large amounts of information to store in the memento or if clients create and return mementos to the originator often enough. Unless encapsulating and restoring Originator state is cheap, the pattern might not be appropriate.

o        Defining narrow and wide interfaces. It may be difficult in some languages to ensure that only the originator can access the memento's state.

o        Hidden costs in caring for mementos. A caretaker is responsible for deleting the mementos it cares for. However, the caretaker has no idea how much state is in the memento. Hence an otherwise lightweight caretaker might incur large storage costs when it stores mementos.

         Related Patterns:

o        Command : Commands can use mementos to maintain state for undoable operations.

o        Iterator : Mementos can be used for iteration