What are design patterns?

Design patterns are elements of re-usable object oriented code that were first defined by Gamma, Helm, Johnson and Vlissides in 1995. These four authors are sometimes referred to as “the gang of four”. If you have looked at any recently designed software you have probably seen references to factory objects.

The gang of four defined three basic categories for design patterns (Creational, Structural and Behavioral). Each of the categories has a number of associated patterns.

Creational Objects:

Factory: creates objects without specifying the exact class to create.
Builder: constructs complex objects by separating construction and representation.
Prototype: creates objects by cloning an existing object.
Singleton: restricts object creation for a class to only one instance.

Structural Objects:

Bridge: decouples an abstraction from its implementation so that the two can vary independently.
Composite: composes zero-or-more similar objects so that they can be manipulated as one object.
Decorator: dynamically adds/overrides behaviour in an existing method of an object.
Facade: provides a simplified interface to a large body of code.
Flyweight: reduces the cost of creating and manipulating a large number of similar objects.
Adapter: allows classes with incompatible interfaces to work together by wrapping its own interface around that of an already existing class.
Proxy: provides a placeholder for another object to control access, reduce cost, and reduce complexity.

Behavioral Objects:

Command: creates objects which encapsulate actions and parameters.
Iterator: accesses the elements of an object sequentially without exposing its underlying representation.
Mediator: allows loose coupling between classes by being the only class that has detailed knowledge of their methods.
Memento: provides the ability to restore an object to its previous state (undo).
Observer: is a publish/subscribe pattern which allows a number of observer objects to see an event.
State: allows an object to alter its behavior when its internal state changes.
Strategy: allows one of a family of algorithms to be selected on-the-fly at runtime.
Visitor: separates an algorithm from an object structure by moving the hierarchy of methods into one object.

I don’t want to get into all of them in this post, but perhaps I can talk about one or two per post over the next while. Today lets consider factories and singletons. A singleton is the easiest to explain. For a class to be a singleton there can only every be one instance. An example of a singleton in Java would be the Runtime class. There is only one Runtime for any given program and you can access it globally.

Runtime runtimeEnvironment = Runtime.getRuntime();

Once you have the “Runtime” you can access things like the amount of free memory or the number of available processors.

In the case of a factory, the exact class of the returned object is unknown but we do know that the returned class implements a common interface. What this means is that a factory can return objects that have all been derived from a common base class or have implemented a common interface. We could have an interface for an object memory that defines the method “read”. When we ask the factory for a memory object we will always get and object that we can call read on.

In some cases the factory may decide that we need an object that also has a write method so in those cases it will return an object with both “read” and “write”.

So in summary the factory decides what to return based on the input criteria. The definition from Wikipedia is “Define an interface for creating an object, but let the classes that implement the interface decide which class to instantiate. The Factory method lets a class defer instantiation to subclasses.”

Many languages provide similar mechanisms for late instantiation but factories do it in a way that is easily recognized. I have read several books on patterns but I must admit that I am not rushing to adopt the concepts. I believe it is possible to write clear concise code without patterns, but I do stumble across them from time to time. It is good to know what they are and how they work if you inherit code from someone else.


Leave a Reply
