Recently, the project plan is very tight, and the stock market is very hot, so many people are secretly watching the market through the website. The boss market will go out to do errands. If the boss comes back, ask the front desk secretary to call in, and everyone will take their places immediately, so that the boss will not find the problem.
One, two-way coupling code
code for what happened in between
Having the whole thing covered, the problem now is that this 'foreground' class and this 'stock watcher' class are coupled to each other. The foreground class needs to add an observer, and the observer class needs the status of the foreground.
If any of the observers want to watch the NBA webcast, the 'frontend' class code needs to be modified.
The first is the open-closed principle. Modifying the original code means that the design is not good enough. The second is the principle of dependency inversion. We should make all programs depend on abstractions, not on each other.
If any of the observers want to watch the NBA webcast, the 'frontend' class code needs to be modified.
The first is the open-closed principle. Modifying the original code means that the design is not good enough. The second is the principle of dependency inversion. We should make all programs depend on abstractions, not on each other.
2. Decoupling practice 1
Here let two observers inherit the 'abstract observer', and rewrite the method of 'Update (update)'
In the preparation of the front desk secretary class, all the places that are coupled with specific observers are changed to 'abstract observers'
The client code is the same as before
in the concrete observer, which is coupled to the concrete class. 'Front Secretary' is a concrete class and should also be abstracted. When the boss came back, it was too late for the front desk to call, so everything that informed everyone became the boss.
In fact, whether the boss or the front desk is a specific notifier, the observer here should not rely on the specific implementation, but an abstract notifier.
If a colleague has a conflict with the front desk, so the colleague is no longer notified, at this time, she should delete this object from the list of observers she added.
in the concrete observer, which is coupled to the concrete class. 'Front Secretary' is a concrete class and should also be abstracted. When the boss came back, it was too late for the front desk to call, so everything that informed everyone became the boss.
In fact, whether the boss or the front desk is a specific notifier, the observer here should not rely on the specific implementation, but an abstract notifier.
If a colleague has a conflict with the front desk, so the colleague is no longer notified, at this time, she should delete this object from the list of observers she added.
3. Decoupling practice 2
Added abstract notification interface
The specific notifier may be the foreground or the boss. They may have their own methods, but for the notifier, they are the same, so they all implement this interface.
The front desk secretary class is similar to the boss class. For specific observers, what needs to be changed is to change the 'front-end' coupling to abstract notifiers.
Because 'Wei Guanqi' was canceled the registration and was not notified, the end was miserable. Now the two are not coupled.
The structure diagram is as follows:
Fourth, the observer mode
Observer mode is also known as publish-subscribe (Publish/Subscribe) mode
The observer mode defines a one-to-many dependency, allowing multiple observer objects to monitor a subject object at the same time. This subject object notifies all observer objects when their state changes, enabling them to update themselves automatically.
The Subjec class, which can be translated into a subject or an abstract notifier, is generally implemented with an abstract class or an interface. It keeps all references to observer objects in an aggregate, and each subject can have any number of observers. Abstract topics provide an interface to add and remove observer objects.
Observer class, abstract observer, defines an interface for all concrete observers, and updates itself when notified by the subject. This interface is called the update interface. The observer is generally implemented with an abstract class or an interface. The update interface usually contains an Update() method, which is called the update method.
The ConcreteSubject class, called a specific subject or a specific notifier, stores the relevant state in a specific observer object; when the internal state of the specific subject changes, it sends a notification to all registered observers. Concrete subject roles are usually implemented with a concrete subclass.
Characteristics of the Observer Pattern:
Dividing a system into a series of cooperating classes has a bad side effect of maintaining consistency between related objects. We don't want to make all kinds of tight coupling in order to maintain consistency, which will bring inconvenience to maintenance, expansion and reuse.
Dividing a system into a series of cooperating classes has a bad side effect of maintaining consistency between related objects. We don't want to make all kinds of tight coupling in order to maintain consistency, which will bring inconvenience to maintenance, expansion and reuse.
The Observer pattern should be considered when a change to one object requires changing other objects at the same time, and it does not know how many objects need to be changed.
When an abstract model has two aspects, one of which depends on the other, the observer pattern can be used to encapsulate the two in separate objects so that they can be changed and reused independently.
When an abstract model has two aspects, one of which depends on the other, the observer pattern can be used to encapsulate the two in separate objects so that they can be changed and reused independently.
What the Observer pattern does is actually decoupling. Let both sides of the coupling depend on the abstract, not on the concrete. So that each change will not affect the changes on the other side.
This is actually the best embodiment of the Dependency Inversion Principle.
This is actually the best embodiment of the Dependency Inversion Principle.
When abstracting observers, you are using abstract classes in your code, why not interfaces?
Because the two specific observers, the stock observer and the NBA observer, are similar, so an abstract class is used, so that some code can be shared, and the interface is only the implementation of the method, and it does not make much sense.
Because the two specific observers, the stock observer and the NBA observer, are similar, so an abstract class is used, so that some code can be shared, and the interface is only the implementation of the method, and it does not make much sense.
So can abstract observers be defined with interfaces?
In real programming, it is entirely possible that the specific observers are unrelated classes, but they all need to perform the Update() operation according to the notification of the notifier, so let them all implement the following interface. realize this idea.
In real programming, it is entirely possible that the specific observers are unrelated classes, but they all need to perform the Update() operation according to the notification of the notifier, so let them all implement the following interface. realize this idea.
These controls are either .NET class libraries or controls written by others in advance. How can they implement the Observer interface with Update?
Disadvantages of Observer Pattern:
When opening VS2015, after running the program, in addition to popping up a console program window, the toolbar has changed, the toolbox has disappeared, and the 'error list' programmed 'automatic window' and 'command window' are opened. There are so many changes that happen just by clicking a "Run" button, each involving a different control.
There is no way for every control to implement an 'Observer' interface, because these controls are already encapsulated by their manufacturers.
Although when the "Run" button is clicked, the related controls are indeed notified of changes, but it is impossible for them to implement the observer pattern by means of an interface.
It's still the same problem as just said, although the principle of dependency inversion has been used, the 'abstract notifier' still depends on the 'abstract observer', that is to say, if there is no such interface as the abstract observer, I will notify function is not complete.
The other is each specific observer, it is not necessarily the 'update' method to be called. As I said just now, I hope that the 'toolbox' is hidden and the 'automatic window' is opened, which is not the same name at all Methods. This should be where it falls short.
If the notifier and the observer don't know each other at all, and it's up to the client to decide who to notify, that's fine.
There is no way for every control to implement an 'Observer' interface, because these controls are already encapsulated by their manufacturers.
Although when the "Run" button is clicked, the related controls are indeed notified of changes, but it is impossible for them to implement the observer pattern by means of an interface.
It's still the same problem as just said, although the principle of dependency inversion has been used, the 'abstract notifier' still depends on the 'abstract observer', that is to say, if there is no such interface as the abstract observer, I will notify function is not complete.
The other is each specific observer, it is not necessarily the 'update' method to be called. As I said just now, I hope that the 'toolbox' is hidden and the 'automatic window' is opened, which is not the same name at all Methods. This should be where it falls short.
If the notifier and the observer don't know each other at all, and it's up to the client to decide who to notify, that's fine.
Event delegation implementation:
"Stock Watcher" class and "NBA Watcher" class, the parent class "abstract observation class" is removed, so add some code, and change the "update" method name to their appropriate method name .
This is the case in reality, and the method names are not necessarily the same.
"Abstract Notifier" does not want to rely on "Abstract Observer", so the "Increase" and "Decrease" methods are unnecessary (abstract observer no longer exists)
Here's how to deal with the 'boss' class and the 'foreground' class. Declare a delegate named "EventHandler" with no parameters and no return value.
A delegate is a type of reference method. Once a delegate is assigned a method, the delegate will behave exactly the same as the method. Delegate methods can be used like any other method, with parameters and return values.
A delegate can be seen as an abstraction of a function, a 'class' of a function, and an instance of the delegate will represent a concrete function.
That is, 'delegate void EventHandler();' can be understood as declaring a special class, and 'public event EventHandler Update;' can be understood as declaring an event delegate variable called 'update'.
The delegated instance will represent a specific function, which means that 'new EventHandler(tongshi1.CloseStock Market)' is actually a delegated instance, and it is equivalent to delegating the method 'tongshi1.CloseStockMarket' to 'huhansan.Update' this method
Once a delegate has a method assigned, the delegate will behave exactly the same as the method.
A delegate can carry multiple methods, all of which are invoked in turn.
You can make the methods carried by the delegate object do not need to belong to the same class.
This makes the collection of abstract observers that are added and subtracted in the 'boss' class and the abstract observers that are traversed at notification unnecessary. Go to the client and let the delegate carry multiple methods, which solves the problem of coupling with abstract observers.
But delegation is also based on the premise that all methods carried by the delegate object must have the same prototype and form, that is, have the same parameter list and return value type.
Note that the observer pattern came first, followed by the delegated event technique, each of which has its own advantages and disadvantages.