Today I’m going to show you a simpler model, the observer model. If you think MY writing is good, keep in mind that I have the courage to introduce these design patterns in simple language.

Why use observer mode?

Take a simple example, in an engineering school (as we all know, there are fewer female students in engineering schools), there is a well-bred, beautiful and gentle girl whom everyone likes very much. Naturally, there are many people chasing after her. Everyone pays close attention to what a girl does. Like when a girl posts “I’m hungry” in the middle of the night.

.

Next, can not, the men (suppose now there are A,B,C three boys at the same time like to change the girl) anxious, all want to use their own way to let the girl to fill the stomach (A: go, take you to eat KFC. B: Don’t move. I’ll bring them downstairs for you. C: Draw your own pie and have a look. Of course, in C’s way, there is no way, cough, digression. So how do you represent it in pseudocode?

// It is the bounden duty of every Boy to take care of the people around him. } class BoyA extends Boy{pulbic void careDarling(){system.out.println (" gO, take you to KFC"); }} class BoyB extends Boy{pulbic void careDarling(){system.out.println (" don't move, I'm going to buy it for you ");}} class BoyB extends Boy{pulbic void careDarling(){system.out. }} class BoyC extends Boy{pulbic void careDarling(){system.out.println (" draw a pie, look at it "); }} public void hungrey(){boya.caredarling (); BoyB.careDarling(); BoyC.careDarling(); }}Copy the code

Of course, we respect the way everyone loves someone. Now, instead of focusing on this, what’s wrong with the representation of the pseudocode?

Just below, there are a few problems:

  1. As a girl, first I need to know who likes me, otherwise what if I call the wrong person? (The truth is, even though you know someone likes you, do you know who it is?)
  2. Someone else likes a girl, wants to take care of her. But do not want to let the girl know, just want to pay silently. The way we write it now, only girls who know who likes them will be notified, not those who don’t.
  3. other

What are the benefits of using observer mode

Looking at the way we wrote above, we found that this way of writing is not appropriate. Do we have a solution? The answer, of course, is yes. But first we should know our own needs.

  1. As long as I take the initiative to pay attention to the girl on the line, do not wait for notice, their own initiative, after all, happiness depends on their own fight.
  2. Girls are attractive and we should allow others to like them too (not just A,B,C). After all, everyone has the right to love and be loved.

So, observer mode comes to the rescue.




Observer pattern structure

(For the record, I will study UML in my free time. This drawing is not standard enough, I hope to illustrate.

So what’s the relationship between this and our example?




The new structure

So why don’t we do it in code?

Observer

public interface Observer {

public void update();
}Copy the code

Boy

public abstract class Boy {

public abstract void careDarling();
}Copy the code

BoyA

public class BoyA extends Boy implements Observer { private Subject subject; public BoyA(Subject subject){ subject.addObserver(this); } @Override public void update() { careDarling(); } @override public void careDarling() {system.out.println (); }}Copy the code

BoyB

public class BoyB extends Boy implements Observer { private Subject subject; public BoyB(Subject subject){ subject.addObserver(this); } @Override public void update() { careDarling(); } @override public void careDarling() {system.out.println (); }}Copy the code

BoyC

public class BoyC extends Boy implements Observer { private Subject subject; public BoyC(Subject subject){ subject.addObserver(this); } @Override public void update() { careDarling(); } @override public void careDarling() {system.out.println (); }}Copy the code

Subject

public interface Subject {

public void addObserver(Observer boy);
public void removeObserver(Observer boy);
public void notifyObservers();    
}


Copy the code

Girl

public class Girl implements Subject { private List boys; public Girl(){ boys = new ArrayList(); } @Override public void addObserver(Observer boy) { boys.add(boy); } @Override public void removeObserver(Observer boy) { boys.remove(boy); } @Override public void notifyObservers() { for(int i=0; iCopy the code

The test class ObserverTest

Public class ObserverTest {public static void main(String[] args) {Girl Girl = new Girl(); // A BoyA BoyA = new BoyA(girl); B BoyB BoyB = new BoyB(girl); // C BoyC BoyC = new BoyC(girl); Girl.hungrey (); }}Copy the code

Results:




result

Well, that's it for the observer model. Going back to our two questions from the beginning, does our current model solve the problem?

  1. As a girl, first I need to know who likes me, otherwise what if I call the wrong person? (The truth is, even though you know someone likes you, do you know who it is?)

We now maintain an array or queue in Girl (Subject implementation class) to hold the observer. You don't need to know who the observer is. We initialized the queue when we created the Girl (in other words, I knew someone liked me, but I didn't need to know who).

  1. Someone else likes a girl, wants to take care of her. But do not want to let the girl know, just want to pay silently. The way we write it now, only girls who know who likes them will be notified, not those who don't.

Now even when BoyC and BoyD appear, they secretly watch the girl when they are created. When the girl is hungry, they can notify all without changing the original code. (How nice, the way we do it. After all, secret love is nice.

In practice, however, the Subject carries some data when it notifies the Observer, which makes it necessary to mention the two modes of Observer mode: push mode and pull mode.

As the name implies, I don't care what you Observer want, you receive what I give you. This pattern is used when the requirements are simple and the Subject and Observer classes agree on the type of data to be returned. The drawback of course is also obvious is that many observers mouth difficult to adjust, I do not know what you want, we return the same. You can think of it as a wayward girl, you have to take what I give you and you have to take what I don't give you.

Write all words a bit large, so only post part of the code:

public interface Subject {
public void addObserver(Observer boy);
public void removeObserver(Observer boy);
public void notifyObservers(int state)；
}


Copy the code

As you can see, here we pass out state as a parameter and then passively receive it in the Observer.

public interface Observer { public void update(int state); // For example, this time we can go to BoyA, BoyB... In the specific state to make corresponding actions. For instance hungry how, sleepy how...... }Copy the code

Pull model: The Observer stands up and gives whatever he wants. Usually we pass the theme class object as a parameter, and then the observer can use reflection to get what they want. The problem of pushing the model is solved, and everyone (many observers) can take what they want. It's understandable that after paying so much, you get the girl and give yourself to you.

public interface Subject {
public void addObserver(Observer boy);
public void removeObserver(Observer boy);
public void notifyObservers(Subject subject)；
}


Copy the code

Girl

. @Override public void notifyObservers(Subject subject) { for(int i=0; iCopy the code

Observer

public interface Observer { public void update(Subject subject); // Everyone has got it, want to know what is difficult? }Copy the code

Ok, this is the observer mode, you can discuss with me if you have any questions. Of course, errors in the text are unavoidable, and I sincerely request criticism and correction.