📄 pat5g-1.htm
字号:
<HTML><HEAD> <TITLE>Observer</TITLE>
<SCRIPT>
function setFocus() {
if ((navigator.appName != "Netscape") && (parseFloat(navigator.appVersion) == 2)) {
return;
} else {
self.focus();
}
}
</SCRIPT>
</HEAD>
<BODY BGCOLOR = #FFFFFF
onLoad="setFocus()";>
<A NAME="top"></A>
<A NAME="Observer"></A>
<A NAME="intent"></A>
<H2><A HREF="#alsoknownas"><IMG SRC="down3-1.gif" tppabs="http://ultra/development/DesignPatterns/lowres/gifsb/down3.gif" BORDER=0 ALT="next:
Also Known As"></A> Intent</H2>
<A NAME="auto1000"></A>
<P>Define a one-to-many dependency between objects so that when one
object changes state, all its dependents are notified and updated
automatically.</P>
<A NAME="alsoknownas"><A>
<H2><A HREF="#motivation"><IMG SRC="down3-1.gif" tppabs="http://ultra/development/DesignPatterns/lowres/gifsb/down3.gif" BORDER=0 ALT="next:
Motivation"></A> Also Known As</H2>
<A NAME="auto1001"></A>
<P>Dependents, Publish-Subscribe</P>
<A NAME="motivation"></A>
<H2><A HREF="#applicability"><IMG SRC="down3-1.gif" tppabs="http://ultra/development/DesignPatterns/lowres/gifsb/down3.gif" BORDER=0
ALT="next: Applicability"></A> Motivation</H2>
<A NAME="auto1002"></A>
<P>A common side-effect of partitioning a system into a collection of
cooperating classes is the need to maintain consistency between
related objects. You don't want to achieve consistency by making the
classes tightly coupled, because that reduces their reusability.</P>
<A NAME="auto1003"></A>
<P>For example, many graphical user interface toolkits separate the
presentational aspects of the user interface from the underlying
application data [<A HREF="bibfs-1.htm#krasner_mvc" tppabs="http://ultra/development/DesignPatterns/lowres/bibfs.htm#krasner_mvc" TARGET="_mainDisplayFrame">KP88</A>, <A HREF="bibfs-1.htm#interviews_composition" tppabs="http://ultra/development/DesignPatterns/lowres/bibfs.htm#interviews_composition" TARGET="_mainDisplayFrame">LVC89</A>, <A HREF="bibfs-1.htm#atk" tppabs="http://ultra/development/DesignPatterns/lowres/bibfs.htm#atk" TARGET="_mainDisplayFrame">P+88</A>, <A HREF="bibfs-1.htm#et++" tppabs="http://ultra/development/DesignPatterns/lowres/bibfs.htm#et++" TARGET="_mainDisplayFrame">WGM88</A>].
Classes defining application data and presentations can be reused
independently. They can work together, too. Both a spreadsheet object
and bar chart object can depict information in the same application data
object using different presentations. The spreadsheet and the bar chart
don't know about each other, thereby letting you reuse only the one you
need. But they <EM>behave</EM> as though they do. When the user changes the
information in the spreadsheet, the bar chart reflects the changes
immediately, and vice versa.</P>
<P ALIGN=CENTER><IMG SRC="obser023-1.gif" tppabs="http://ultra/development/DesignPatterns/lowres/Pictures/obser023.gif"></P>
<A NAME="auto1004"></A>
<P>This behavior implies that the spreadsheet and bar chart are dependent
on the data object and therefore should be notified of any change in
its state. And there's no reason to limit the number of dependent
objects to two; there may be any number of different user interfaces
to the same data.</P>
<A NAME="def-subject"></A>
<P>The Observer pattern describes how to establish these relationships.
The key objects in this pattern are <STRONG>subject</STRONG> and
<STRONG>observer</STRONG>. A subject may have any number of dependent
observers. All observers are notified whenever the subject undergoes
a change in state. In response, each observer will query the subject
to synchronize its state with the subject's state.</P>
<A NAME="auto1005"></A>
<P>This kind of interaction is also known as
<STRONG>publish-subscribe</STRONG>. The subject is the publisher of
notifications. It sends out these notifications without having to know
who its observers are. Any number of observers can subscribe to
receive notifications.</P>
<A NAME="applicability"></A>
<H2><A HREF="#structure"><IMG SRC="down3-1.gif" tppabs="http://ultra/development/DesignPatterns/lowres/gifsb/down3.gif" BORDER=0 ALT="next:
Structure"></A> Applicability</H2>
<A NAME="auto1006"></A>
<P>Use the Observer pattern in any of the following situations:</P>
<UL>
<A NAME="auto1007"></A>
<LI>When an abstraction has two aspects, one dependent on the other.
Encapsulating these aspects in separate objects lets you vary and
reuse them independently.</LI>
<A NAME="auto1008"></A>
<P></P>
<A NAME="auto1009"></A>
<LI>When a change to one object requires changing others, and you
don't know how many objects need to be changed.</LI>
<A NAME="auto1010"></A>
<P></P>
<A NAME="auto1011"></A>
<LI>When an object should be able to notify other objects without making
assumptions about who these objects are. In other words, you don't
want these objects tightly coupled.</LI>
</UL>
<A NAME="structure"></A>
<H2><A HREF="#participants"><IMG SRC="down3-1.gif" tppabs="http://ultra/development/DesignPatterns/lowres/gifsb/down3.gif" BORDER=0 ALT="next:
Participants"></A> Structure</H2>
<P ALIGN=CENTER><IMG SRC="observer-1.gif" tppabs="http://ultra/development/DesignPatterns/lowres/Pictures/observer.gif"></P>
<A NAME="participants"></A>
<H2><A HREF="#collaborations"><IMG SRC="down3-1.gif" tppabs="http://ultra/development/DesignPatterns/lowres/gifsb/down3.gif" BORDER=0
ALT="next: Collaborations"></A> Participants</H2>
<UL>
<A NAME="auto1012"></A>
<LI><B>Subject</B></LI>
<A NAME="auto1013"></A>
<P></P>
<UL>
<A NAME="auto1014"></A>
<LI>knows its observers. Any number of Observer objects may
observe a subject.</LI>
<A NAME="auto1015"></A>
<P><!-- extra space --></P>
<A NAME="auto1016"></A>
<LI>provides an interface for attaching and detaching Observer
objects.</LI>
</UL>
<A NAME="auto1017"></A>
<P></P>
<A NAME="auto1018"></A>
<LI><B>Observer</B></LI>
<A NAME="auto1019"></A>
<P></P>
<UL>
<A NAME="auto1020"></A>
<LI>defines an updating interface for objects that should be
notified of changes in a subject.</LI>
</UL>
<A NAME="auto1021"></A>
<P></P>
<A NAME="auto1022"></A>
<LI><B>ConcreteSubject</B>
<A NAME="auto1023"></A>
<P></P>
<UL>
<A NAME="auto1024"></A>
<LI>stores state of interest to ConcreteObserver objects.
<A NAME="auto1025"></A>
<P><!-- extra space --></P>
<A NAME="auto1026"></A>
<LI>sends a notification to its observers when its state changes.
</UL>
<A NAME="auto1027"></A>
<P></P>
<A NAME="auto1028"></A>
<LI><B>ConcreteObserver</B>
<A NAME="auto1029"></A>
<P></P>
<UL>
<A NAME="auto1030"></A>
<LI>maintains a reference to a ConcreteSubject object.
<A NAME="auto1031"></A>
<P><!-- extra space --></P>
<A NAME="auto1032"></A>
<LI>stores state that should stay consistent with the subject's.
<A NAME="auto1033"></A>
<P><!-- extra space --></P>
<A NAME="auto1034"></A>
<LI>implements the Observer updating interface to keep
its state consistent with the subject's.
</UL>
</UL>
<A NAME="collaborations"></A>
<H2><A HREF="#consequences"><IMG SRC="down3-1.gif" tppabs="http://ultra/development/DesignPatterns/lowres/gifsb/down3.gif" BORDER=0
ALT="next: Consequences"></A> Collaborations</H2>
<UL>
<A NAME="auto1035"></A>
<LI>ConcreteSubject notifies its observers whenever a change
occurs that could make its observers' state inconsistent with its own.</LI>
<A NAME="auto1036"></A>
<P></P>
<A NAME="auto1037"></A>
<LI>After being informed of a change in the concrete subject, a
ConcreteObserver object may query the subject for information.
ConcreteObserver uses this information to reconcile its state with that
of the subject.
<A NAME="auto1038"></A>
<P>The following interaction diagram illustrates the collaborations
between a subject and two observers:</P>
<A NAME="subj-295i"></A>
<P ALIGN=CENTER><IMG SRC="obser022-1.gif" tppabs="http://ultra/development/DesignPatterns/lowres/Pictures/obser022.gif"></P>
<A NAME="auto1039"></A>
<P>Note how the Observer object that initiates the change request
postpones its update until it gets a notification from the subject.
Notify is not always called by the subject. It can be called by an
observer or by another kind of object entirely. The Implementation
section discusses some common variations.</P>
</LI>
</UL>
<A NAME="consequences"></A>
<H2><A HREF="#implementation"><IMG SRC="down3-1.gif" tppabs="http://ultra/development/DesignPatterns/lowres/gifsb/down3.gif" BORDER=0
ALT="next: Implementation"></A> Consequences</H2>
<A NAME="auto1040"></A>
<P>The Observer pattern lets you vary subjects and observers
independently. You can reuse subjects without reusing their
observers, and vice versa. It lets you add observers without
modifying the subject or other observers.</P>
<A NAME="auto1041"></A>
<P>Further benefits and liabilities of the Observer pattern include the
following:</P>
<A NAME="abscoup"></A>
<OL>
<A NAME="auto1042"></A>
<LI><EM>Abstract coupling between Subject and Observer.</EM>
All a subject knows is that it has a list of observers, each
conforming to the simple interface of the abstract Observer class.
The subject doesn't know the concrete class of any observer. Thus the
coupling between subjects and observers is abstract and minimal.
<A NAME="auto1043"></A>
<P>Because Subject and Observer aren't tightly coupled, they can belong to
different layers of abstraction in a system. A lower-level subject
can communicate and inform a higher-level observer, thereby keeping the
system's layering intact. If Subject and Observer are lumped
together, then the resulting object must either span two layers (and
violate the layering), or it must be forced to live in one layer or
the other (which might compromise the layering abstraction).</P>
</LI>
<A NAME="auto1044"></A>
<P></P>
<A NAME="auto1045"></A>
<LI><EM>Support for broadcast communication.</EM>
Unlike an ordinary request, the notification that a subject sends
needn't specify its receiver. The notification is broadcast
automatically to all interested objects that subscribed to it. The
subject doesn't care how many interested objects exist; its only
responsibility is to notify its observers. This gives you the freedom
to add and remove observers at any time. It's up to the observer to
handle or ignore a notification.</LI>
<A NAME="auto1046"></A>
<P></P>
<A NAME="update-limit"></A>
<LI><EM>Unexpected updates.</EM>
Because observers have no knowledge of each other's presence, they can
be blind to the ultimate cost of changing the subject. A seemingly
innocuous operation on the subject may cause a cascade of updates to
observers and their dependent objects. Moreover, dependency criteria
that aren't well-defined or maintained usually lead to spurious
updates, which can be hard to track down.
<A NAME="update-protocol"></A>
<P>This problem is aggravated by the fact that the simple update protocol
provides no details on <EM>what</EM> changed in the subject. Without
additional protocol to help observers discover what changed, they may
be forced to work hard to deduce the changes.</P>
</LI>
</OL>
<A NAME="implementation"></A>
<H2><A HREF="#samplecode"><IMG SRC="down3-1.gif" tppabs="http://ultra/development/DesignPatterns/lowres/gifsb/down3.gif" BORDER=0 ALT="next:
Sample Code"></A> Implementation</H2>
<A NAME="auto1047"></A>
<P>Several issues related to the implementation of the dependency
mechanism are discussed in this section.</P>
<OL>
<A NAME="subj-map-obsrv"></A>
<LI><EM>Mapping subjects to their observers.</EM>
The simplest way for a subject to keep track of the observers it
should notify is to store references to them explicitly in the
subject. However, such storage may be too expensive when there are
many subjects and few observers. One solution is to trade space for
time by using an associative look-up (e.g., a hash table) to maintain
the subject-to-observer mapping. Thus a subject with no observers
does not incur storage overhead. On the other hand, this approach
increases the cost of accessing the observers.</LI>
<A NAME="auto1048"></A>
<P></P>
<A NAME="subj-mult-obsrv"></A>
<LI><EM>Observing more than one subject.</EM>
It might make sense in some situations for an observer to depend on
more than one subject. For example, a spreadsheet may depend on more
than one data source. It's necessary to extend the Update interface
in such cases to let the observer know <EM>which</EM> subject is sending
the notification. The subject can simply pass itself as a parameter
in the Update operation, thereby letting the observer know which
subject to examine.</LI>
<A NAME="auto1049"></A>
<P></P>
<A NAME="update-trigger"></A>
<LI><EM>Who triggers the update?</EM>
The subject and its observers rely on the notification mechanism to
stay consistent. But what object actually calls Notify to trigger the
update? Here are two options:</LI>
<A NAME="auto1050"></A>
<P></P>
<OL TYPE=a>
<A NAME="auto1051"></A>
<LI>Have state-setting operations on Subject call Notify after they
change the subject's state. The advantage of this approach is that
clients don't have to remember to call Notify on the subject. The
disadvantage is that several consecutive operations will cause
several consecutive updates, which may be inefficient.</LI>
<A NAME="auto1052"></A>
<P></P>
<A NAME="auto1053"></A>
<LI>Make clients responsible for calling Notify at the right time.
The advantage here is that the client can wait to trigger the update
until after a series of state changes has been made, thereby
avoiding needless intermediate updates. The disadvantage is that
clients have an added responsibility to trigger the update. That
makes errors more likely, since clients might forget to call Notify.</LI>
</OL>
<A NAME="auto1054"></A>
<P></P>
<A NAME="subj-avoid-dangle"></A>
<LI><EM>Dangling references to deleted subjects.</EM>
Deleting a subject should not produce dangling references in its
observers. One way to avoid dangling references is to make the
subject notify its observers as it is deleted so that they can reset
their reference to it. In general, simply deleting the observers is not
an option, because other objects may reference them, or they may be
observing other subjects as well.</LI>
<A NAME="auto1055"></A>
<P></P>
<A NAME="auto1056"></A>
<LI><EM>Making sure Subject state is self-consistent before
notification.</EM>
It's important to make sure Subject state is self-consistent before
calling Notify, because observers query the subject for its current
state in the course of updating their own state.
<A NAME="auto1057"></A>
<P>This self-consistency rule is easy to violate unintentionally when
Subject subclass operations call inherited operations. For example,
the notification in the following code sequence is trigged when the
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -