The observer pattern is intended to resolve a one-to-many dependency situation where all dependent objects are notified and automatically updated when the state of the dependent object changes. As a simple example, if an attribute state of a character in a game changes, it may be assumed that the role's level has been upgraded, then the corresponding model presentation in the game scene ([Dependency point 1]) needs to be adjusted, and the role properties on the UI interface ([Dependency point 2] The description details also need to be updated in time to show the new level value to the player. This side of [Dependency point 1] and [Dependency point 2] are dependent on the properties of the role, and for both of these dependencies, the properties are sensitive to them, and they need to be able to perceive changes in these properties in a timely manner. In this case, you can consider using the Observer mode. The pattern's class diagram reference is as follows:
The coding structure of the pattern is referenced below:
1 namespaceObserver2 {3 //--------Observer--------4 classSubject;5 classIObserver6 {7 Public:8 //some code here .....9 Virtual voidUpdate (subject* psubject) =0;Ten One};//class IObserver A - classConcreteObserver1: PublicIObserver - { the Public: - //some code here ..... - Virtual voidUpdate (subject* psubject)Override { - //some code here ..... + Constauto& thestate = psubject->getState (); - //Some other code here ..... + } A at};//class ConcreteObserver1 - - //--------Subject-------- - classSubject - { - Public: in //some code here ..... - Virtual voidRegisteobserver (iobserver* pobserver) =0; to Virtual voidUnregisterobserver (iobserver* pobserver) =0; + Virtual voidNotify () =0; - the};//class Subject * $ classConcreteSubject: PublicSubjectPanax Notoginseng { - Public: the //some code here ..... + Virtual voidRegisteobserver (iobserver* pobserver)Override { A //some code here ..... the M_listobservers.push_back (pobserver); + } - $ Virtual voidUnregisterobserver (iobserver* pobserver)Override { $ //some code here ..... -Auto iter =Std::find (M_listobservers.begin (), M_listobservers.end (), pobserver); - if(ITER! =M_listobservers.end ()) { the M_listobservers.erase (ITER); - }Wuyi } the - Virtual voidNotify ()Override { WuFor_each (M_listobservers.begin (), M_listobservers.end (), [] (Constiobserver* pObj) {pobj->update ( This); }); - } About $ Private: -Std::list<iobserver*>m_listobservers; - -};//class ConcreteSubject A +}//namespace ObserverObserver pattern Coding structure Reference
Observer model for object-oriented design, the personal view of its significance is very significant. Imagine that without the design of the pattern, the coupling between observer and subject will be greatly enhanced. More frightening is that if a observer depends on more than one subject, then the system will be complex, and later maintenance will be quite scary. The Observer mode minimizes the dependence of observer and subject, simply notify out, and for subject does not know (and does not need to know) what kinds of observer are different objects, It is only responsible for the status changes in time to notify the registered observers. Thus observer and subject can naturally form hierarchical structure design, their respective responsibilities are distinct.
Is there a way to implement observer in some languages that do not have an object-oriented mechanism? Like the C language. The answer is yes. The technical means of implementation are also simple: function pointer, specifically not detailed. Of course, this technology is also applicable in C + +, but since people support object-oriented, the natural majority will not think of function pointers this laborious technical means. But with the development of language, evolution, the emergence of std::function technology, in fact, will make the design of observer model more convenient, and its coupling will be further reduced, interested students can think on their own. (Hint: std::function+auto|std::bind)
"Behavioral" Observer mode