The Observer model (Observer) perfectly separated the observer from the observed object. For example, the user interface can be used as an observer, the business data is observed, the user interface observes the changes in the business data, and when the data changes, it is displayed in the interface. One of the principles of object-oriented design is that each class in the system focuses on one function, not the other. An object does only one thing and does it well. The observer pattern defines clear boundaries between modules, increasing the maintainability and reusability of the application.
There are many ways to implement the observer pattern, which in essence must contain two roles: The Observer and the observed object. In just the example, the business data is the observed object, and the user interface is the Observer. There is a logical connection between the observer and the observed, and when the observer changes, the Observer observes the change and responds accordingly. If you use such an observation process between the user interface and the business data, you can ensure that the interface and data are in a different way, assuming that the requirements of the application change, you need to modify the performance of the interface, only need to rebuild a user interface, the business data need not be changed.
"Observation" is not "call directly"
When realizing the observer pattern, it should be noted that the interaction between the observer and the observed object can not be directly called between classes, otherwise it will cause the observer and the observed object to be tightly coupled and fundamentally violate the principle of object-oriented design. Neither the Observer "observes" the observer, or the observer notifies the observer of his change, should not be called directly.
Examples of implementing observer patterns
There are many forms of implementation of the observer pattern, the more intuitive one is the use of a "registration-notice-revocation registration" form. The following three graphs describe in detail such a process:
1: The Observer (OBSERVER) registers itself with the observed object (Subject), and the observed object stores the viewer in a container (Container).
2: The observed object has undergone some sort of change (as shown in the Askpricechanged), from which all registered observers are notified and the observer is informed of the change.
3: The observer tells the observed to revoke the observation, which is removed from the container by the Observer.
When the observer registers himself in the observer's container, the observer should not interfere with the specific type of observer, but should use the observer's interface. The advantage is that there are other observers in the program, so long as the observer is the same interface implementation. An observed person can correspond to multiple observers, and when the observed changes, he can notify all the observers of the message. interfaces, rather than concrete implementations, provide greater flexibility for the program.
The following code is an example of using C # to implement the Observer pattern:
//“观察者”接口
public interface IObserver {
void Notify(object anObject);
}
//“被观察对象”接口
public interface IObservable {
void Register(IObserver anObserver);
void UnRegister(IObserver anObserver);
}