📄 pat5g.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 = #FFFFFFonLoad="setFocus()";><A NAME="top"></A><A NAME="Observer"></A><A NAME="intent"></A><H2><A HREF="#alsoknownas"><IMG SRC="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 oneobject changes state, all its dependents are notified and updatedautomatically.</P><A NAME="alsoknownas"><A><H2><A HREF="#motivation"><IMG SRC="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="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 ofcooperating classes is the need to maintain consistency betweenrelated objects. You don't want to achieve consistency by making theclasses tightly coupled, because that reduces their reusability.</P><A NAME="auto1003"></A><P>For example, many graphical user interface toolkits separate thepresentational aspects of the user interface from the underlyingapplication data [<A HREF="bibfs.htm#krasner_mvc" TARGET="_mainDisplayFrame">KP88</A>, <A HREF="bibfs.htm#interviews_composition" TARGET="_mainDisplayFrame">LVC89</A>, <A HREF="bibfs.htm#atk" TARGET="_mainDisplayFrame">P+88</A>, <A HREF="bibfs.htm#et++" TARGET="_mainDisplayFrame">WGM88</A>].Classes defining application data and presentations can be reusedindependently. They can work together, too. Both a spreadsheet objectand bar chart object can depict information in the same application dataobject using different presentations. The spreadsheet and the bar chartdon't know about each other, thereby letting you reuse only the one youneed. But they <EM>behave</EM> as though they do. When the user changes theinformation in the spreadsheet, the bar chart reflects the changesimmediately, and vice versa.</P><P ALIGN=CENTER><IMG SRC="Pictures/obser023.gif"></P><A NAME="auto1004"></A><P>This behavior implies that the spreadsheet and bar chart are dependenton the data object and therefore should be notified of any change inits state. And there's no reason to limit the number of dependentobjects to two; there may be any number of different user interfacesto 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 dependentobservers. All observers are notified whenever the subject undergoesa change in state. In response, each observer will query the subjectto 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 ofnotifications. It sends out these notifications without having to knowwho its observers are. Any number of observers can subscribe toreceive notifications.</P><A NAME="applicability"></A><H2><A HREF="#structure"><IMG SRC="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 andreuse them independently.</LI><A NAME="auto1008"></A><P></P><A NAME="auto1009"></A><LI>When a change to one object requires changing others, and youdon'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 makingassumptions about who these objects are. In other words, you don'twant these objects tightly coupled.</LI></UL><A NAME="structure"></A><H2><A HREF="#participants"><IMG SRC="gifsb/down3.gif" BORDER=0 ALT="next: Participants"></A> Structure</H2> <P ALIGN=CENTER><IMG SRC="Pictures/observer.gif"></P><A NAME="participants"></A><H2><A HREF="#collaborations"><IMG SRC="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="gifsb/down3.gif" BORDER=0 ALT="next: Consequences"></A> Collaborations</H2><UL><A NAME="auto1035"></A><LI>ConcreteSubject notifies its observers whenever a changeoccurs 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, aConcreteObserver object may query the subject for information.ConcreteObserver uses this information to reconcile its state with thatof the subject.<A NAME="auto1038"></A><P>The following interaction diagram illustrates the collaborationsbetween a subject and two observers:</P><A NAME="subj-295i"></A><P ALIGN=CENTER><IMG SRC="Pictures/obser022.gif"></P><A NAME="auto1039"></A><P>Note how the Observer object that initiates the change requestpostpones its update until it gets a notification from the subject.Notify is not always called by the subject. It can be called by anobserver or by another kind of object entirely. The Implementationsection discusses some common variations.</P></LI></UL><A NAME="consequences"></A><H2><A HREF="#implementation"><IMG SRC="gifsb/down3.gif" BORDER=0 ALT="next: Implementation"></A> Consequences</H2> <A NAME="auto1040"></A><P>The Observer pattern lets you vary subjects and observersindependently. You can reuse subjects without reusing theirobservers, and vice versa. It lets you add observers withoutmodifying the subject or other observers.</P><A NAME="auto1041"></A><P>Further benefits and liabilities of the Observer pattern include thefollowing:</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, eachconforming to the simple interface of the abstract Observer class.The subject doesn't know the concrete class of any observer. Thus thecoupling between subjects and observers is abstract and minimal.<A NAME="auto1043"></A><P>Because Subject and Observer aren't tightly coupled, they can belong todifferent layers of abstraction in a system. A lower-level subjectcan communicate and inform a higher-level observer, thereby keeping thesystem's layering intact. If Subject and Observer are lumpedtogether, then the resulting object must either span two layers (andviolate the layering), or it must be forced to live in one layer orthe 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 sendsneedn't specify its receiver. The notification is broadcastautomatically to all interested objects that subscribed to it. Thesubject doesn't care how many interested objects exist; its onlyresponsibility is to notify its observers. This gives you the freedomto add and remove observers at any time. It's up to the observer tohandle 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 canbe blind to the ultimate cost of changing the subject. A seeminglyinnocuous operation on the subject may cause a cascade of updates toobservers and their dependent objects. Moreover, dependency criteriathat aren't well-defined or maintained usually lead to spuriousupdates, which can be hard to track down.<A NAME="update-protocol"></A><P>This problem is aggravated by the fact that the simple update protocolprovides no details on <EM>what</EM> changed in the subject. Withoutadditional protocol to help observers discover what changed, they maybe forced to work hard to deduce the changes.</P></LI></OL><A NAME="implementation"></A><H2><A HREF="#samplecode"><IMG SRC="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 dependencymechanism 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 itshould notify is to store references to them explicitly in thesubject. However, such storage may be too expensive when there aremany subjects and few observers. One solution is to trade space fortime by using an associative look-up (e.g., a hash table) to maintainthe subject-to-observer mapping. Thus a subject with no observersdoes not incur storage overhead. On the other hand, this approachincreases 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 onmore than one subject. For example, a spreadsheet may depend on morethan one data source. It's necessary to extend the Update interfacein such cases to let the observer know <EM>which</EM> subject is sendingthe notification. The subject can simply pass itself as a parameterin the Update operation, thereby letting the observer know whichsubject 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 tostay consistent. But what object actually calls Notify to trigger theupdate? 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 theychange the subject's state. The advantage of this approach is thatclients don't have to remember to call Notify on the subject. Thedisadvantage is that several consecutive operations will causeseveral 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 updateuntil after a series of state changes has been made, therebyavoiding needless intermediate updates. The disadvantage is thatclients have an added responsibility to trigger the update. Thatmakes 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 itsobservers. One way to avoid dangling references is to make thesubject notify its observers as it is deleted so that they can resettheir reference to it. In general, simply deleting the observers is not an option, because other objects may reference them, or they may beobserving other subjects as well.</LI><A NAME="auto1055"></A><P></P><A NAME="auto1056"></A><LI><EM>Making sure Subject state is self-consistent beforenotification.</EM>It's important to make sure Subject state is self-consistent beforecalling Notify, because observers query the subject for its currentstate in the course of updating their own state.<A NAME="auto1057"></A><P>This self-consistency rule is easy to violate unintentionally whenSubject 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 + -