Abstract Factory Pattern

The Abstract Factory Pattern provides an interface for creating families of related or dependent objects without specifying their concrete classes.

This pattern saves clients the bother of instantiating families of products. The client is written against an abstract factory interface. The interface, which creates products in the abstract, is implemented in concrete factories which create the particular families of products from concrete implementations of abstract product classes.

One question I have is whether the client needs to also be written against the abstract product classes, as the Wikipedia article on this pattern suggests.

Decorator Pattern

The Decorator Pattern attaches additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality.

Subclassing components would extend functionality at compile time. Fortunately, however, the Decorator Pattern does this at run time. The pattern means that classes are open for extension but closed for modification.

This pattern wraps a concrete component with one or more decorations, or additional responsibilities. Decorations are derived from an abstract decorator class which in turn inherits from an abstract component superclass.

The concrete decorator class is passed a component in its constructor, so that operations inherited from the abstract component superclass can build on - decorate - the component.

An implementation of the Decorator Pattern carries with it an assumption that the abstract component superclass type is satisfactory to the rest of your code. You should consider another pattern if the concrete component type is what the rest of your code depends on.

Observer Pattern

The Observer Pattern defines a one-to-many dependency between objects so that when one object changes state, all of its dependents are notified and updated automatically.

This pattern is useful for the loosely coupled way it disseminates the fact of a data event or data change in a single subject to as many observers of that subject as have subscribed to receive such notifications.

Apparently, usual practice is for observers to "pull" data from the subject rather than for the subject to "push" the data to observers; in other words, usual practice is for the subject to have getter methods for its state rather than send its data as a parameter in a notifyObservers() call.

A concrete subject implements an interface to register, unregister and notify observers and has a list of registered observers that receive notifications. Concrete observers of the subject implement an interface to update themselves or other objects upon receiving notification of data events or changes in the subject.

Strategy Pattern

The Strategy Pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it.

This pattern is a means of exchanging members of a family of algorithms without impeding the operation of clients. It requires programming to an interface, not an implementation. The pattern grants clients consistency because concrete algorithms in use are members of the same family or interface.

Head First Design Patterns implements Strategy Pattern in an interesting way. Rather than provide a class with behavioural methods, they have the class delegate behaviour to an interface. Concrete behaviours have to implement their particular interface. As a result, ducks behave appropriately!