Design Patterns

From Wikipedia, the free encyclopedia

You have new messages (last change).
Enlarge
This article is about the book by Gamma et al. For other meanings, see design pattern.

Often referred to as the GoF, or Gang-Of-Four (because of the four authors who wrote it), Design Patterns: Elements of Reusable Object-Oriented Software (ISBN 0-201-63361-2) is a software engineering book describing recurring solutions to common problems in software design. The book's authors are Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, known as the "Gang of Four" or simply "GoF". The book is divided into two parts, with the first two chapters exploring the capabilities and pitfalls of object-oriented programming, and the remaining chapters describing a series of classic software design patterns. The book includes examples in C++ and Smalltalk.

The original publication date of the book was 1995, and as of 2003, the book was in its 26th printing. It has been highly influential to the field of software engineering but makes for such dense reading, even for experienced programmers, that it has been superseded in practice by a spate of more recent, accessibly-written books despite being regarded as an important source for object-oriented design theory.

Contents

[edit] Introduction, Chapter 1

Chapter 1 is a discussion of object-oriented design techniques, based on the authors' experience, which they believe would lead to good object-oriented software design, including:

  • "Program to an 'interface', not an 'implementation'." (Gang of Four 1995:18)
  • "Favor 'object composition' over 'class inheritance'." (Gang of Four 1995:20)

The authors claim the following as advantages of interfaces over inheritance:

  • clients remain unaware of the specific types of objects they use, as long as the object adheres to the interface
  • clients remain unaware of the classes that implement these objects; clients only know about the abstract class(es) defining the interface

The authors refer to inheritance as white-box reuse, with white-box referring to visibility, because the internals of parent classes are often visible to subclasses. In contrast, the authors refer to object composition (in which objects with well-defined interfaces are used dynamically at runtime by objects obtaining references to other objects) as black-box reuse because no internal details of composed objects need be visible in the code using them.

The authors discuss the tension between inheritance and encapsulation at length and state that in their experience, designers overuse inheritance (Gang of Four 1995:20). The danger is stated as follows:

"Because inheritance exposes a subclass to details of its parent's implementation, it's often said that 'inheritance breaks encapsulation'". (Gang of Four 1995:19)

They warn that the implementation of a subclass can become so bound up with the implementation of its parent class that any change in the parent's implementation will force the subclass to change. They say that a way to avoid this is to inherit only from abstract classes--but then, they point out that there is minimal code reuse.

They recommend using inheritance mainly when adding to the functionality of existing components, reusing most of the old code and adding relatively small amounts of new code.

To the authors, 'delegation' is an extreme form of object composition that can always be used to replace inheritance. Delegation involves two objects: a 'sender' passes itself to a 'delegate' to let the delegate refer to the receiver. Thus the link between two parts of a system are established only at runtime, not at compile-time. The Callback article has more information about delegation.

The authors also discuss so-called parameterized types, which are also known as generics (Ada, Eiffel, Java, C#) or 'templates' (C++). These allow a type to be defined without specifying all the other types it uses--the unspecified types are supplied as 'parameters' at the point of use.

The authors admit that delegation and parameterization are very powerful but add a warning:

"Dynamic, highly parameterized software is harder to understand than more static software." (Gang of Four 1995:21)

The authors further distinguish between 'aggregation', where one object 'has' or 'is part of' another object (implying that an aggregate object and its owner have identical lifetimes) and acquaintance, where one object merely 'knows of' another object. Sometimes acquaintance is called 'association' or the 'using' relationship. Acquaintance objects may request operations of each other, but they aren't responsible for each other. Acquaintance is a weaker relationship than aggregation and suggests much looser coupling between objects, which can often be desirable for maximum maintainability in a design.

The authors employ the term 'toolkit' where others might today use 'class library', as in C# or Java. In their parlance, toolkits are the object-oriented equivalent of subroutine libraries, whereas a 'framework' is a set of cooperating classes that make up a reusable design for a specific class of software. They state that applications are hard to design, toolkits are harder, and frameworks are the hardest to design.

[edit] Case study, Chapter 2

(a case study--description needs to be added)

[edit] Creational patterns, Chapter 3

These patterns have to do with class instantiation. They can be further divided into class-creation patterns and object-creational patterns. While class-creation patterns use inheritance effectively in the instantiation process, object-creation patterns use delegation to get the job done.

[edit] Structural patterns, Chapter 4

These concern Class and Object composition. They use inheritance to compose interfaces and define ways to compose objects to obtain new functionality.

[edit] Behavioral patterns, Chapter 5

These design patterns are about Class's objects communication. They are specifically concerned with communication between objects.

[edit] Related articles

[edit] External links

v • d • e
Design patterns in Design Patterns

Creational: Abstract factory • Builder • Factory • Prototype • Singleton

Structural: Adapter • Bridge • Composite • Decorator • Façade • Flyweight • Proxy

Behavorial: Chain of responsibility • Command • Interpreter • Iterator • Mediator • Memento • Observer • State • Strategy • Template method • Visitor

Retrieved from "http://en.wikipedia.org../../../d/e/s/Design_Patterns_cf86.html"