PrefaceLet's briefly talk about the definition and composition of the observer pattern.
The Observer pattern is set in relation to the compositionIn layman's terms, the Observer pattern defines a one-to-many dependency that allows multiple observer objects to simultaneously listen to a Subject object. When the subject object changes in state, notify all observer objects so that they can actively update themselves. The observer model is divided into four parts: abstract thematic roles, abstract observer roles, specific thematic roles, and specific observer roles.
Let's take a look at my custom observer mode.
Custom Observer ModeLet's start with the need: to implement a simple message subscription through the Observer model. Here's a concrete design abstraction: Think of the main part of the observer, which can be roughly abstracted into a few categories: Subject (subject), OBSERVER (Observer), Concreatesubject (Specific theme roles), Concreteobserver (specific observer role)
After abstracting these classes, you can draw the following class diagram:
Specific code implementations: Abstract roles:
Subject:
Public interface Subject {
/**
* Message Subscription
* @param Observer
*
/public void SUBSCRIBE (Observer observer) ;
/**
* Broadcast Message
*
/public void publish ();
/**
* Unsubscribe from a service
* @param Observer
*
/public VOID UNSUBSCRIBE (Observer observer);
/**
* Unsubscribe All services *
/public void unsubscribeallservers ();
}
Abstractsubject:
Public abstract class Abstractsubject implements Subject {
//Observer List
private list<observer> observers;
Public Abstractsubject () {
this.observers = Lists.newarraylist ();
}
public void Subscribe (Observer Observer) {
if (null = = Observer) {return
;
}
OBSERVERS.ADD (Observer);
}
public void Publish () {to
(Observer observer:observers) {
observer.update (this);
}
}
public void Unsubscribe (Observer Observer) {
System.out.println ("unsubscribe...\n");
OBSERVERS.REMOVE (Observer);
}
public void Unsubscribeallservers () {
observers.clear ();
}
}
Observer:
Public interface Observer {public
void update (Subject Subject);
}
Specific roles:
Concreatesubject:
public class Concreatesubject extends Abstractsubject {
//message state
private int status;
Message subject
private String subject;
Public Concreatesubject (String subject) {
super ();
Status = Status.NOT_SEND.getStatus ();
This.subject = subject;
}
Message state change public
void changed (int newstatus) {
this.status = newstatus;
Publish ();
}
Public String Getsubject () {return
subject;
}
public int GetStatus () {return
status;
}
}
Concreateobserver:
public class Concreateobserver implements Observer {
//Observer name
private String name;
Subscribe to the theme
private Subject Subject;
Public Concreateobserver (String name, Subject Subject) {
this.name = name;
This.subject = subject;
Subject.subscribe (this);
}
It is generally only possible to change the name of the notice, but when there is a business operation it is recommended to use update public
void Update (Subject Subject) {
concreatesubject Concreatesubject = (concreatesubject) subject;
System.out.println ("observername =" + THIS.name + "\ n" + concreatesubject.getsubject () + changed ... "+" \ n "+" status = "+ Status.getstatus (Concreatesubject.getstatus ()). Getstatusname () +" \ n ")
;
@Override public
String toString () {return
"concreateobserver{" +
"name= '" + name + ' \ ' +
", Subjec T= "+ subject +
'} ';
}
}
Finally look at the specific call:
Client:
public class Client {public
static void Main (String args[]) {
//define a theme
concreatesubject subject = new Concrea Tesubject ("Com.sankuai.sendMessage");
Definition two observer
concreateobserver sendobserver = new Concreateobserver ("Send_message", subject);
Concreateobserver resendmessage = new Concreateobserver ("Re_send_message", subject);
Change message status
subject.changed (Status.SEND.status);
}
PostScriptThe following points must be noted when designing the Observer model:
The first thing to be clear is who is the observer and who is the observer, as long as it is clear who is the object of concern, the problem is that there is a one-to-many relationship between the general observer and the observed, and an observer can have multiple observers, for example, an edit box, an observer with a mouse click, an observer with content changes, and so on. When an observer sends a broadcast notification, it is not necessary to specify a specific observer,observer to decide whether to subscribe to the subject's notice; The observed must have at least three methods: Add the listener, remove the listener, notify the observer; The Observer has at least one method: Update, Update the current content and make the deal; Finally, the application scenario of the pattern: a. Updating the state of an object requires that other objects synchronize updates, or that an object's update needs to rely on another object update; B. Objects need to notify their own updates to other objects only, without having to know the details of other objects, such as message push.
push model and pull model:
The observer model can be divided into the push model and the pull model according to its emphasis function.
Push MODEL: The observer pushes the subject-related information to the observer, regardless of whether the observer needs it or not, the information in the viewer object is passed to the observer via update (object obj) in the general implementation of the model.
Pull Model: when the Observer notifies the observer, it only needs to pass a small amount of information. If the observer needs more specific information, the Observer takes the initiative to obtain it from the observed object, which is equivalent to drawing data from the observer to the object of the Observer. In general, the view of this model is that the object itself is passed through the Update method to the Observer update (Subject Subject), so that it can be obtained by this reference when the observer needs to obtain the data.
The model of the Observer is also supported in the JDK, and the specific source analysis will be given in subsequent posting.