Object-Oriented Design Patterns: An Introduction

Printer-friendly versionSend to friend
Visitor
The purpose of the visitor pattern is to provide a mechanism for separating an algorithm from the object structure in which it operates, thus allowing the same algorithm to be applied to multiple object types and multiple algorithms to be applied to any one object on a dynamic basis. The essence of the implementation of this pattern is that an object provides a method which will accept objects of the visitor type and which will then execute a visit() method on that object to apply the algorithm to the object’s structures with the object passed as an argument to the Visitor class. The Visitor typically contains code which applies different actions according to the class of the argument. This pattern improves Separation of Concerns by encapsulating a general class of behavior separate from the specific instances where that behavior might be used. Some feel that Visitor is overused since it implies a combinatorial interaction lattice between objects and algorithms, which does not often occur in most problem spaces. This leads to questionable practices such as “no-op” visits.

Summary
This concludes the summary of the 23 GoF patterns. It is, at best, a brief summary and the reader is encouraged to further reading to gain a more complete understanding of these and other patterns, especially since many patterns have significant context about when they are and are not seen as appropriate to use and there is a diversity of opinion on their virtue and proper application. Moreover, the GoF patterns, which are the most famous of the OO pattern sets, are by no means the only patterns available and there are many books and many, many web pages with additional patterns. Other sets may supplement the GoF patterns with entirely new ideas, recharacterize GoF patterns in ways the author finds more intuitive or useful, or combine GoF and/or other patterns into more complex patterns.

It is important to recognize that patterns are not rules, but ideas about how to solve problems. They are not to be slavishly applied whenever the opportunity presents, but rather are intended to provide inspiration and a mnemonic aid for associating a familiar problem with a corresponding solution. If a pattern almost fits a problem, but not quite, then one should feel free to adapt the pattern to fit the requirements, possibly by borrowing elements from another pattern. Some problems will seem to fit multiple patterns and one must choose which provides the best solution for the purpose at hand. Their intent is to make design and programming easier, not to provide rules to limit solutions. Patterns can also be very helpful in communicating ideas.

1. 1. See also, Mercer-Hursh, Thomas (2010) Object-Oriented Vocabulary: An Introduction for brief definitions of the words used in these patterns. http://www.cintegrity.com/content/Object-Oriented-Vocabulary-Introduction
2. 2. Alexander, Christopher (1977). [em]A Pattern Language[/em]. Oxford University Press.
3. 3. While the same design patterns can actually be applied in almost any programming language or idiom, they have taken particular hold in object-oriented programming. This may be because there is a strong emphasis on re-use in OO and the essence of design patterns is re-use of knowledge. Also, Object Orientation is all about abstracting from the problem space, so one already has the conceptual mechanisms and infrastructure for design patterns, which are themselves abstractions of sets of problem solutions.
4. 4. Gamma, Helm, Johnson & Vlissides (1994). Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley.
5. 5. Hohpe, Gregor & Woolf, Bobby (2003). Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions. Addison-Wesley.
6. 6. Anti-Pattern: A design pattern which is widely used, but is ineffective or counterproductive in practice.

Attachment	Size
OODesignPatterns_20100120.pdf	92.3 KB