The Observer pattern for PHP mode design

This is the fifth article I wrote in PHP pattern design. The previous four articles in the continuous learning to deepen the understanding, to today again look at the Observer model, feel very easy to understand. This may be the result of our multiplying. I hope we can keep improving.

Starting with the name, the observer of the Observer pattern has a large amount of three words. Children who have played a lot of online games should know that even the landlord, in addition to the player, there is a role called "observer." In the pattern design that we are talking about today, so does the observer. First, you have a "subject". Only with a theme, the observer can carry a small stool to gather in a pile. Second, observers must also have their own operations. Otherwise, it doesn't make any sense to get together in a bunch of nothing.

From a process-oriented point of view, the first is the observer to the subject registration , after registration, the topic then notify the Observer to make corresponding actions , the whole thing is over.

From an object-oriented perspective, the topic provides an interface for registration and notification, and the Observer provides an interface for its own operations. (These observers have a single interface.) The observer uses the interface of the topic to register the subject, and the subject uses the Observer interface to notify the Observer. The coupling degree is quite low.

How do I implement an observer registration? It's easy to give us ideas through the previous registrant model and add these objects to a registered tree. How to notify? This is even simpler, by traversing the registration tree, allowing each object to implement the operations provided by its interface.

<?PHP//Topic InterfaceInterfacesubject{ Public functionRegister (Observer$observer);  Public functionnotify ();}//Viewer InterfaceInterfaceobserver{ Public functionwatch ();}//ThemeclassActionImplementssubject{ Public $_observers=Array();  Public functionRegister (Observer$observer){         $this->_observers[]=$observer; }      Public functionNotify () {foreach($this->_observers as $observer) {             $observer-Watch (); }     } }//observersclassCatImplementsobserver{ Public functionWatch () {Echo"Cat Watches Tv; } }  classDogImplementsobserver{ Public functionWatch () {Echo"Dog Watches Tv; } }  classPeopleImplementsobserver{ Public functionWatch () {Echo"People watches tv; } }//Application Examples$action=NewAction ();$action->register (NewCat ());$action->register (Newpeople ());$action->register (NewDog ());$action->notify ();

The so-called pattern, more is an idea, there is no need to rigidly adhere to the code details. The Observer pattern represents more than two separate classes that use interfaces to accomplish something that should be complicated. Without the use of theme classes, we also need to constantly iterate through the creation of instances and perform operations. Now it's just a matter of creating an instance, and the only way to do it is to call a notification.

From the beginning of the singleton mode I consider how to implement the code, and now most of the implementation of the Code, in fact, is built on the basis of the accumulation of the previous. Really feel that through continuous learning design patterns can greatly deepen the thinking of object-oriented programming. Of course, it is not good, it is best to put more practice to go to it ~~

Related article "Handling exception information using the Observer pattern"

Turn https://www.cnblogs.com/DeanChopper/p/4830134.html

The Observer pattern for PHP mode design