Behavioral Patterns
Rules of thumb
-
Behavioral patterns are concerned with the assignment of responsibilities
between objects, or, encapsulating behavior in an object and delegating
requests to it. [GOF, p222]
-
Chain of Responsibility, Command, Mediator, and
Observer, address how you can decouple senders and receivers,
but with different trade-offs. Chain of Responsibility passes a
sender request along a chain of potential receivers. Command normally
specifies a sender-receiver connection with a subclass. Mediator
has senders and receivers reference each other indirectly.
Observer defines a very decoupled interface that allows for
multiple receivers to be configured at run-time. [GOF, p347]
-
Chain of Responsibility can use Command to represent requests
as objects. [GOF, p349]
-
Chain of Responsibility is often applied in conjunction with
Composite. There, a component's parent can act as its successor.
[GOF, p232]
-
Command and Memento act as magic tokens to be passed
around and invoked at a later time. In Command, the token
represents a request; in Memento, it represents the internal
state of an object at a particular time. Polymorphism is important
to Command, but not to Memento because its interface is
so narrow that a memento can only be passed as a value. [GOF, p346]
-
Command can use Memento to maintain the state required
for an undo operation. [GOF, p242]
-
MacroCommands can be implemented with Composite. [GOF, p242]
-
A Command that must be copied before being placed on a history
list acts as a Prototype. [GOF, p242]
-
Interpreter can use State to define parsing contexts.
[GOF, p349]
-
The abstract syntax tree of Interpreter is a Composite
(therefore Iterator and Visitor are also applicable).
[GOF, p255]
-
Terminal symbols within Interpreter's abstract syntax tree can
be shared with Flyweight. [GOF. p255]
-
Iterator can traverse a Composite. Visitor can
apply an operation over a Composite. [GOF, p173]
-
Polymorphic Iterators rely on Factory Methods to instantiate
the appropriate Iterator subclass. [GOF, p271]
-
Mediator and Observer are competing patterns. The
difference between them is that Observer distributes
communication by introducing "observer" and "subject" objects, whereas
a Mediator object encapsulates the communication between other
objects. We've found it easier to make reusable Observers
and Subjects than to make reusable Mediators. [GOF, p346]
-
On the other hand, Mediator can leverage Observer for
dynamically registering colleagues and communicating with them. [GOF,
p282]
-
Mediator is similar to Facade in that it abstracts
functionality of existing classes. Mediator
abstracts/centralizes arbitrary communication between colleague
objects, it routinely "adds value", and it is known/referenced by the
colleague objects (i.e. it defines a multidirectional protocol). In
contrast, Facade defines a simpler interface to a subsystem, it
doesn't add new functionality, and it is not known by the subsystem
classes (i.e. it defines a unidirectional protocol where it makes
requests of the subsystem classes but not vice versa). [GOF, p193]
-
Memento is often used in conjunction with Iterator. An
Iterator can use a Memento to capture the state of an
iteration. The Iterator stores the Memento
internally. [GOF, p271]
-
State is like Strategy except in its intent. [Coplien,
Mar96, p88]
-
Flyweight explains when and how State objects can
be shared. [GOF, p313]
-
State objects are often Singletons. [GOF, p313]
-
Strategy lets you change the guts of an object.
Decorator lets you change the skin. [GOF, p184]
-
Strategy is to algorithm. as Builder is to creation.
[Icon, p8-13]
-
Strategy has 2 different implementations, the first is similar
to State. The difference is in binding times (Strategy
is a bind-once pattern, whereas State is more dynamic).
[Coplien, Mar96, p88]
-
Strategy objects often make good Flyweights. [GOF, p323]
-
Strategy is like Template Method except in its
granularity. [Coplien, Mar96, p88]
-
Template Method uses inheritance to vary part of an algorithm.
Strategy uses delegation to vary the entire algorithm. [GOF, p330]
-
The Visitor pattern is like a more powerful Command
pattern because the visitor may initiate whatever is appropriate
for the kind of object it encounters. [Johnson, Huni, Engel, 1995, p8]