Editing Software design pattern (section)

=== [[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}}
|}