Skip to main content

Object-Oriented Design Patterns: An Introduction

Printer-friendly version
In the Prototype pattern, a new object is created via a clone of an existing object rather than by creating a new object from scratch. The object provided for cloning is the prototype or prototypical instance. This pattern avoids the need for subclasses because a single creator can produce multiple objects based on different prototypes and is useful when the cost of creating a clone is inherently less expensive than the cost of creating a new object. Thus, one might, for example, clone an existing object, apply some series of transactions, and then replace the original object with the modified one.

In the Singleton pattern, one restricts instantiation of a given class to a single object. This is useful when either the nature of the class is such that only one instance should exist, e.g., where the object performs some coordination rôle among other objects. Singletons are often used to introduce global state into a system, but this can be overused or abused; consequently, there are some who regard Singleton as an anti-pattern6. Singleton is really only relevant when the problem space dictates that only one entity can exist at a time but in the problem solution flow of control there are multiple opportunities for creating the entity.

Structural Patterns

Adapter aka Wrapper
An Adapter or Wrapper translates one interface into another so that two objects which could not otherwise work together based on the original interface can cooperate based by means of the Adapter. The Object Adapter pattern is used at runtime via a class which translates the properties and methods of the original interface to the desired properties and methods. In this usage, the Adapter contains an instance of the class which is being adapted, hence the term Wrapper. The Class Adapter pattern uses a class which inherits or implements both the original and desired interface. In languages such as OOABL, which does not support multiple inheritance, the desired interface must be implemented as a pure interface.

The purpose of the Bridge pattern is to decouple the abstract part of a problem from the implementation part of a problem. In that, it can be thought of as simply doing the correct decomposition of the problem space, but as it is a common requirement, it merits identification as a pattern. A classic example of the use of the Bridge pattern is any component in which there is a portion which is device or system dependent and a portion which is independent or invariant, e.g., a device driver where there is a common portion that applies to all devices and defines the common interface and a device specific portion for the particular hardware.

The Composite pattern allows a group of objects to be treated in the same way as a single object by “composing” objects into a tree structure to represent a single entity. It is used when one wishes to treat individual objects and groups of objects in the same way, i.e., any operation you can perform on the individual you can also perform on the group and expect some kind of equivalent behavior. Thus, Composite provides for a tree structure in which both the nodes and the leaves share the same interface, or at least most of the same interface. If one relaxes the requirement for a common interface, Composite can be seen as a pattern which allows one to navigate hierarchical structures containing both composed and atomic data.

OODesignPatterns_20100120.pdf92.3 KB