Design Pattern-Observer Pattern

Definition:

Defines the one-to-many relationship between objects. In this way, when an object changes, all dependent persons will receive notifications and update automatically.

Keywords:

Observer: Observer

Subject: topic

Concreteobserver: Specific observer

Structure:

Application scenarios:

This mode can be used when the state of an object changes and multiple other objects need to be notified to be synchronously updated. (if there is only one object that needs to be updated, it is unnecessary)

When you need to dynamically add and delete objects to be synchronized

Objects only need to notify other objects of their updates, and do not need to know the implementation details of other objects.

Advantages:

Subject and observer are highly cohesive and Low-coupling. They only contact each other through interfaces.

No need to specify a specific observer

Disadvantages:

Caused by loose couplingCodeIt seems that the relationship is not obvious, which is hard to understand.

Example:

Logging. When an event or a state change occurs, logs need to be recorded. database records and file records are required at the same time. How can this problem be written?

The general statement is:

 
Public ClassRecord {Public VoidNotify () {databaselog d =NewDatabaselog (); D. recordtodatabase (); filelog F =NewFilelog (); F. recordtofile ();}}Public ClassDatabaselog {Public VoidRecordtodatabase (){// Todo}}Public ClassFilelog {Public VoidRecordtofile (){// Todo}}
 

When there is a change, you only need to call

 
Record r =NewRecord (); R. Sort y ();
 

You can.

However, if you want to add a new record method, what should we do for Web records?

Add a weblog class and modify the record class.

 Public   Class Record { Public   Void Notify () {databaselog d = New Databaselog (); D. recordtodatabase (); filelog F = New Filelog (); F. recordtofile (); weblog W = New Weblog (); W. recordtoweb ();}} Public  Class Databaselog { Public   Void Recordtodatabase (){ // Todo }} Public   Class Filelog { Public   Void Recordtofile (){ // Todo }} Public   Class Weblog { Public   Void Recordtoweb (){// Todo }}

 
As a result, we found that, for actual programming, we need to add a new record class and modify the record class whenever there is a new one.
 

 
When you carefully observe the three record methods, you are actually recording what happened, but the record methods are different.
 

 
Class diagram:
 

 
Code:
 

 Public   Interface Isubject { Void Registerobserver (iobserver observer ); Void Removeobserver (iobserver observer ); Void Yyobservers ();} Public   Class Record: isubject { Private Arraylist observerslist; Public Record () {observerslist = New Arraylist ();} Public   Void Registerobserver (iobserver observer) {observerslist. Add (observer );} Public   Void Removeobserver (iobserver observer) {observerslist. Remove (observer );} Public   Void Yyobservers (){ Foreach (Iobserver observer In Observerslist) {observer. Record ();}} Public   Void Setevent ( Int El ){ If (El> 10) {policyobservers ();}}} Public   Interface Iobserver { Void Record ();} Public   Class Databaselog: iobserver { Private Isubject subject; Public Databaselog (isubject subject ){ This . Subject = subject; subject. registerobserver ( This );} Public   Void Record (){ // Todo }} Public   Class Filelog: iobserver { Private Isubject subject; Public Filelog (isubject subject ){ This . Subject = subject; subject. registerobserver (This );} Public   Void Record (){ // Todo }} Public   Class Weblog: iobserver { Private Isubject subject; Public Weblog (isubject subject ){ This . Subject = subject; subject. registerobserver ( This );} Public   Void Record (){ // Todo }}

 
Page call:
 

Protected VoidPage_load (ObjectSender, eventargs e) {record R =NewRecord (); databaselog DBL =NewDatabaselog (r); filelog FL =NewFilelog (r); weblog WL =NewWeblog (r); R. setevent (100 );}

To add other record methods, you need to add a class to implement iobserver, and then modify the client page.

Through the configuration file, we can also make the client easy to plug and remove.

 
<HR/>
 

 
From <simple introduction to design patterns>
 

 
Design principles involved:
 

 encapsulation changes 

 in observer mode, the status of the topic, the number and type of the observer (observer) are changed. 

 interface-Oriented Programming 

 both the observer and the topic use interfaces. The observer uses the topic interface and the observer interface to achieve loose coupling. 

 give priority to object combination instead of inheritance 

 The Observer mode uses a combination to talk about the combination of multiple observers into the topic. This relationship between objects is not inherited, but generated using dynamic combinations at runtime.