Museum Magic Night! Museum Magic Night! Museum Magic Night!
Re-say three!!!
After the JVM saw the "Museum Night" movie, he decided to open a museum in his own home! After all, we need something new, and the museum will soon
It's open, and appoint you as curator (curator of gold?). ), and solemnly told you of his duties as a curator:
1. Accept the JVM's program.
2. Inform the Museum of the object to prepare the program.
As a proud OO programmer, how can you do such a thing with your own power? So you're going to recruit a subordinate, in the Java world, you know you just need new
A good one, but new needs a class before, it's okay, write one!
So you looked at the program, monkeys, rats, and rubber ducks, so, do it!.
class worker { private String Program_card; public void program_cardchanged () // This method is called when the program changes, so there's no need to call it. {string program_card =getprogram_card (); // Monkey.setprogram (Program_card) has been implemented; // mouse.setprogram (Program_card); Ruberduck.setprogram (Program_card);} // other methods .... }
The
Looks like this is a great subordinate, the first day of work done very good! Are you happy to do something else (LOL?) Two phone calls came in the next day.
The first one is the JVM, and he blames you: Why is Toy Soldier's program not on today?
The second one is Ruberduck, and it complains to you: I don't want to do the show today, why give me the program?
You angrily find your worker, scold it a meal! But it is also very wronged, and say to you:
"I have written according to you, Ah, wrong is also you wrong!" "
You realize that you may be wrong, but as a boss you won't admit it, and you decide to re-hire a new worker, before we look at
what the first worker has done wrong.
1. Not for interface/superclass programming, but for implementation programming, so that when performers change, the program_cardchanged () method must be modified to respond to
changes.
2. The changes are not encapsulated. Classes such as
3.monkey,mouse,ruberduck have Setprogram (String Program_card) methods, as if they can be unified into interfaces. The
is the time to introduce the protagonist today!
Observer mode: Defines a one-to-many dependency between objects, so that when an object changes state, all its dependents are notified and
automatically updated.
It is clear that, in the current environment, all the objects that want to perform the show will accept
notifications when the Program_card in the Worker object has changed.
Before we solve the above three problems, we first determine the dependency:
in the dependent object (the subject), declare a ArrayList, to store the dependent (Observer) instances, stored procedures we call the
Registration (register).
OK, we are officially starting OO design!
1. Design the Observer interface.
with the above analysis, we know what features the Observer needs: Register, unregister, and notify the Observer, then:
Public Interface Subject // subject/Observer {publicvoid registobserver (Observer o); // Register Public void // Unlock Registration Public void notifyobservers (); // Notification }
2. Design Observer interface
Only one method is required for the observer to invoke.
Public Interface Observer {publicvoid Setprogram (String program_card);
You let the newly hired workers achieve subject:
public class Worker implements Subject
{
Private arraylist<observer> observers;
Private String Program_card;
Public Worker ()
{
Observers = new arralisy<observer> ();
}
Public Registerobserver (Observer o)//registration is the process of placing objects in the ArrayList
{
Observers.add (o);
}
Public Removeobserver (Observer o)//The process of unlocking the registration
{
int I=observers.indexof (o);
if (i>=0)
{
Observers.remove (i);
}
}
public void Notifyobservers ()//Traverse list, notify Observer
{
for (int i=0;i<observer,size (); i++)
{
Observer O=observers.get (i);
O.setprogram (Program_card);
}
}
public void program_cardchanged ()
{
Notifyobservers (); When the program is updated, notify the viewer
}
}
Let the museum's actors achieve observer, for example, Ruberduck:
public class Ruberduck implements Observer
{
Private String Program_card;
Private Subject worker;
Public Ruberduck (Subject worker)
{
This.worker=worker;
Work.registerobserver ();
}
public void Setprogram (string program_card)
{
This.program_card=program_card;
}
Other methods omitted .....
}
Everything seems to be all fine.
But what exactly does the Observer pattern do for us?
Answer: Loose coupling
In the Observer pattern, the observer simply needs to know that the observer implements the observer interface and does not know what the observer itself is, so we can use the observer (i.e. multiplexing) independently.
Instead of tying the two together (tightly coupled), the observer is the same.
As an OO programmer, you must have found another problem! That is, since the String program_card! is loosely coupled, why does the observer know what type of data The observer needs?
In fact, the observer should not know the specific data type, in the Java built-in observer pattern, the data type passed is object, which is more in line with our loosely coupled settings.
In addition, we can refine our observer patterns from the built-in observer pattern in Java.
1.change. In our observer pattern, all observers are notified as soon as the data changes, but sometimes we don't need to be so "sensitive", so we can add a
Change the bit, and then notify the Observer when changing the bit =true. (Java built-in with the corresponding Setchange and Haschange methods).
2. Push and pull. Our observer is to pass the data in a push, while the pull is to let the observer provide a GET method to get the observer to get when notified, both of these methods have pros and cons,
Don't dwell on it. (Also, Java built-in is implemented)
Bo Master skill is still shallow, blog post if have improper place please reader Haihan.
Head Frist Design pattern Learning in the JVM of the Museum Magic Night (Viewer mode)