disc5-1.htm

四人帮《设计模式》一书英文版本

programmer would use Mediator.</P>
<A NAME="disc5-19"></A>
<A NAME="decouple-sandr"></A>
<H2><A HREF="#summary"><IMG SRC="down3-1.gif" tppabs="http://ultra/development/DesignPatterns/lowres/gifsb/down3.gif" BORDER=0 ALT="next: Summary"></A>
Decoupling Senders and Receivers</H2>
<A NAME="disc5-20"></A>
<P>When collaborating objects refer to each other directly, they become
dependent on each other, and that can have an adverse impact on the
layering and reusability of a system.  Command, Observer, Mediator,
and Chain of Responsibility address how you can decouple senders and
receivers, but with different trade-offs.</P>
<A NAME="disc5-21"></A>
<P>The Command pattern supports decoupling by using a Command object to
define the binding between a sender and receiver:</P>
<A NAME="disc5-22"></A>
<P ALIGN=CENTER><IMG SRC="cmddec-1.gif" tppabs="http://ultra/development/DesignPatterns/lowres/Pictures/cmddec.gif"></P>
<A NAME="disc5-23"></A>
<P>The Command object provides a simple interface for issuing the request
(that is, the Execute operation).  Defining the sender-receiver
connection in a separate object lets the sender work with different
receivers.  It keeps the sender decoupled from the receivers, making
senders easy to reuse.  Moreover, you can reuse the Command object to
parameterize a receiver with different senders.  The Command pattern
nominally requires a subclass for each sender-receiver connection,
although the pattern describes implementation techniques that avoid
subclassing.</P>
<A NAME="disc5-24"></A>
<A NAME="media-vs-obsrv2"></A>
<P>The Observer pattern decouples senders (subjects) from receivers
(observers) by defining an interface for signaling changes in
subjects.  Observer defines a looser sender-receiver binding than
Command, since a subject may have multiple observers, and their number
can vary at run-time.</P>
<A NAME="disc5-25"></A>
<A NAME="subj-347i"></A>
<P ALIGN=CENTER><IMG SRC="obser024-1.gif" tppabs="http://ultra/development/DesignPatterns/lowres/Pictures/obser024.gif"></P>
<A NAME="disc5-26"></A>
<P>The Subject and Observer interfaces in the Observer pattern are
designed for communicating changes.  Therefore the Observer pattern is
best for decoupling objects when there are data dependencies between
them.</P>
<A NAME="disc5-27"></A>
<P>The Mediator pattern decouples objects by having them refer to each
other indirectly through a Mediator object.</P>
<A NAME="disc5-28"></A>
<A NAME="media-348i"></A>
<P ALIGN=CENTER><IMG SRC="media035-1.gif" tppabs="http://ultra/development/DesignPatterns/lowres/Pictures/media035.gif"></P>
<A NAME="disc5-29"></A>
<P>A Mediator object routes requests between Colleague objects and
centralizes their communication.  Consequently, colleagues can only
talk to each other through the Mediator interface.  Because this
interface is fixed, the Mediator might have to implement its own
dispatching scheme for added flexibility. Requests can be encoded and
arguments packed in such a way that colleagues can request an
open-ended set of operations.</P>
<A NAME="disc5-30"></A>
<P>The Mediator pattern can reduce subclassing in a system, because it
centralizes communication behavior in one class instead of
distributing it among subclasses. However, <EM>ad hoc</EM> dispatching schemes
often decrease type safety.</P>
<A NAME="disc5-31"></A>
<P>Finally, the Chain of Responsibility pattern decouples the sender from
the receiver by passing the request along a chain of potential
receivers:</P>
<A NAME="disc5-32"></A>
<P ALIGN=CENTER><IMG SRC="chain093-1.gif" tppabs="http://ultra/development/DesignPatterns/lowres/Pictures/chain093.gif"></P>
<A NAME="disc5-33"></A>
<A NAME="media-vs-cor"></A>
<P>Since the interface between senders and receivers is fixed, Chain of
Responsibility may also require a custom dispatching scheme.  Hence it
has the same type-safety drawbacks as Mediator.  Chain of
Responsibility is a good way to decouple the sender and the receiver
if the chain is already part of the system's structure, and one of
several objects may be in a position to handle the request.  Moreover,
the pattern offers added flexibility in that the chain can be changed or
extended easily.</P>
<A NAME="disc5-34"></A>
<A NAME="summary"></A>
<H2><A HREF="#last"><IMG SRC="down3-1.gif" tppabs="http://ultra/development/DesignPatterns/lowres/gifsb/down3.gif" BORDER=0 ALT="next: navigation"></A>
Summary</H2>
<A NAME="disc5-35"></A>
<P>With few exceptions, behavioral design patterns complement and
reinforce each other.  A class in a chain of responsibility, for
example, will probably include at least one application of
<A HREF="pat5jfs-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/pat5jfs.htm" TARGET="_mainDisplayFrame">Template Method (325)</A>.
The template method can use
primitive operations to determine whether the object should handle the
request and to choose the object to forward to.  The chain can use the
Command pattern to represent requests as objects.
<A HREF="pat5cfs-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/pat5cfs.htm" TARGET="_mainDisplayFrame">Interpreter (243)</A> can use the State pattern to
define parsing contexts.  An iterator can traverse an aggregate, and a
visitor can apply an operation to each element in the aggregate.</P>
<A NAME="disc5-36"></A>
<P>Behavioral patterns work well with other patterns, too. For example, a
system that uses the <A HREF="pat4cfs-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/pat4cfs.htm" TARGET="_mainDisplayFrame">Composite (163)</A> pattern might use
a visitor to perform operations on components of the
composition.  It could use Chain of Responsibility to let components
access global properties through their parent.  It could also use
<A HREF="pat4dfs-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/pat4dfs.htm" TARGET="_mainDisplayFrame">Decorator (175)</A>
to override these properties on parts
of the composition.  It could use the Observer pattern to tie one
object structure to another and the State pattern to let a component
change its behavior as its state changes. The composition itself might
be created using the approach in
<A HREF="pat3bfs-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/pat3bfs.htm" TARGET="_mainDisplayFrame">Builder (97)</A>, and it
might be treated as a
<A HREF="pat3dfs-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/pat3dfs.htm" TARGET="_mainDisplayFrame">Prototype (117)</A> by some other
part of the system.</P>
<A NAME="disc5-37"></A>
<P>Well-designed object-oriented systems are just like this&#151;they have
multiple patterns embedded in them&#151;but not because their designers
necessarily thought in these terms.  Composition at the <EM>pattern</EM>
level rather than the class or object levels lets us achieve the same
synergy with greater ease.</P>
<A NAME="disc5-38"></A>
<A NAME="last"></A>
<P><A HREF="#top"><IMG SRC="up3-1.gif" tppabs="http://ultra/development/DesignPatterns/lowres/gifsb/up3.gif" BORDER=0></A><BR>
<A HREF="chap6fs-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/chap6fs.htm" TARGET="_mainDisplayFrame"><IMG SRC="rightar3-1.gif" tppabs="http://ultra/development/DesignPatterns/lowres/gifsb/rightar3.gif"
	ALIGN=TOP BORDER=0></A> <A HREF="chap6fs-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/chap6fs.htm"
	TARGET="_mainDisplayFrame">Conclusion</A><BR>
<A HREF="pat5kfs-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/pat5kfs.htm" TARGET="_mainDisplayFrame"><IMG SRC="leftarr3-1.gif" tppabs="http://ultra/development/DesignPatterns/lowres/gifsb/leftarr3.gif"
	ALIGN=TOP BORDER=0></A> <A HREF="pat5kfs-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/pat5kfs.htm"
	TARGET="_mainDisplayFrame">Visitor</A>
</P>

<HR>

<A NAME="footnote12"></A>
<P><SUP>12</SUP>This theme runs through other kinds of patterns, too.
<A HREF="pat3afs-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/pat3afs.htm" TARGET="_mainDisplayFrame">Abstract Factory (87)</A>,
<A HREF="pat3bfs-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/pat3bfs.htm" TARGET="_mainDisplayFrame">Builder (97)</A>, and
<A HREF="pat3dfs-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/pat3dfs.htm" TARGET="_mainDisplayFrame">Prototype (117)</A>
all encapsulate knowledge about how
objects are created.
<A HREF="pat4dfs-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/pat4dfs.htm" TARGET="_mainDisplayFrame">Decorator (175)</A>
encapsulates responsibility that can be added to an object.
<A HREF="pat4bfs-1.htm" tppabs="http://ultra/development/DesignPatterns/lowres/pat4bfs.htm" TARGET="_mainDisplayFrame">Bridge (151)</A>
separates an abstraction
from its implementation, letting them vary independently.
</P>

</BODY>

</HTML>