Command

In GUI applications, it is always desirable to implement the same function via different ways (e.g. menus, context menus and etc.). Hence how can it be possible to separate the invoker and commands themselves in order to avoid unnecessary repeatition of code? The Command pattern provides us more than this.

In this figure, all Commands have the same interface. Each Invoker responds to the Client by sending request to the corresponding ConcreteCommand. The Command then carries out the action to handle the request.

We can maintain a queue for Commands, and the Command should keep all necessary information to undo the action. Thus by adding an Unexecute() to the interface and implementing it in subclasses, a do/undo/redo mechanism can be established.

The advantages are:

• It decouples the invoker and receiver and they can be modified separately.
• A Composite of Commands can be built to represent a series of complicated operations.
• It is easy to add new Commands.

Chain of Reponsibility

In this setting, a request is send to only one object, however there should be several related objects that take the responsibility. So a chain is build so as to create the final response.

The chain is usually created automatically when Composite pattern is used, since each object might keep a pointer to its parent. So the request sent to a leaf can be propagated further to its parent. The forwarding procedure can also be used to pass the request to who can handle it if the current object can not.

Proxy

At first glance, you may wonder what's the difference of a Proxy and a Decorator? Why should we propose such a pattern? A Decorator is aimed at docorating the original object, that is to provide more functions before or after the operation sent to the object. However, Proxy does not take the trouble to do more than sending the request.

Useless guys, you might wonder. However, you are wrong. The basic usage of a Proxy is to put off the real expense when it is inevitable. That's to say, RealSubject is something once created costing much time. Then its basic information can be obtained and stored in a Proxy object which acts in the same way as RealSubject does. So if only lightweight operations inquring about the basic information, there is no need to instantiate one immediately.

The indirection of Proxy can also be useful in the case of copy-on-write: The Proxy keeps the copied object and the copy needn't be carried out if the original one isn't modified. What's more the Proxy can protect the object in some way.

Flyweight

The Flyweight patterns can be illustrated with the following figure:

In this figure, the Flyweight objects can be divided into two subgroups, according to the states they keep track of. ConcreteFlyweight ones only keep an intrinsic state and the extrinsic state should be computed to locate each one by the Client. It trades off the time cost to the storage cost. Usually, it should be those objects repeated frequently and larged whose extrinsic states are easy to obtained. The UnsharedConcreteFlyweight objects are usually those whose extrinsic states are also stored and won't be necessary to be kept in a pool (since they are seldom repeated).

Sometimes, Flyweight pattern is used with Composite, which then builds a complex objects by these small repeated ones.

Facade

I guess any one who has built a complex (sub)system must be familiar with the idea by providing the user a simple class that carries out routines in the (sub)system so as to centralize the requests forwarded to the (sub)system. This idea relieves the direct coupling between (sub)systems and facilitate the users who can ignore the inner interactions of complicated classes.

Decorator

A Decorator of a certain subclass of an interface is simply a subclass that is on the same inheritance level. The difference between the subclass and its Decorator is that instead of implementing all the nterface operations itself, the Decorator simply maintains an instance of the subclass and forward the request to it after/before it adds decorations to the request. The idea enables decorators can be nested by any sequence without worry about what the decorated one is.

The Decorator helps decrease the height of the class hiararchy and is more flexible than pure inheritance. Sometime the abstract Decorator class can be omitted.

Composite

The Composite pattern is to build a class hiararchy such that each subclasses of it can be treated likewise, no matter it is a single object or a collection of objects. The following figure presents us the main idea:

In the figure, the Leaf subclass is the basic element that can build a Composite object. To implement a common operation to both the Leaf object and the Composite one, it is required that Leaf must implement the operation and Composite can forward the request to its childrens (perhaps a Leaf or a Composite one).

The Leaf class doesn't really need an Add() or Remove() operation, and hence can throw exceptions in these functions. In order to traverse the Composite object more easily, each Component can maintain a pointer to its parent. The children of a Composite object should be destroyed by the object itself in its destructor function by forwarding the request to all its children.