Design Patterns: Difference between revisions

Revision as of 21:16, 3 February 2021

Latest revision as of 14:46, 25 August 2025

(59 intermediate revisions by 44 users not shown)

Line 1:

{{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 = The "Gang of Four": {{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 [[Design pattern (computer science)|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|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|bibcode=2021Sust...1310256A |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>

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. The authors are often referred to as the '''Gang of Four''' ('''GoF''').<ref>[http://c2.com/cgi/wiki?GangOfFour Gang Of Four], Content Creation Wiki for People Projects And Patterns in Software Development.</ref>

==Development and publication history==

==History==

The book started at a [[birds -of -a -feather (computing)|birdssession ofat athe feather]] (BoF) session at1990 [[OOPSLA]] '90meeting, "Towards an Architecture Handbook", run by Bruce Anderson, 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 originalbook publicationwas dateoriginally ofpublished theon book was21 October 211994, 1994 with a 1995 copyright, hence it is often cited with a 1995-year, despite being published in 1994. The bookand was first made available to the public at the 1994 OOPSLA meeting held in Portland, Oregon, in October 1994.

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>[http://www.sigplan.org/sites/default/files/report2005.pdf SIGPLAN FY '05 Annual Report]</ref> As of March 2012, the book was in its 40th printing.

==Introduction==

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

Chapter 1 is a discussion of [[Object-oriented programming|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)

* "Program[[Composition toover aninheritance]]: "Favor 'interface[[object composition]]', not anover ''''implementation'''[[Inheritance (object-oriented programming)|class inheritance]]'." (Gang of Four 1995:1820)

* [[Composition over inheritance]]: "Favor '[[object composition]]' over '[[Inheritance (computer science)|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 in(computer object-oriented programmingscience)|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.

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)

Line 54 ⟶ 52:

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#]], VB[[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:

Line 62 ⟶ 60:

:"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 aren'tare 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 a designdesigns.

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.

==Case study==

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

Chapter 2 is a step-by-step case study on "the design of a '[[WYSIWYG|What-You-See-Is-What-You-Get]]' (or 'WYSIWYG') document editor called Lexi." (pp.{{nbsp}}33)

The chapter goes through seven problems that must be addressed in order to properly design Lexi, including any constraints that must be followed. Each problem is analyzed in depth, and solutions are proposed. Each solution is explained in full, including [[pseudo-code]] and a slightly modified version of [[Object Modeling Technique]] where appropriate.

Finally, each solution is associated directly with one or more design patterns. It is shown how the solution is a direct implementation of that design pattern.

The seven problems (including their constraints) and their solutions (including the pattern(s) referenced), are as follows:

===Document Structure===

The document is "an arrangement of basic graphical elements" such as characters, lines, other shapes, etc., that "capture the total information content of the document"(pp.{{nbsp}}35<!-- Should this be just one p? Or should it use "35ff"? -->). The structure of the document contains a collection of these elements, and each element can in turn be a substructure of other elements.

'''Problems and Constraints'''

#Text and graphics should be treated the same way (that is, graphics aren't a derived instance of text, nor vice versa)

#The implementation should treat complex and simple structures the same way. It should not have to know the difference between the two.

#Specific derivatives of abstract elements should have specialized analytical elements.

'''Solution and Pattern'''

A ''recursive composition'' is a hierarchical structure of elements, that builds "increasingly complex elements out of simpler ones" (pp.{{nbsp}}36<!-- Should this be just one p? Or should it use "35ff"? -->). Each node in the structure knows of its own children and its parent. If an operation is to be performed on the whole structure, each node calls the operation on its children (recursively).

This is an implementation of the [[composite pattern]], which is a collection of nodes. The node is an [[Abstract type|abstract base class]], and derivatives can either be leaves (singular), or collections of other nodes (which in turn can contain leaves or collection-nodes). When an operation is performed on the parent, that operation is recursively passed down the hierarchy.

===Formatting===

Formatting differs from structure. Formatting is a method of constructing a particular instance of the document's physical structure. This includes breaking text into lines, using hyphens, adjusting for margin widths, etc.

'''Problems and Constraints'''

#Balance between (formatting) quality, speed and storage space

#Keep formatting independent (uncoupled) from the document structure.

'''Solution and Pattern'''

A ''Compositor'' class will encapsulate the algorithm used to format a composition. Compositor is a subclass of the primitive object of the document's structure. A Compositor has an associated instance of a Composition object. When a Compositor runs its <code>Compose()</code>, it iterates through each element of its associated Composition, and rearranges the structure by inserting Row and Column objects as needed.

The Compositor itself is an abstract class, allowing for derivative classes to use different formatting algorithms (such as double-spacing, wider margins, etc.)

The [[Strategy pattern|Strategy Pattern]] is used to accomplish this goal. A Strategy is a method of encapsulating multiple algorithms to be used based on a changing context. In this case, formatting should be different, depending on whether text, graphics, simple elements, etc., are being formatted.

===Embellishing the User Interface===

The ability to change the graphical interface that the user uses to interact with the document.

'''Problems and Constraints'''

#Demarcate a page of text with a border around the editing area

#Scroll bars that let the user view different parts of the page

#User interface objects should not know about the embellishments

#Avoid an "explosion of classes" that would be caused by subclassing for "every possible combination of embellishments" and elements (p.{{nbsp}}44)

'''Solution and Pattern'''

The use of a ''transparent enclosure'' allows elements that augment the behaviour of composition to be added to a composition. These elements, such as Border and Scroller, are special subclasses of the singular element itself. This allows the composition to be augmented, effectively adding state-like elements. Since these augmentations are part of the structure, their appropriate <code>Operation()</code> will be called when the structure's <code>Operation()</code> is called. This means that the client does not need any special knowledge or interface with the structure in order to use the embellishments.

This is a [[Decorator pattern]], one that adds responsibilities to an object without modifying the object itself.

===Supporting Multiple Look-And-Feel Standards===

[[Look and feel|Look-and-feel]] refers to [[Platform (computing)|platform]]-specific UI standards. These standards "define guidelines for how applications appear and react to the user" (pp.{{nbsp}}47).

'''Problems and Constraints'''

#The editor must implement standards of multiple platforms so that it is [[porting|portable]]

#Easily adapt to new and emergent standards

#Allow for run-time changing of look-and-feel (i.e.: No [[hard coded|hard-coding]])

#Have a set of abstract elemental subclasses for each category of elements (ScrollBar, Buttons, etc.)

#Have a set of concrete subclasses for each abstract subclass that can have a different look-and-feel standard. (ScrollBar having MotifScrollBar and PresentationScrollBar for Motif and Presentation look-and-feels)

'''Solution and Pattern'''

Since object creation of different concrete objects cannot be done at runtime, the object creation process must be abstracted. This is done with an abstract guiFactory, which takes on the responsibility of creating UI elements. The abstract guiFactory has concrete implementations, such as MotifFactory, which creates concrete elements of the appropriate type (MotifScrollBar). In this way, the program need only ask for a ScrollBar and, at run-time, it will be given the correct concrete element.

This is an [[Abstract factory pattern|Abstract Factory]]. A regular factory creates concrete objects of one type. An abstract factory creates concrete objects of varying types, depending on the concrete implementation of the factory itself. Its ability to focus on not just concrete objects, but entire ''families'' of concrete objects "distinguishes it from other creational patterns, which involve only one kind of product object" (pp.{{nbsp}}51).

===Supporting Multiple Window Systems===

Just as look-and-feel is different across platforms, so is the method of handling [[window (computing)|windows]]. Each platform displays, lays out, handles input to and output from, and layers windows differently.

'''Problems and Constraints'''

#The document editor must run on many of the "important and largely incompatible window systems" that exist (p.{{nbsp}}52)

#An Abstract Factory cannot be used. Due to differing standards, there will not be a common abstract class for each type of widget.

#Do not create a new, nonstandard windowing system

'''Solution and Pattern'''

It is possible to develop "our own abstract and concrete product classes", because "all window systems do generally the same thing" (p.{{nbsp}}52). Each window system provides operations for drawing primitive shapes, iconifying/de-iconifying, resizing, and refreshing window contents.

An abstract base <code>Window</code> class can be derived to the different types of existing windows, such as application, [[iconification|iconified]], dialog. These classes will contain operations that are associated with windows, such as reshaping, graphically refreshing, etc. Each window contains elements, whose <code>Draw()</code> functions are called upon by the <code>Window</code>'s own draw-related functions.

In order to avoid having to create platform-specific Window subclasses for every possible platform, an interface will be used. The <code>Window</code> class will implement a <code>Window</code> implementation (<code>WindowImp</code>) abstract class. This class will then in turn be derived into multiple platform-specific implementations, each with platform-specific operations. Hence, only one set of <code>Window</code> classes are needed for each type of <code>Window</code>, and only one set of <code>WindowImp</code> classes are needed for each platform (rather than the [[Cartesian product]] of all available types and platforms). In addition, adding a new window type does not require any modification of platform implementation, or vice versa.

This is a [[Bridge pattern]]. <code>Window</code> and <code>WindowImp</code> are different, but related. <code>Window</code> deals with windowing in the program, and <code>WindowImp</code> deals with windowing on a platform. One of them can change without ever having to modify the other. The Bridge pattern allows these two "separate class hierarchies to work together even as they evolve independently" (p.{{nbsp}}54).

===User Operations===

All actions the user can take with the document, ranging from entering text, changing formatting, quitting, saving, etc.

'''Problems and Constraints'''

#Operations must be accessed through different inputs, such as a menu option and a keyboard shortcut for the same command

#Each option has an interface, which should be modifiable

#Operations are implemented in several different classes

#In order to avoid coupling, there must not be a lot of dependencies between implementation and user interface classes.

#Undo and redo commands must be supported on most document changing operations, with [[zero one infinity rule|no arbitrary limit]] on the number of levels of undo

#Functions are not viable, since they don't undo/redo easily, are not easily associated with a state, and are hard to extend or reuse.

#Menus should be treated like hierarchical composite structures. Hence, a menu is a menu item that contains menu items which may contain other menu items, etc.

'''Solution and Pattern'''

Each menu item, rather than being instantiated with a list of parameters, is instead done with a ''Command'' object.

Command is an abstract object that only has a single abstract <code>Execute()</code> method. Derivative objects extend the <code>Execute()</code> method appropriately (i.e., the <code>PasteCommand.Execute()</code> would utilize the content's clipboard buffer). These objects can be used by widgets or buttons just as easily as they can be used by menu items.

To support undo and redo, <code>Command</code> is also given <code>Unexecute()</code> and <code>Reversible()</code>. In derivative classes, the former contains code that will undo that command, and the latter returns a boolean value that defines if the command is undoable. <code>Reversible()</code> allows some commands to be non-undoable, such as a Save command.

All executed <code>Commands</code> are kept in a list with a method of keeping a "present" marker directly after the most recently executed command. A request to undo will call the <code>Command.Unexecute()</code> directly before "present", then move "present" back one command. Conversely, a <code>Redo</code> request will call <code>Command.Execute()</code> after "present", and move "present" forward one.

This <code>Command</code> approach is an implementation of the [[Command pattern]]. It encapsulates requests in objects, and uses a common interface to access those requests. Thus, the client can handle different requests, and commands can be scattered throughout the application.

===Spell Check and Hyphenation===

This is the document editor's ability to textually analyze the contents of a document. Although there are many analyses that can be performed, spell check and hyphenation-formatting are the focus.

'''Problems and Constraints'''

#Allow for multiple ways to check spelling and identify places for hyphenation

#Allow for expansion for future analysis (e.g., word count, grammar check)

#Be able to iterate through a text's contents without access to the text's actual structure (e.g., array, linked list, string)

#Allow for any manner of traversal of document (beginning to end, end to beginning, alphabetical order, etc.)

'''Solution and Pattern'''

Removing the integer-based index from the basic element allows for a different iteration interface to be implemented. This will require extra methods for traversal and object retrieval. These methods are put into an abstract <code>Iterator</code> interface. Each element then implements a derivation of the <code>Iterator</code>, depending on how that element keeps its list (<code>ArrayIterator</code>, <code>LinkListIterator</code>, etc.).

Functions for traversal and retrieval are put into the abstract Iterator interface. Future Iterators can be derived based on the type of list they will be iterating through, such as Arrays or Linked Lists. Thus, no matter what type of indexing method any implementation of the element uses, it will have the appropriate Iterator.

This is an implementation of the [[Iterator pattern]]. It allows the client to traverse through any object collection, without needing to access the contents of the collection directly, or be concerned about the type of list the collection's structure uses.

Now that traversal has been handled, it is possible to analyze the elements of a structure. It is not feasible to build each type of analysis into the element structure themselves; every element would need to be coded, and much of the code would be the same for similar elements.

Instead, a generic <code>CheckMe()</code> method is built into the element's abstract class. Each Iterator is given a reference to a specific algorithm (such as spell check, grammar check, etc.). When that Iterator iterates through its collection, it calls each element's <code>CheckMe</code>, passing the specified algorithm. <code>CheckMe</code> then passes a reference to its element back to said algorithm for analysis.

Thus, to perform a spell check, a front-to-end iterator would be given a reference to a <code>SpellCheck</code> object. The iterator would then access each element, executing its <code>CheckMe()</code> method with the <code>SpellCheck</code> parameter. Each <code>CheckMe</code> would then call the <code>SpellCheck</code>, passing a reference to the appropriate element.

In this manner, any algorithm can be used with any traversal method, without hard-code coupling one with the other. For example, Find can be used as "find next" or "find previous", depending on if a "forward" iterator was used, or a "backwards" iterator.

In addition, the algorithms themselves can be responsible for dealing with different elements. For example, a <code>SpellCheck</code> algorithm would ignore a <code>Graphic</code> element, rather than having to program every <code>Graphic</code>-derived element to not send themselves to a <code>SpellCheck</code>.

== Patterns by type ==

Line 221 ⟶ 69:

{{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.

Line 229 ⟶ 76:

===Structural===

These[[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 behaviourbehavior 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.

Line 239 ⟶ 86:

===Behavioral===

Most of[[Behavioral thesepattern|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 whichthat 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.

Line 253 ⟶ 99:

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

==CriticismReception==

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" or "generating by hand the expansions of some macro". [[Paul Graham (programmer)|Paul Graham]] wrote:<ref name = "Graham2002">{{cite conference

| last = Graham

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

| first = Paul

| author-linklast1 = Paul Graham (computer programmer)

| first1 = Paul

| title = Revenge of the Nerds

| author1-link = Paul Graham (computer programmer)

| url = http://www.paulgraham.com/icad.html

| year = 2002

| title = Revenge of the Nerds

| access-date = 2012-08-11}}

| url = http://www.paulgraham.com/icad.html

</ref>

| 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 (via directby language support)features in [[Lisp (programming language)|Lisp]] or [[Dylan (programming language)|Dylan]].<ref name = "Norvig1998">{{cite conference

| lastlast1 = Norvig

| firstfirst1 = Peter

| authorauthor1-link = Peter Norvig

| year = 1998
| title = Design Patterns in Dynamic Languages

| url = http://www.norvig.com/design-patterns/

| year = 1998}}</ref> Related observations were made by Hannemann and [[Gregor Kiczales|Kiczales]] who implemented several of the 23 design patterns using an [[Aspect-oriented programming|aspect-oriented programming language]] 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

| lastlast1 = Hannemann

| firstfirst1 = Jan

| year = 2002

| title = Design pattern implementation in Java and AspectJ

| title = Design pattern implementation in Java and AspectJ

| url = http://hannemann.pbworks.com/w/page/16577895/Design%20Pattern

| url = http://hannemann.pbworks.com/w/page/16577895/Design%20Pattern

| year = 2002}}</ref>

}}</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>

There has also been humorous criticism, such as a show trial at OOPSLA '99 on 3 November 1999,<ref>[http://www.laputan.org/patterns/trial.html Indictment]</ref><ref>[http://www.laputan.org/patterns/gang-of-four.html The Show Trial of the Gang-of-Four], [[Big ball of mud|Brian Foote]]</ref>{{efn|1=Presiding Magistrate Neil Harrison, Head Prosecutor [[Kent Beck]], Defending Barrister [[Martin Fowler (software engineer)|Martin Fowler]], Court Baliff [[Big ball of mud|Brian Foote]]; Richard Helm submitted a [http://www.laputan.org/patterns/helm.html confession], while the rest stood trial.}} and a parody of the format, by [[Jim Coplien]], entitled "[http://c2.com/cgi/wiki?KansasCityAirConditioner Kansas City Air Conditioner]".

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. Gamma wanted to remove the Singleton pattern, but there was no consensus among the authors to do so.<ref>{{cite interview |last=Gamma |first=Erich |last2=Helm |first2=Richard |last3=Johnson |first3=Ralph |interviewer=Larry O'Brien |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 |date=2009-10-22 |access-date=2019-09-01 |archive-url=https://web.archive.org/web/20190220090254/http://www.informit.com/articles/article.aspx?p=1404056 |archive-date=2019-02-20 |url-status=live}}</ref>

==See also==

* [[Software design pattern]]

* [[Enterprise Integration Patterns]]

* [[GRASP (object-oriented design)]]

* [[Pedagogical patternspattern]]s

==Notes==

{{notelist}}

==References==

{{reflistReflist}}

{{Design Patterns Patternspatterns}}

{{DEFAULTSORT:Design Patterns (Book)}}