Design Patterns (book): Difference between revisions

From Citizendium
Jump to navigation Jump to search
imported>Yi Zhe Wu
m (restore WP tag)
imported>Pat Palmer
(→‎Observer: defining when it is used)
(29 intermediate revisions by 4 users not shown)
Line 1: Line 1:
'''Design Patterns: Elements of Reusable Object-Oriented Software''' (ISBN 0-201-63361-2) is a landmark book, first published in 1995, that recommends a set of best practices for object-oriented design and catalogs a variety of object-oriented software architectures (with examples in [[C++]] and [[Smalltalk]]).  In its 36th printing as of April 2007, the book has been translated into more than a dozen languages and has been highly regarded in the field of [[software engineering]].  However, the book makes for such dense reading (even for experienced programmers) that it has been superceded, in practice, by a spate of more recent, accessibly-written books despite being regarded as an important source for object-oriented design theory.
{{subpages}}


The book's authors ([[Erich Gamma]], [[Richard Helm]], [[Ralph Johnson]], and [[John Vlissides]]) are commonly spoken of as ''the gang of four'' due to difficulties in speaking or remembering all their names at once.  
'''Design Patterns: Elements of Reusable Object-Oriented Software''' (ISBN 0-201-63361-2) is a landmark book, first published in 1995, that recommends a set of best practices for object-oriented design and catalogs a variety of object-oriented software architectures illustrated in [[C++]] and [[Smalltalk]]<ref name="DesignPattern1">{{cite web|url=http://www.awprofessional.com/title/0201633612|title=Design Patterns: Elements of Reusable Object-Oriented Software|publisher=Addison-Wesley|year=2007|accessdate=2007-05-24}}</ref>.  In its 36th printing as of April 2007, the book has been translated into more than a dozen languages and has been highly regarded in the field of [[software engineering]].  However, the book 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.  


==Introduction, Chapter 1==
The book's authors ([[Erich Gamma]], [[Richard Helm]], [[Ralph Johnson]], and [[John Vlissides]]) are commonly spoken of as ''the gang of four'' due to difficulties in speaking or remembering all their names at once. 
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)
== Chapter 1 summary: Overview and Philosophy ==
* "Favor '[[object composition]]' over '[[Inheritance_%28computer_science%29|class inheritance]]'." (Gang of Four 1995:20)
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.
 
=== When to use Interfaces vs. Inheritance ===
 
* "Program to an 'interface', not an 'implementation'." (page 18)<ref name="DesignPattern1" />
* "Favor '[[object composition]]' over '[[Inheritance_%28computer_science%29|class inheritance]]'." (page 20)<ref name="DesignPattern1" />


The authors claim the following as advantages of [[Interface_%28computer_science%29|interfaces]] over [[Inheritance_%28computer_science%29|inheritance]]:
The authors claim the following as advantages of [[Interface_%28computer_science%29|interfaces]] over [[Inheritance_%28computer_science%29|inheritance]]:
Line 13: Line 17:
* 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 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
* clients remain unaware of the classes that implement these objects; clients only know about the abstract class(es) defining the interface
=== Inheritance as White-box Software Engineering, Object Composition as Black-box SE ===


The authors refer to [[inheritance]] as ''[[White_box_%28software_engineering%29|white-box reuse]]'', with
The authors refer to [[inheritance]] as ''[[White_box_%28software_engineering%29|white-box reuse]]'', with
Line 22: Line 28:
composed objects need be visible in the code using them.
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:
=== Inheritance overused; when and how to use it; pitfalls ===
 
The authors discuss the tension between inheritance and encapsulation at length and state that in their experience, designers overuse inheritance (page 20)<ref name="DesignPattern1" />.  The danger is stated as follows:


"Because inheritance exposes a [[Subclass_%28computer_science%29|subclass]] to details of its parent's implementation,
"Because inheritance exposes a [[Subclass_%28computer_science%29|subclass]] to details of its parent's implementation,
it's often said that 'inheritance breaks encapsulation'". (Gang of Four 1995:19)
it's often said that 'inheritance breaks encapsulation'". (page 19)<ref name="DesignPattern1" />


They warn that the implementation of
They warn that the implementation of
Line 36: Line 44:
of existing components, reusing most of the old code and adding relatively
of existing components, reusing most of the old code and adding relatively
small amounts of new code.
small amounts of new code.
=== Delegates as run-time linking ===


To the authors, 'delegation' is an extreme form of object composition
To the authors, 'delegation' is an extreme form of object composition
Line 42: Line 52:
to let the delegate refer to the receiver.  Thus the link between two parts
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_%28computer_science%29|Callback]] article has more information about delegation.
of a system are established only at runtime, not at compile-time.  The [[Callback_%28computer_science%29|Callback]] article has more information about delegation.
=== Generics (Templates in C++) ===


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 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.
=== Warning about Delegates and Generics ===


The authors admit that delegation and parameterization are  
The authors admit that delegation and parameterization are  
very powerful but add a warning:
very powerful but add a warning: "Dynamic, highly parameterized software is harder to understand
than more static software." (page 21)<ref name="DesignPattern1" />


"Dynamic, highly parameterized software is harder to understand
=== Aggregation vs. Acquaintance (association) of objects ===
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
The authors further distinguish between '[[aggregation]]', where one object 'has' or 'is part of' another object
Line 59: Line 73:
aggregation and suggests much looser coupling between objects, which
aggregation and suggests much looser coupling between objects, which
can often be desirable for maximum maintainability in a design.
can often be desirable for maximum maintainability in a design.
=== Terminology: 'toolkit' for 'class library', e.g. ===


The authors employ the term 'toolkit' where others might today use 'class library',
The authors employ the term 'toolkit' where others might today use 'class library',
Line 68: Line 84:
'''toolkits''' are harder, and '''frameworks''' are the hardest to design.
'''toolkits''' are harder, and '''frameworks''' are the hardest to design.


==Case study, Chapter 2==
==Patterns covered in the book==
 
=== Abstract Factory ===
The [[Abstract factory pattern]] groups object factories that have a common theme.
 
=== Builder ===
The [[Builder pattern]] constructs complex objects by separating construction and representation.
 
=== Factory Method ===
The [[Factory method pattern]] creates objects without specifying the exact object to create.
 
===Prototype===
The [[Prototype pattern]] creates objects by cloning an existing object.
 
=== Singleton ===
The [[Singleton pattern]] restricts object creation of a class to only one instance.
 
=== Adapter ===
The [[Adapter pattern]] allows classes with incompatible interfaces to work together by wrapping its own interface around that of an already existing class.
 
=== Bridge ===
The [[Bridge pattern]] decouples an abstraction from its implementation so that the two can vary independently.
 
=== Composite ===
The [[Composite pattern]] composes one-or-more similar objects so that they can be manipulated as one object.
 
=== Decorator ===
The [[Decorator pattern]] dynamically adds/overrides behaviour in an existing method of an object.
 
=== Façade ===
The [[Façade pattern]] provides a simplified interface to a large body of code.
 
=== Flyweight ===
The [[Flyweight pattern]] reduces the cost of creating and manipulating a large number of similar objects.
 
=== Proxy ===
The [[Proxy pattern]] provides a placeholder for another object to control access, reduce cost, and reduce complexity.
 
=== Chain-of-responsibility ===
The [[Chain-of-responsibility pattern]] delegates a series of commands to a chain of processing objects.
 
=== Command ===
The [[Command pattern]] creates objects which encapsulate actions and parameters.
 
=== Interpreter ===
The [[Interpreter pattern]] implements a specialized language.
 
=== Iterator ===
The [[Iterator pattern]] accesses the elements of an object sequentially without exposing its underlying representation.


Chapter 2 is a step-by-step case study on "the design of a 'What-You-See-Is-What-You-Get' (or 'WYSIWYG') document editor called Lexi." (pp33)
=== Mediator ===
The [[Mediator pattern]] allows loose coupling between classes by being the only class that has detailed knowledge of their methods.


==Creational patterns, Chapter 3==  
=== Memento ===
These patterns have to do with object 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.
The [[Memento pattern]] provides the ability to restore an object to its previous state (undo).


* [[Abstract factory pattern|Abstract Factory]] groups object factories that have a common theme.
=== Observer ===
* [[Builder pattern|Builder]] constructs complex objects by separating construction and representation.
The [[Observer pattern]] is a publish/subscribe pattern which allows a number of observer objects (the "subscribers") to see an event (the "published" thing to be observed). This pattern is often, or typically, used for communications among multiple threads or processes of execution which are not otherwise synchronized with each other.
* [[Factory method pattern|Factory Method]] creates objects without specifying the exact object to create.
* [[Prototype pattern|Prototype]] creates objects by cloning an existing object.
* [[Singleton pattern|Singleton]] restricts object creation for a class to only one instance.


==Structural patterns, Chapter 4==
=== State ===
These concern Class and Object composition. They use inheritance to compose interfaces and define ways to compose objects to obtain new functionality.
The [[State pattern]] allows an object to alter its behavior when its internal state changes.
* [[Adapter pattern|Adapter]] allows classes with incompatible interfaces to work together by wrapping its own interface around that of an already existing class.
 
* [[Bridge pattern|Bridge]] decouples an abstraction from its implementation so that the two can vary independently.
=== Strategy ===
* [[Composite pattern|Composite]] composes one-or-more similar objects so that they can be manipulated as one object.
The [[Strategy pattern]] allows one of a family of algorithms to be selected on-the-fly at runtime.
* [[Decorator pattern|Decorator]] dynamically adds/overrides behaviour in an existing method of an object.
 
* [[Façade pattern|Façade]] provides a simplified interface to a large body of code.
=== Template Method ===
* [[Flyweight pattern|Flyweight]] reduces the cost of creating and manipulating a large number of similar objects.
The [[Template method pattern]] defines the skeleton of an algorithm as an abstract class, allowing its subclasses to provide concrete behavior.
* [[Proxy pattern|Proxy]] provides a placeholder for another object to control access, reduce cost, and reduce complexity.
 
==Behavioral patterns, Chapter 5==
=== Visitor ===
These design patterns are about Class's objects communication. They are specifically concerned with communication between '''objects'''.
[[Visitor pattern]] separates an algorithm from an object structure by moving the hierarchy of methods into one object.


* [[Chain-of-responsibility pattern|Chain of responsibility]] delegates a series of commands to a chain of processing objects.
* [[Command pattern|Command]] creates objects which encapsulate actions and parameters.
* [[Interpreter pattern|Interpreter]] implements a specialized language.
* [[Iterator pattern|Iterator]] accesses the elements of an object sequentially without exposing its underlying representation.
* [[Mediator pattern|Mediator]] allows loose coupling between classes by being the only class that has detailed knowledge of their methods.
* [[Memento pattern|Memento]] provides the ability to restore an object to its previous state (undo).
* [[Observer pattern|Observer]] is a publish/subscribe pattern which allows a number of observer objects to see an event.
* [[State pattern|State]] allows an object to alter its behavior when its internal state changes.
* [[Strategy pattern|Strategy]] allows one of a family of algorithms to be selected on-the-fly at runtime.
* [[Template method pattern|Template method]] defines the skeleton of an algorithm as an abstract class, allowing its subclasses to provide concrete behavior.
* [[Visitor pattern|Visitor]] separates an algorithm from an object structure by moving the hierarchy of methods into one object.
==External links==
==External links==
* [http://www.awprofessional.com/title/0201633612 Design Patterns: Elements of Reusable Object-Oriented Software] Addison-Wesley, Publisher  
* [http://www.awprofessional.com/title/0201633612 Design Patterns: Elements of Reusable Object-Oriented Software] Addison-Wesley, Publisher  
* [http://tal.forum2.org/hatching Pattern Hatching] by John Vlissides (one of the ''gang of four'')
* [http://tal.forum2.org/hatching Pattern Hatching] by John Vlissides (one of the ''gang of four'')
* [http://www.eden-study.org/lepus/ LePUS] A formal language for describing and reasoning about design patterns
* [http://www.felix-colibri.com/ Felix COlibri] pattern source code: the 24 gof patterns, the gof LEXI editor, Bridge and Abstract Factory
* [http://c2.com/cgi/wiki?AntiPattern Anti Pattern] Anti Pattern
* [http://c2.com/cgi/wiki?AntiPattern Anti Pattern] Anti Pattern
==References==
==References==
<references />
<references />
[[Category:CZ Live]]
[[Category:Computers Workgroup]]

Revision as of 20:48, 15 December 2020

This article is developing and not approved.
Main Article
Discussion
Related Articles  [?]
Bibliography  [?]
External Links  [?]
Citable Version  [?]
 
This editable Main Article is under development and subject to a disclaimer.

Design Patterns: Elements of Reusable Object-Oriented Software (ISBN 0-201-63361-2) is a landmark book, first published in 1995, that recommends a set of best practices for object-oriented design and catalogs a variety of object-oriented software architectures illustrated in C++ and Smalltalk[1]. In its 36th printing as of April 2007, the book has been translated into more than a dozen languages and has been highly regarded in the field of software engineering. However, the book 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.

The book's authors (Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides) are commonly spoken of as the gang of four due to difficulties in speaking or remembering all their names at once.

Chapter 1 summary: Overview and Philosophy

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.

When to use Interfaces vs. Inheritance

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

Inheritance as White-box Software Engineering, Object Composition as Black-box SE

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.

Inheritance overused; when and how to use it; pitfalls

The authors discuss the tension between inheritance and encapsulation at length and state that in their experience, designers overuse inheritance (page 20)[1]. 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'". (page 19)[1]

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.

Delegates as run-time linking

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.

Generics (Templates in C++)

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.

Warning about Delegates and Generics

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." (page 21)[1]

Aggregation vs. Acquaintance (association) of objects

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.

Terminology: 'toolkit' for 'class library', e.g.

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.

Patterns covered in the book

Abstract Factory

The Abstract factory pattern groups object factories that have a common theme.

Builder

The Builder pattern constructs complex objects by separating construction and representation.

Factory Method

The Factory method pattern creates objects without specifying the exact object to create.

Prototype

The Prototype pattern creates objects by cloning an existing object.

Singleton

The Singleton pattern restricts object creation of a class to only one instance.

Adapter

The Adapter pattern allows classes with incompatible interfaces to work together by wrapping its own interface around that of an already existing class.

Bridge

The Bridge pattern decouples an abstraction from its implementation so that the two can vary independently.

Composite

The Composite pattern composes one-or-more similar objects so that they can be manipulated as one object.

Decorator

The Decorator pattern dynamically adds/overrides behaviour in an existing method of an object.

Façade

The Façade pattern provides a simplified interface to a large body of code.

Flyweight

The Flyweight pattern reduces the cost of creating and manipulating a large number of similar objects.

Proxy

The Proxy pattern provides a placeholder for another object to control access, reduce cost, and reduce complexity.

Chain-of-responsibility

The Chain-of-responsibility pattern delegates a series of commands to a chain of processing objects.

Command

The Command pattern creates objects which encapsulate actions and parameters.

Interpreter

The Interpreter pattern implements a specialized language.

Iterator

The Iterator pattern accesses the elements of an object sequentially without exposing its underlying representation.

Mediator

The Mediator pattern allows loose coupling between classes by being the only class that has detailed knowledge of their methods.

Memento

The Memento pattern provides the ability to restore an object to its previous state (undo).

Observer

The Observer pattern is a publish/subscribe pattern which allows a number of observer objects (the "subscribers") to see an event (the "published" thing to be observed). This pattern is often, or typically, used for communications among multiple threads or processes of execution which are not otherwise synchronized with each other.

State

The State pattern allows an object to alter its behavior when its internal state changes.

Strategy

The Strategy pattern allows one of a family of algorithms to be selected on-the-fly at runtime.

Template Method

The Template method pattern defines the skeleton of an algorithm as an abstract class, allowing its subclasses to provide concrete behavior.

Visitor

Visitor pattern separates an algorithm from an object structure by moving the hierarchy of methods into one object.

External links

References

  1. 1.0 1.1 1.2 1.3 1.4 1.5 Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley (2007). Retrieved on 2007-05-24.