Editing Software design pattern (section)

==Examples==
Design patterns can be organized into groups based on what kind of problem they solve. [[Creational pattern]]s create objects. [[Structural pattern]]s organize classes and objects to form larger structures that provide new functionality. [[Behavioral pattern]]s describe collaboration between objects.

=== [[Creational patterns]] ===
{| class="wikitable"
|-
! Name
! Description
! In ''[[Design Patterns]]''
! In ''[[Code Complete]]''<ref name="McConnell2004">{{cite book
 | title = Code Complete
 | first = Steve
 | last = McConnell
 | author-link = Steve McConnell
 |date=June 2004
 | publisher = [[Microsoft Press]]
 | isbn = 978-0-7356-1967-8
 | chapter = Design in Construction
 | quote = Table 5.1 Popular Design Patterns
 | edition = 2nd
 | page = [https://archive.org/details/codecomplete0000mcco/page/104 104]
| title-link = Code Complete
 }}</ref>
! Other
|-
| [[Abstract factory]]
| Provide an interface for creating ''families'' of related or dependent objects without specifying their concrete classes.
| {{yes}}
| {{yes}}
| {{n/a}}
|-
| [[Builder pattern|Builder]]
| Separate the construction of a complex object from its representation, allowing the same construction process to create various representations.
| {{yes}}
| {{yes}}
| {{n/a}}
|-
| [[Dependency Injection]]
| A class accepts the objects it requires from an injector instead of creating the objects directly.
| {{n/a}}
| {{yes}}
| {{n/a}}
|-
| [[Factory method]]
| Define an interface for creating a ''single'' object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.
| {{yes}}
| {{yes}}
| {{n/a}}
|-
| [[Lazy initialization]]
| Tactic of delaying the creation of an object, the calculation of a value, or some other expensive process until the first time it is needed. This pattern appears in the GoF catalog as "virtual proxy", an implementation strategy for the [[Proxy pattern|Proxy]] pattern.
| {{yes}}
| {{yes}}
| {{yes|{{abbr|PoEAA|Patterns of Enterprise Application Architecture}}<ref name = "PoEAA">
{{cite book
 | first = Martin
 | last = Fowler
 | author-link = Martin Fowler (software engineer)
 | year = 2002
 | title = Patterns of Enterprise Application Architecture
 | publisher = [[Addison-Wesley]]
 | isbn = 978-0-321-12742-6
 | url = http://martinfowler.com/books.html#eaa
}}</ref>}}
|-
| [[Multiton]]
| Ensure a class has only named instances, and provide a global point of access to them.
| {{yes}}
| {{yes}}
| {{yes}}
|-
| [[Object pool]]
| Avoid expensive acquisition and release of resources by recycling objects that are no longer in use. Can be considered a generalisation of [[connection pool]] and [[thread pool]] patterns.
| {{yes}}
| {{yes}}
| {{yes}}
|-
| [[Prototype pattern|Prototype]]
| Specify the kinds of objects to create using a prototypical instance, and create new objects from the 'skeleton' of an existing object, thus boosting performance and keeping memory footprints to a minimum.
| {{yes}}
| {{yes}}
| {{yes}}
|-
| [[Resource acquisition is initialization]] (RAII)
| Ensure that resources are properly released by tying them to the lifespan of suitable objects.
| {{yes}}
| {{yes}}
| {{yes}}
|-
| [[Singleton pattern|Singleton]]
| Ensure a class has only one instance, and provide a global point of access to it.
| {{yes}}
| {{yes}}
| {{yes}}
|}

=== [[Structural pattern]]s ===
{| class="wikitable"
|-
! Name
! Description
! In ''[[Design Patterns]]''
! In ''[[Code Complete]]''<ref name="McConnell2004" />
! Other
|-
| [[Adapter pattern|Adapter]], Wrapper, or Translator
| Convert the interface of a class into another interface clients expect. An adapter lets classes work together that could not otherwise because of incompatible interfaces. The enterprise integration pattern equivalent is the translator.
| {{yes}}
| {{yes}}
| {{yes}}
|-
| [[Bridge pattern|Bridge]]
| Decouple an abstraction from its implementation allowing the two to vary independently.
| {{yes}}
| {{yes}}
| {{yes}}
|-
| [[Composite pattern|Composite]]
| Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.
| {{yes}}
| {{yes}}
| {{yes}}
|-
| [[Decorator pattern|Decorator]]
| Attach additional responsibilities to an object dynamically keeping the same interface. Decorators provide a flexible alternative to subclassing for extending functionality.
| {{yes}}
| {{yes}}
| {{yes}}
|-
| [[Delegation pattern|Delegation]]
| Extend a class by composition instead of subclassing. The object handles a request by delegating to a second object (the delegate)
| {{yes}}
| {{yes}}
| {{yes}}
|-
| Extension object
| Adding functionality to a hierarchy without changing the hierarchy.
| {{yes}}
| {{yes}}
| {{yes}}
|-
| [[Facade pattern|Facade]]
| Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.
| {{yes}}
| {{yes}}
| {{yes}}
|-
| [[Flyweight pattern|Flyweight]]
| Use sharing to support large numbers of similar objects efficiently.
| {{yes}}
| {{yes}}
| {{yes}}
|-
| [[Front controller]]
| The pattern relates to the design of Web applications. It provides a centralized entry point for handling requests.
| {{yes}}
| {{yes}}
| {{yes|
{{abbr|J2EE Patterns|Core J2EE Patterns: Best Practices and Design Strategies (2nd Edition)}}<ref name = "J2EE Patterns">
{{cite book
 | first1 = Deepak
 | last1 = Alur
 | first2 = John | last2 = Crupi | first3 = Dan | last3 = Malks
 | year = 2003
 | title = Core J2EE Patterns: Best Practices and Design Strategies
 | page = 166
 | publisher = [[Prentice Hall]]
 | isbn = 978-0-13-142246-9
 | url = http://www.corej2eepatterns.com
}}</ref>
{{abbr|PoEAA|Patterns of Enterprise Application Architecture}}<ref name = "PoEAA2">
{{cite book
 | first = Martin
 | last = Fowler
 | author-link = Martin Fowler (software engineer)
 | year = 2002
 | title = Patterns of Enterprise Application Architecture
 | page = 344
 | publisher = [[Addison-Wesley]]
 | isbn = 978-0-321-12742-6
 | url = http://martinfowler.com/books.html#eaa
}}</ref>}}
|-
| [[Marker interface pattern|Marker]]
| Empty interface to associate metadata with a class.
| {{yes}}
| {{yes}}
| {{yes|[[Joshua Bloch|Effective Java]]<ref name="EffectiveJava">
{{cite book
 | last = Bloch
 | first = Joshua
 | title = Effective Java
 | page = [https://archive.org/details/effectivejava00bloc_0/page/179 179]
 | chapter = Item 37: Use marker interfaces to define types
 | year = 2008
 | isbn = 978-0-321-35668-0
 | publisher = Addison-Wesley
 | chapter-url = https://archive.org/details/effectivejava00bloc_0/page/179
 | edition = Second
 }}</ref>}}
|-
| [[Module pattern|Module]]
| Group several related elements, such as classes, singletons, methods, globally used, into a single conceptual entity.
| {{yes}}
| {{yes}}
| {{yes}}
|-
| [[Proxy pattern|Proxy]]
| Provide a surrogate or placeholder for another object to control access to it.
| {{yes}}
| {{yes}}
| {{yes}}
|-
| [[Twin pattern|Twin]]<ref>{{cite web|url=http://www.ssw.jku.at/Research/Papers/Moe99/Paper.pdf |title=Twin – A Design Pattern for Modeling Multiple Inheritance }}</ref>
| Twin allows modeling of multiple inheritance in programming languages that do not support this feature.
| {{yes}}
| {{yes}}
| {{yes}}

|}

=== [[Behavioral patterns]] ===
{| class="wikitable"
|-
! Name
! Description
! In ''[[Design Patterns]]''
! In ''[[Code Complete]]''<ref name="McConnell2004" />
! Other
|-
| [[Blackboard (design pattern)|Blackboard]]
| [[Artificial intelligence]] pattern for combining disparate sources of data (see [[blackboard system]])
| {{yes}}
| {{yes}}
| {{yes}}
|-
| [[Chain-of-responsibility pattern|Chain of responsibility]]
| Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it.
| {{yes}}
| {{yes}}
| {{yes}}
|-
| [[Command pattern|Command]]
| Encapsulate a request as an object, thereby allowing for the parameterization of clients with different requests, and the queuing or logging of requests. It also allows for the support of undoable operations.
| {{yes}}
| {{yes}}
| {{yes}}
|-
|[[Fluent interface]]
| Design an API to be method chained so that it reads like a DSL. Each method call returns a context through which the next logical method call(s) are made available.
| {{yes}}
| {{yes}}
| {{yes}}
|-
| [[Interpreter pattern|Interpreter]]
| Given a language, define a representation for its grammar along with an interpreter that uses the representation to interpret sentences in the language.
| {{yes}}
| {{yes}}
| {{yes}}
|-
| [[Iterator pattern|Iterator]]
| Provide a way to access the elements of an [[Aggregate pattern|aggregate]] object sequentially without exposing its underlying representation.
| {{yes}}
| {{yes}}
| {{yes}}
|-
| [[Mediator pattern|Mediator]]
| Define an object that encapsulates how a set of objects interact. Mediator promotes [[loose coupling]] by keeping objects from referring to each other explicitly, and it allows their interaction to vary independently.
| {{yes}}
| {{yes}}
| {{yes}}
|-
| [[Memento pattern|Memento]]
| Without violating encapsulation, capture and externalize an object's internal state allowing the object to be restored to this state later.
| {{yes}}
| {{yes}}
| {{yes}}
|-
| [[Null object]]
| Avoid null references by providing a default object.
| {{yes}}
| {{yes}}
| {{yes}}
|-
| [[Observer pattern|Observer]] or [[Publish/subscribe]]
| Define a one-to-many dependency between objects where a state change in one object results in all its dependents being notified and updated automatically.
| {{yes}}
| {{yes}}
| {{yes}}
|-
| [[Design pattern Servant|Servant]]
| Define common functionality for a group of classes. The servant pattern is also frequently called helper class or utility class implementation for a given set of classes. The helper classes generally have no objects hence they have all static methods that act upon different kinds of class objects.
| {{yes}}
| {{yes}}
| {{yes}}
|-
| [[Specification pattern|Specification]]
| Recombinable [[business logic]] in a [[Boolean algebra|Boolean]] fashion.
| {{yes}}
| {{yes}}
| {{yes}}
|-
| [[State pattern|State]]
| Allow an object to alter its behavior when its internal state changes. The object will appear to change its class.
| {{yes}}
| {{yes}}
| {{yes}}
|-
| [[Strategy pattern|Strategy]]
| Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it.
| {{yes}}
| {{yes}}
| {{yes}}
|-
| [[Template method]]
| Define the skeleton of an algorithm in an operation, deferring some steps to subclasses. Template method lets subclasses redefine certain steps of an algorithm without changing the algorithm's structure.
| {{yes}}
| {{yes}}
| {{yes}}
|-
| [[Visitor pattern|Visitor]]
| Represent an operation to be performed on instances of a set of classes. Visitor lets a new operation be defined without changing the classes of the elements on which it operates.
| {{yes}}
| {{yes}}
| {{yes}}
|}

=== [[Concurrency patterns]] ===
{| class="wikitable"
|-
! Name
! Description
! In ''[[Pattern-Oriented Software Architecture|POSA2]]''<ref name="POSA2">{{cite book
 | first1 = Douglas C.
 | last1 = Schmidt
| first2 = Michael | last2 = Stal | first3 = Hans | last3 = Rohnert | first4 = Frank | last4 = Buschmann
 | date = 2000
 | title = Pattern-Oriented Software Architecture, Volume 2: Patterns for Concurrent and Networked Objects
 | publisher = John Wiley & Sons
 | isbn = 978-0-471-60695-6
}}</ref>
! Other
|-
| [[Active Object]]
| Decouples method execution from method invocation that reside in their own thread of control. The goal is to introduce concurrency, by using [[asynchronous method invocation]] and a [[scheduling (computing)|scheduler]] for handling requests.
| {{yes}}
| {{n/a}}
|-
| [[Balking pattern|Balking]]
| Only execute an action on an object when the object is in a particular state.
| {{no}}
| {{n/a}}
|-
| [[Binding properties pattern|Binding properties]]
| Combining multiple observers to force properties in different objects to be synchronized or coordinated in some way.<ref>[http://c2.com/cgi/wiki?BindingProperties Binding Properties<!-- Bot generated title -->]</ref>
| {{no}}
| {{n/a}}
|-
| [[Compute kernel]]
| The same calculation many times in parallel, differing by integer parameters used with non-branching pointer math into shared arrays, such as [[GPU]]-optimized [[Matrix multiplication]] or [[Convolutional neural network]].
| {{no}}
| {{n/a}}
|-
| [[Double-checked locking]]
| Reduce the overhead of acquiring a lock by first testing the locking criterion (the 'lock hint') in an unsafe manner; only if that succeeds does the actual locking logic proceed.
Can be unsafe when implemented in some language/hardware combinations. It can therefore sometimes be considered an [[anti-pattern]].
| {{yes}}
| {{n/a}}
|-
| [[Event-Based Asynchronous Pattern|Event-based asynchronous]]
| Addresses problems with the asynchronous pattern that occur in multithreaded programs.<ref name="PC#2008">{{cite book|title = Professional C# 2008| first1 = Christian | last1 = Nagel | first2 = Bill | last2 = Evjen | first3 = Jay | last3 = Glynn | first4 = Karli | last4 = Watson | first5 = Morgan | last5 = Skinner|pages = 570–571|publisher = Wiley|year = 2008|isbn = 978-0-470-19137-8|chapter = Event-based Asynchronous Pattern}}</ref>
| {{no}}
| {{n/a}}
|-
| [[Guarded suspension]]
| Manages operations that require both a lock to be acquired and a precondition to be satisfied before the operation can be executed.
| {{no}}
| {{n/a}}
|-
| [[Join-pattern|Join]]
| Join-pattern provides a way to write concurrent, parallel and distributed programs by message passing. Compared to the use of threads and locks, this is a high-level programming model.
| {{no}}
| {{n/a}}
|-
| [[Lock (computer science)|Lock]]
| One thread puts a "lock" on a resource, preventing other threads from accessing or modifying it.<ref>[http://c2.com/cgi/wiki?LockPattern Lock Pattern<!-- Bot generated title -->]</ref>
| {{no}}
| {{yes|PoEAA<ref name = "PoEAA"/>}}
|-
| [[Messaging pattern|Messaging design pattern (MDP)]]
| Allows the interchange of information (i.e. messages) between components and applications.
| {{no}}
| {{n/a}}
|-
| [[Monitor (synchronization)|Monitor object]]
| An object whose methods are subject to [[mutual exclusion]], thus preventing multiple objects from erroneously trying to use it at the same time.
| {{yes}}
| {{n/a}}
|-
| [[Reactor pattern|Reactor]]
| A reactor object provides an asynchronous interface to resources that must be handled synchronously.
| {{yes}}
| {{n/a}}
|-
| [[Read-write lock]]
| Allows concurrent read access to an object, but requires exclusive access for write operations. An underlying semaphore might be used for writing, and a [[Copy-on-write]] mechanism may or may not be used.
| {{no}}
| {{n/a}}
|-
| [[Scheduler pattern|Scheduler]]
| Explicitly control when threads may execute single-threaded code.
| {{no}}
| {{n/a}}
|-
| Service handler pattern
| For each request, a server spawns a dedicated client handler to handle a request.<ref>{{cite journal |last1=Francalanza |first1=Adrian |last2=Tabone |first2=Gerard |title=ElixirST: A session-based type system for Elixir modules |journal=Journal of Logical and Algebraic Methods in Programming |date=October 2023 |volume=135 |doi=10.1016/j.jlamp.2023.100891|s2cid=251442539 }}</ref> Also referred to as ''thread-per-session''.<ref>{{cite journal |last1=Schmidt |first1=Douglas C. |last2=Vinoski |first2=Steve |title=Object Interconnections: Comparing Alternative Programming Techniques for Multi-threaded CORBA Servers (Column 7) |date=July–August 1996 |journal=SIGS C++ Report |url=https://www.dre.vanderbilt.edu/~schmidt/PDF/C++-report-col7.pdf |s2cid=2654843}}</ref>
| {{no}}
| {{n/a}}
|-
| [[Thread pool]]
| A number of threads are created to perform a number of tasks, which are usually organized in a queue. Typically, there are many more tasks than threads. Can be considered a special case of the [[object pool]] pattern.
| {{no}}
| {{n/a}}
|-
| [[Thread-specific storage]]
| Static or "global" memory local to a thread.
| {{yes}}
| {{n/a}}
|-
| Safe Concurrency with Exclusive Ownership
| Avoiding the need for runtime concurrent mechanisms, because exclusive ownership can be proven. This is a notable capability of the Rust language, but compile-time checking isn't the only means, a programmer will often manually design such patterns into code - omitting the use of locking mechanism because the programmer assesses that a given variable is never going to be concurrently accessed.
| {{no}}
| {{n/a}}
|-
| CPU atomic operation
| x86 and other CPU architectures support a range of atomic instructions that guarantee memory safety for modifying and accessing primitive values (integers). For example, two threads may both increment a counter safely. These capabilities can also be used to implement the mechanisms for other concurrency patterns as above. The [[C Sharp (programming language)|C#]] language uses the [https://docs.microsoft.com/en-us/dotnet/api/system.threading.interlocked?view=net-5.0 Interlocked] class for these capabilities.
| {{no}}
| {{n/a}}
|}