Discovery of design patterns in the net framework class library we use (2)

 

Observer Mode

 

Observer: The Observer, which requires the target object to receive notifications when detecting changes and call an update method.

Subejct: the target, that is, each observer can be notified when changes are detected.

 

A good OO design emphasizes both encapsulation and loose coupling. In other words, classes should encapsulate private details as much as possible and minimize the strong dependency between classes. In most applications, classes are not isolated, and they often interact with each other and affect each other. There is a common scenario of class-Class Interaction: when an object (subject) changes, another object (Observer) requires that this (subject changed) notification be received. For example, several form controls can be changed after a button is clicked. A simple solution is to directly call a specific method of the Observer when the status of the Subject object changes. This method will introduce the handler to solve the problem:

Subject needs to know which method the Observer will be called. This will cause the Subject to be tightly coupled with a specific Observer. In addition, if you need to add several other observers, you have to add code to call every Observer method in the Subject. If the number of observers changes dynamically, this will be more complicated and you will fall into this unmaintainable chaos.

An effective solution is to use the observer mode. In this way, you can decouple the Subject from its Observer so that you can easily add and delete any number of observers at design time and runtime. The Subject maintains an Observer list. When the status of the Subject changes, it can notify all the observers in the list in sequence. See the following sample code:

Public abstract class CanonicalSubjectBase

{

Private ArrayList _ observers = new ArrayList ();

Public void Add (ICanonicalObserver o)

{

_ Observers. Add (o );

}

Public void Remove (ICanonicalObserver o)

{

_ Observers. Remove (o );

}

Public void Policy ()

{

Foreach (ICanonicalObserver o in _ observers)

{

O. Policy ();

}

}

}

Public interface ICanonicalObserver

{

Void y ();

}

All classes that assume the Observer role implement the ICanonicalObserver interface, and all Subject must inherit from CanonicalSubjectBase. If a new Observer wants to monitor the Object, you only need to add this Observer method without changing any line of code in the Subject! In addition, you will find that the Object no longer directly depends on those observers (because the method at the beginning is that the Object must call a method of each Observer, the Translator's note), but only depends on the ICanonicalObserver interface.

Although the Observer mode of the Gang of Four can solve some problems, this method still has some defects, because Subejct must inherit from CanonicalSubjectBase, and all observers must implement the ICanonicalObserver interface. (That is to say, in one sense, tight coupling is transferred to another sense.) Let's look back at the example of the form button control, the solution is shown in front of us: NET Framework uses delegation and events to solve this problem! If you were in ASP. if you have written programs in NET and WinForm, you may have used delegation and events. The event is Subejct, and the delegate is Observer, let's take a look at the example of the observer Mode Implemented by using events:

Public delegate void Event1Hander ();

Public delegate void Event2Handler (int );

Public class Subject

{

Public Subject (){}

Public Event1Hander Event1;

Public Event2Handler Event2;

Public void RaiseEvent1 ()

{

Event1Handler ev = Event1;

If (ev! = Null) ev ();

}

Public void RaiseEvent2 ()

{

Event2Handler ev = Event2;

If (ev! = Null) ev (6 );

}

}

Public class Observer1

{Public Observer1 (Subject s)

{

S. Event1 + = new Event1Hander (HandleEvent1 );

S. Event2 + = new Event2Handler (HandleEvent2 );

}

Public void HandleEvent1 ()

{

Console. WriteLine ("Observer 1-Event 1 ");

}

Public void HandleEvent2 (int)

{

Console. WriteLine ("Observer 1-Event 2 ");

}

}

The form button control exposes a click event that can be notified to the Observer when the button is clicked. Any Observer that needs to respond to the event only needs to register a delegate (new Event1Hander (method) to the event) it is a delegate. Registering a delegate is + = giving Event1 event, the Translator's note ). The form button control does not depend on any potential Observer. Every Observer only needs to know the delegate signature format of this event and is OK (in this instance, the delegate is EventHandler ), because EventHandler is a delegate type rather than an interface, each Observer does not need to implement an extra interface. If an Observer already has a method that complies with the delegate signature format, then it just needs to register this method to the Subject event. By using delegation and events, the Observer mode can decouple the Subject from the Observer (that is, the Subject does not need to explicitly call a method of the Observer )!

 

From people who take hobbies as their work