Editing Design Patterns

{{Short description|1994 software engineering book}}
{{hatnote|This article is about the book. For the generic articles, see [[software design pattern]] and [[design pattern]].}}
{{cleanup reorganize|date=July 2013}}
{{Use dmy dates|date=January 2024}}
{{Use American English|date=January 2024}}
{{Infobox book
| name         = Design Patterns:<br>Elements of Reusable {{nobr|Object-Oriented}} Software
| image        = Design Patterns cover.jpg
| author       = {{unbulleted list|[[Erich Gamma]]|[[Richard Helm]]|[[Ralph Johnson (computer scientist)|Ralph Johnson]]|[[John Vlissides]]}}
| illustrator  =
| cover_artist =
| country      = United States
| subject      = [[Design pattern]]s, [[software engineering]], [[object-oriented programming]]
| genre        =
| publisher    = [[Addison-Wesley]]
| pub_date     = 1994
| media_type   =
| pages        = 395
| isbn         = 0-201-63361-2
| oclc         = 31171684
| dewey        = 005.1/2 20
| congress     = QA76.64 .D47 1995
}}
'''''Design Patterns: Elements of Reusable Object-Oriented Software''''' (1994) is a [[software engineering]] book describing [[software design pattern]]s. The book was written by [[Erich Gamma]], [[Richard Helm]], [[Ralph Johnson (computer scientist)|Ralph Johnson]], and [[John Vlissides]], with a foreword by [[Grady Booch]]. 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 23 classic [[software design pattern]]s. The book includes examples in [[C++]] and [[Smalltalk]].

It has been influential to the field of software engineering and is regarded as an important source for object-oriented design theory and practice. More than 500,000 copies have been sold in English and in 13 other languages.<ref name="copies-sold">{{cite book|url=https://doi.org/10.1007/978-1-4302-2821-9_13|title=Pro ODP .NET for Oracle Database 11g|first=Edmund|last=Zehoo|editor-first=Edmund|editor-last=Zehoo|date=26 January 2010|publisher=Apress|pages=351–371|via=Springer Link|doi=10.1007/978-1-4302-2821-9_13}}</ref> The authors are often referred to as the ''Gang of Four'' (GoF).<ref name="gof1">{{cite book|chapter-url=https://ieeexplore.ieee.org/document/8009931|title=2017 IEEE International Conference on Software Quality, Reliability and Security (QRS)|doi=10.1109/QRS.2017.37 |s2cid=21343926 |chapter=The Effect of Gang-of-Four Design Patterns Usage on Design Quality Attributes |date=2017 |last1=Hussain |first1=Shahid |last2=Keung |first2=Jacky |last3=Khan |first3=Arif Ali |pages=263–273 |isbn=978-1-5386-0592-9 }}</ref><ref name="gof2">{{cite book|url=https://doi.org/10.1007/978-3-319-02192-8_16|title=Scala Design Patterns: Patterns for Practical Reuse and Design|first=John|last=Hunt|editor-first=John|editor-last=Hunt|date=26 January 2013|publisher=Springer International Publishing|pages=135–136|via=Springer Link|doi=10.1007/978-3-319-02192-8_16}}</ref><ref name="gof3">{{cite journal|title=Bad Smells of Gang of Four Design Patterns: A Decade Systematic Literature Review|first1=Sara H. S.|last1=Almadi|first2=Danial|last2=Hooshyar|first3=Rodina Binti|last3=Ahmad|date=26 January 2021|journal=Sustainability|volume=13|issue=18|pages=10256|doi=10.3390/su131810256|doi-access=free }}</ref><ref name="gof4">{{cite book|url=https://repositorium.sdum.uminho.pt/handle/1822/752|title=Pitfalls of aspectJ implementations of some of the gang-of-four design patterns|first1=Miguel Pessoa|last1=Monteiro|first2=João M.|last2=Fernandes|date=26 January 2004|publisher=Universidad de Extremadura|isbn=978-84-688-8889-7 |via=repositorium.uminho.pt}}</ref>

==Development and publication history==
The book started at a birds-of-a-feather session at the 1990 [[OOPSLA]] meeting, "Towards an Architecture Handbook", where Erich Gamma and Richard Helm met and discovered their common interest. They were later joined by Ralph Johnson and John Vlissides.<ref>[http://c2.com/cgi/wiki?RichardHelm Richard Helm]</ref> The book was originally published on 21 October 1994, with a 1995 copyright, and was made available to the public at the 1994 OOPSLA meeting.

==Introduction==
{{Overly detailed|section|date=October 2020}}

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)
* [[Composition over inheritance]]: "Favor '[[object composition]]' over '[[Inheritance (object-oriented programming)|class inheritance]]'." (Gang of Four 1995:20)

The authors claim the following as advantages of [[Interface (computer science)|interfaces]] over implementation:
* 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

Use of an interface also leads to [[Dynamic dispatch|dynamic binding]] and [[Polymorphism (computer science)|polymorphism]], which are central features of object-oriented programming.

The authors refer to [[Inheritance (object-oriented programming)|inheritance]] as ''[[White box (software engineering)|white-box]] reuse'', with white-box referring to visibility, because the internals of parent classes are often visible to [[Subclass (computer science)|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|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 (computer science)|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. Furthermore, they claim that a way to avoid this is to inherit only from abstract classes—but then, they point out that there is minimal code reuse.

Using inheritance is recommended 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 sender. Thus the link between two parts of a system are established only at runtime, not at compile-time. The [[Callback (computer science)|Callback]] article has more information about delegation.

The authors also discuss so-called parameterized types, which are also known as [[Generic programming|generics]] ([[Ada (programming language)|Ada]], [[Eiffel (programming language)|Eiffel]], [[Generics in Java|Java]], [[C Sharp (programming language)|C#]], [[Visual Basic (.NET)]], and [[Delphi (software)|Delphi]]) or templates ([[C++]]). These allow any 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 and build than more static software." (Gang of Four 1995:21)

The authors further distinguish between '[[Object composition#Aggregation|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 are not responsible for each other. Acquaintance is a weaker relationship than aggregation and suggests much [[Loose coupling|looser coupling]] between objects, which can often be desirable for maximum maintainability in designs.

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 '[[Software framework|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 by type ==

===Creational===
{{main|Creational pattern}}
[[Creational pattern]]s are ones that create objects, rather than having to instantiate objects directly. This gives the program more flexibility in deciding which objects need to be created for a given case.
* [[Abstract factory pattern|Abstract factory]] groups object factories that have a common theme.
* [[Builder pattern|Builder]] constructs complex objects by separating construction and representation.
* [[Factory method pattern|Factory method]] creates objects without specifying the exact class 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===
[[Structural pattern]]s concern class and object composition. They use inheritance to compose interfaces and define ways to compose objects to obtain new functionality.
* [[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.
* [[Composite pattern|Composite]] composes zero-or-more similar objects so that they can be manipulated as one object.
* [[Decorator pattern|Decorator]] dynamically adds/overrides behavior in an existing method of an object.
* [[Facade pattern|Facade]] provides a simplified interface to a large body of code.
* [[Flyweight pattern|Flyweight]] reduces the cost of creating and manipulating a large number of similar objects.
* [[Proxy pattern|Proxy]] provides a placeholder for another object to control access, reduce cost, and reduce complexity.

===Behavioral===
Most [[Behavioral pattern|behavioral design patterns]] are specifically concerned with communication between objects.
* [[Chain-of-responsibility pattern|Chain of responsibility]] delegates commands to a chain of processing objects.
* [[Command pattern|Command]] creates objects that 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.

==Reception==
In 2005 the ACM [[SIGPLAN]] awarded that year's Programming Languages Achievement Award to the authors, in recognition of the impact of their work "on programming practice and [[programming language]] design".<ref>{{cite web|url=http://www.sigplan.org/sites/default/files/report2005.pdf|title=SIGPLAN FY '05 Annual Report}}</ref>

Criticism has been directed at the concept of [[software design pattern]]s generally, and at ''Design Patterns'' specifically. A primary criticism of ''Design Patterns'' is that its patterns are simply workarounds for missing features in C++, replacing elegant abstract features with lengthy concrete patterns, essentially becoming a "human compiler". [[Paul Graham (programmer)|Paul Graham]] wrote:<ref name = "Graham2002">{{cite conference
| last1 = Graham
| first1 = Paul
| author1-link = Paul Graham (computer programmer)
| year = 2002
| title = Revenge of the Nerds
| url = http://www.paulgraham.com/icad.html
| access-date = 11 August 2012}}
</ref>
{{Quote|text=When I see patterns in my programs, I consider it a sign of trouble. The shape of a program should reflect only the problem it needs to solve. Any other regularity in the code is a sign, to me at least, that I'm using abstractions that aren't powerful enough-- often that I'm generating by hand the expansions of some macro that I need to write.}}

[[Peter Norvig]] demonstrates that 16 out of the 23 patterns in ''Design Patterns'' are simplified or eliminated by language features in [[Lisp (programming language)|Lisp]] or [[Dylan (programming language)|Dylan]].<ref name = "Norvig1998">{{cite conference
| last1 = Norvig
| first1 = Peter
| author1-link = Peter Norvig
| year = 1998
| title = Design Patterns in Dynamic Languages
| url = http://www.norvig.com/design-patterns/
}}</ref> Related observations were made by Hannemann and [[Gregor Kiczales|Kiczales]] who implemented several of the 23 design patterns using an [[aspect-oriented programming]] language ([[AspectJ]]) and showed that code-level dependencies were removed from the implementations of 17 of the 23 design patterns and that aspect-oriented programming could simplify the implementations of design patterns.<ref name = "Hannemann 2002">{{cite conference
| last1 = Hannemann
| first1 = Jan
| year = 2002
| title = Design pattern implementation in Java and AspectJ
| url = http://hannemann.pbworks.com/w/page/16577895/Design%20Pattern
}}</ref>

In an interview with InformIT in 2009, Erich Gamma stated that the book authors had a discussion in 2005 on how they would have refactored the book and concluded that they would have recategorized some patterns and added a few additional ones, such as extension object/interface, dependency injection, type object, and null object. Gamma wanted to remove the singleton pattern, but there was no consensus among the authors to do so.<ref>{{cite interview |last1=Gamma |first1=Erich |last2=Helm |first2=Richard |last3=Johnson |first3=Ralph |interviewer=Larry O'Brien |date=22 October 2009 |title=Design Patterns 15 Years Later: An Interview with Erich Gamma, Richard Helm, and Ralph Johnson |url=http://www.informit.com/articles/article.aspx?p=1404056 |work=InformIT |access-date=1 September 2019 |archive-url=https://web.archive.org/web/20190220090254/http://www.informit.com/articles/article.aspx?p=1404056 |archive-date=20 February 2019 |url-status=live}}</ref>

==See also==
* [[Software design pattern]]
* [[Enterprise Integration Patterns]]
* [[GRASP (object-oriented design)]]
* [[Pedagogical pattern]]s

==References==
{{Reflist}}

{{Design patterns}}

{{DEFAULTSORT:Design Patterns (Book)}}
[[Category:Software engineering books]]
[[Category:Software design patterns]]
[[Category:1994 non-fiction books]]
[[Category:Addison-Wesley books]]