This article describes the observer pattern of php pattern design. Share it for your reference, as follows:
This is the fifth article of "PHP Pattern Design" I wrote. The previous four articles are constantly learning and deepening their understanding. Today, I look at the observer model and find it very easy to understand. This may be the result of our accumulation of small amounts. Hopefully, we can continue to improve.
The beginning starts with the name, and the three words "observer mode" of the observer are very informative. Children who have played many online games should know that even Landlords, in addition to players, there is also a character called "Observer". The same is true of the pattern design we are talking about today. First, there must be a "theme". Only with a theme can observers move small stools and gather together. Secondly, the observer must also have his own operations. Otherwise, it would be meaningless to get together in a bunch of things.
From a process-oriented perspective, the first thing is that the observer registers with the topic. After registering, the subject notifies the observer to make corresponding operations, and the whole thing is over.
From an object-oriented perspective, topics provide interfaces for registration and notifications, and observers provide interfaces for their own operations. (These observers have one same interface.) The observer uses the subject's interface to register with the subject, and the subject uses the observer interface to notify the observer. The coupling degree is quite low.
How to implement observer registration? It is easy to provide us with ideas through the previous registrant model, just add these objects to a registration tree. How to notify? This is even simpler, traversing the registration tree, allowing each object to implement the operations provided by its interface.
<?php
// Theme interfaceinterface Subject{
public function register(Observer $observer);
public function notify();
}
// Observer interfaceinterface Observer{
public function watch();
}
// themeclass Action implements Subject{
public $_observers=array();
public function register(Observer $observer){
$this->_observers[]=$observer;
}
public function notify(){
foreach ($this->_observers as $observer) {
$observer->watch();
}
}
}
// Observerclass Cat implements Observer{
public function watch(){
echo "Cat watches TV<hr/>";
}
}
class Dog implements Observer{
public function watch(){
echo "Dog watches TV<hr/>";
}
}
class People implements Observer{
public function watch(){
echo "People watches TV<hr/>";
}
}
// Application example$action=new Action();
$action->register(new Cat());
$action->register(new People());
$action->register(new Dog());
$action->notify();
Running results:
Cat watches TV
--------------------------------------------------------------------------------
People watches TV
--------------------------------------------------------------------------------
Dog watches TV
--------------------------------------------------------------------------------
The so-called pattern is more of an idea, and there is no need to stick to code details at all. The observer pattern more reflects that two independent classes use interfaces to accomplish something that should be very complicated. If we do not use the topic class, we also need to continuously loop through the creation of instances and perform operations. Now you only need to create an instance, and you only need to call the notification method once to perform operations.
From the beginning of the singleton model, I have considered how to implement the code step by step. To the present, most of the implementation code has been introduced in one sentence, which is actually based on the continuous accumulation of the previous one. I really feel that constantly learning design patterns can greatly deepen my thinking on object-oriented programming. Of course, it is still unsatisfactory to talk on paper, so it is better to devote more practice~~·