Skip to main content

Object-Oriented Design Patterns: An Introduction

Printer-friendly version
Behavioral Patterns

Chain of Responsibility
The Chain of Responsibility pattern consists of a source of command objects and a series of processing objects. Each processing object contains logic for the types of command objects that it can handle, and how to pass off those that it cannot to the next processing object in the chain. New processing objects can also be added to the end of this chain. A series of processing objects is chained together and a command passed to the head of the chain. Each processing objects decides whether or not it can handle the command. If it can, it does so; if it can’t, it passes it to the next processing objects in sequence. This simplifies the dispatch mechanism, since only one object for the head of the chain is required and is very flexible in allowing new sets of processing objects to be composed according to need and context. This pattern promotes loose coupling.

In the Command pattern, a command class represents and encapsulates all the information necessary to perform a certain operation, e.g., call a method, at a later time. A client object builds a Command object containing the necessary information; an invoker object decides when the Command will be executed; and a receiver object is the object containing the method to be executed. An example of the use of the Command pattern is multi-level undo in which each of the user’s instructions is preserved as a Command object in a stack. If the user indicates a need for undo, the Command is popped off of the stack and its undo() method is run. Another example is a wizard where one often collects multiple pages of information into Command objects and then passes these to the invoker when the user has completed filling out the wizard.

The purpose of the Interpreter pattern is to evaluate sentences in a formal language by associating a class with each symbol or token in the language and arranging these in a composite pattern tree structure. Interpreter does not cover the parsing of the input into tokens, only the representation of the parsed structure ready for evaluation. It is primarily used for evaluating specialized languages such as SQL or a special communications language.

The intent of the Iterator pattern is to provide an object which can be used to traverse some aggregate structure or collection, abstracting the details of the implementation of the structure. Typically, an Iterator provides methods for testing whether elements are available, advancing to the next or next Nth position, and accessing the value at the current position, but does so independent of the structure of the collection. By the use of an Iterator, the nature of the collection can be changed without changing the logic of the client using the collection. Also, Iterators allow multiple clients to access the same collection at the same time, each Iterator providing a pointer to the current element rather than that pointer being provided by the collection.

The purpose of the Mediator pattern is to provide a class which manages the communication among many objects in an application so that individual classes need not be linked directly, but can be linked through the Mediator. This reduces coupling among the classes in the application and provides a central point for modification of the communication structure. Thus, communication paths can be varied independent of the classes which are communicating. Classes which use the Mediator for communication are sometimes called Colleagues.

OODesignPatterns_20100120.pdf92.3 KB