View the design mode from the Java class library (1)

In many cases, experience is crucial for a design (software, building, or industrial. Good experiences give us guidance and save our time. Bad experiences give us reference to reduce the risk of failure. However, in terms of knowledge, experience only exists in the personal brain as a kind of accumulation of work and is difficult to be transferred or recorded. To solve this problem, people have proposed the so-called model concept. The so-called Mode refers to the repeated problem solutions under a specific background. The mode is experience-based documentation.

The concept of software pattern is now widely used, involving analysis, design, architecture, coding, testing, refactoring, and other parts of the software construction life cycle. Here we mainly discuss the design pattern, which refers to the solutions to some repeated problems in the software design process. However, when we mention the design pattern, it generally refers to the 23 patterns in the Design Pattern -- elements of reusable object-oriented software, a classic gof book. Therefore, it is specific to the object-oriented software design process.

Globally, the pattern represents a language, a documented experience, or even a culture. There are often many problems that are difficult to describe or are complicated to describe. Speaking in a pattern language will make the listener feel enlightened. Of course, both parties must be able to grasp the meaning of the Model language. However, this is not an easy task. Patterns are often different in understanding. This article aims to explain the design patterns from a specific application perspective: Java class libraries. Combined with specific examples, we hope to deepen our understanding of the design model.

The Java class library mentioned here is not limited to JDK itself, but also some examples of other class libraries, such as JAXP (of course, the next JDK version will also contain JAXP ). In fact, the concept of design patterns is now so widely used. No matter what kind of design, as long as a slightly larger design, many traces of design patterns can be found, or it is inevitable to use the design pattern. Most of the design patterns described below are the 23 patterns that have appeared in the gof classic. However, some, such as MVC, do not belong to them. Generally speaking, we think that the 23 gof models are intermediate ones, and some lower-layer models can be abstracted below them, you can also combine them to obtain some advanced modes. Of course, the differences between low, medium, and high levels are similar to the differences between different languages. They are only differences at the application layer.

Observer Mode

The function of the observer mode is to expect two or more objects, called subject and observer. When the status of one party changes, the other party will be notified. That is to say, as the observer side, it can monitor a specific state change of the subject and respond to it. A simple example is: when the data in a user view is changed by the user, the backend database can be updated, and when the database is updated in other ways, the data display in the user view also changes.

Figure 1: class diagram of the obverser Mode
 

In JDK, there is actually a simple implementation of the observer mode: Class java. util. observerable and interface java. util. Observer. The Java. util. observerable class corresponds to subject, while Java. util. Observer is the observer. In JDK, these two parts are not designed as interfaces. Instead, java. util. observerable provides partial implementation, which simplifies many programming tasks. Of course, this also reduces some flexibility.

The following lists the functions of observer and observeral and their simple functions.

java.util.Observer：
public void update(Observable obs, Object obj)
Java. util. the observer interface is very simple. Only this method is defined. In a narrow sense, according to the observer mode, observer should call the getxxx () method of subject in this method to obtain the latest status, in fact, you can only respond to certain subject events. This is a prototype of the proxy event model in Java-responding to events. However, in the Observer mode, the event is specified as a State/data change.

Java. util. observable

Public void addobserver (Observer obs)

Register an observer with subject. That is to say, add the observer object to the internal list of Java. util. observable. In JDK, this list is simply implemented through a java. util. vector class, but in fact, in some complicated observer mode applications, we need to place this part separately to form a manager class to manage mappings between subject and observer. In this way, the subject and observer are further decoupled, and the program will be more flexible.

Public void deleteobserver (Observer obs)
Delete a reference with registered observer from subject.

Public void deleteobservers ()
Delete all registered observer references from subjec.

Public int countobservers ()
Returns the number of observers registered in subject.

Protected void setchanged ()
Set an internal flag to indicate that the ovserver status has changed. Note that this is a protected method, that is, it can only be called in the Observer class and its subclass, but not in other classes.

Protected void clearchanged ()
Clear the internal identifier of the file. It is automatically called within the yyobservers () method to indicate that the status change of the subject has been passed to the ovserver.

Public Boolean haschanged ()
Determine whether the status of the subject has changed.

Public void policyobservers (Object OBJ)
It first checks the internal flag to determine whether the status has changed. If yes, it calls the update () method of each observer registered in the subject. In JDK, this method is implemented internally as synchronized, that is, if multiple threads compete for a java. util. if the observerable policyobservers () method is used, they must be executed in the order of scheduling. In some special circumstances, there may be some potential problems: during the waiting process, a newly added observer will be missed and not notified, A deleted observer still receives a notification that it does not want.

Public void policyobservers ()
It is equivalent to calling policyobservers (null ).

Therefore, it is easy to apply the observer in Java. It is necessary to make the subject object to be observed inherit Java. util. observerable, let the object to be observed implement Java. util. observer interface, and then use Java. util. the observerable addobserver (Observer OBJ) method registers the observer to the subject object. This has completed most of the work. Then, the observer mode mechanism can be implemented by calling methods such as notifyobservers (Object Arg) of Java. util. observerable. Let's take a simple example of using this mode. In this example, there are three classes: framesubject, datesubject, frameobject, and entryclass. In framesubject, users can set the observed values, which are automatically displayed in frameobject, datesubject encapsulates the observed value and acts as the subject in the Observer mode.

Public class framesubject extends jframe {
..............
// Because multi-inheritance cannot be used, you can only use object combination to introduce one
// Java. util. observerable object.
Datesubject subject = new datesubject ();
// This method adds an observer message to datesubject.
Public void registerobserver (Java. util. Observer O ){
Subject. addobserver (O );
}
// Data changes. When an event is triggered, notifyobservers () is called to notify the observer.
Void jbutton?action=med (actionevent e ){
Subject. setwidthinfo (integer. parseint (jtextfield1.gettext ()));
Subject. setheightinfo (integer. parseint (jtextfield2.gettext ()));
Subject. policyobservers ();
}
...............
}
Public class datesubject extends observable {
// Encapsulate the observed data
Private int widthinfo;
Private int heightinfo;
Public int getwidthinfo (){
Return widthinfo;
}
Public void setwidthinfo (INT widthinfo ){
This. widthinfo = widthinfo;
// After the data changes, setchanged () must be called; otherwise, the yyobservers () method does not work.
This. setchanged ();
}
Public void setheightinfo (INT heightinfo ){
This. heightinfo = heightinfo;
This. setchanged ();
}
Public int getheightinfo (){
Return heightinfo;
}
}
Public class frameobserver extends jframe implements java. util. Observer {
..............
// Observed data
Int widthinfo = 0;
Int heightinfo = 0;
// Update data and other necessary responses in the update () method.
Public void Update (observable o, object Arg ){
Datesubject subject = (datesubject) O;
Widthinfo = subject. getwidthinfo ();
Heightinfo = subject. getheightinfo ();
Jlabel1.settext ("The heightinfo from subject is :");
Jlabel3.settext (string. valueof (heightinfo ));
Jlabel2.settext ("The widthinfo from subject is :");
Jlabel4.settext (string. valueof (widthinfo ));
}
................
}
Public class entryclass {
Public static void main (string [] ARGs ){
.................
Framesubject frame = new framesubject ();
Frameobserver frame2 = new frameobserver ();
// Register the observer in the subject and associate the two.
Frame. registerobserver (frame2 );
..............
Frame. setvisible (true );
Frame2.setvisible (true );
.................
}
}

I think the implementation of this observer mode in JDK is very sufficient for general observer mode applications. However, on the one hand, it uses a class to implement subject, and on the other hand, it uses vector to save subject references to observer, which simplifies the programming process, but it will limit its application in some scenarios that require more flexibility and complex design. Sometimes (although this is not the case ), we have to rewrite the new subject object and additional manager object to implement more complex observer mode applications.

Summary:

This part mainly discusses the concept of pattern. With the continuous development of the modern software industry, the scale of software systems is expanding, and it is increasingly necessary to model some emerging problems, reduce the Risk of software development failure with successful experiences or lessons learned. The pattern represents a documented experience that provides the best (or good) solution to a certain type of problem, even if it is not an experienced software engineer, you can also build a relatively successful system based on the mode. This section provides an example of the obverser mode to better illustrate this point. The obverser mode mainly solves the problem of State ing between objects or mirroring.

References

• Software patterns: James O. coplien, Bell Laboratories, the hillside Group

• Design Model: Reusable Basic Machinery Industry Press for Object-Oriented Software
• Java2 class library supplemental version Machinery Industry Press
• Visual Object-Oriented Modeling Technology Beijing University of Aeronautics and Astronautics Press
• Jdk1.3 source code
• UML User Guide Mechanical Industry Press

About the author

		Liu Wudong: 2001 graduate student at the School of Computer Science, Wuhan University. Research Direction: Reusable Component technology and design pattern.