Application of state mode in client software

Http://35java.com/zhibo/forum.php? MoD = viewthread & tid = 109 & extra = Page % 3d3

Introduction
In the hierarchical software architecture, the serverProgramFocus on implementing business logic, and the client program contains the user interface. The server program is called by the client program, and its request and response modes have been determined during the design. The probability of problems occurring during the running is small. On the contrary, client programs interact directly with users. Although there are correct operation orders or modes, user operations are unpredictable, the program must handle various operation errors and add data input validation requirements to increase the development cost of the client program.
Therefore, once there is a user interaction GUI that has been fully tested or even accepted, the GUI should be reused as much as possible to improve the reliability and maintainability of the software.
In the process of restructuring a J2EE project and adding new functions, we use the state mode for the Client GUI program. The results show that the use of this mode not only reduces the Client GUI program size (LOC), but also greatly reduces the development and unit test time, the number of defects found in the integration test is three times less on average than the number of defects before using this mode. This article describes how to use the State mode in this project.

1. State Mode
First, we will briefly introduce the state mode.
This mode changes the behavior of an object when its internal state changes ]. Its structure 1 is shown in.

Figure 1 State mode structure

The responsibilities of each participant in the mode are described as follows:

• Context: a user object that has a State member to identify the current state of the object;
• State: interface or base class, which encapsulates behaviors related to the specific state of context;
• Concretestate: an interface implementation class or subclass that implements a behavior related to a certain state of context.

During running, context delegates state-related requests to the current concretestate object for processing. For more information about the state mode, see References 1.

2. Client Applications
The goal of this mode is to separate the variation part and the unchanged part of the client software so that the changed part can be independent of the unchanged part, which is conducive to the expansion of new functions and maintenance.
There are two ways to reuse the Client GUI in the project.

• Method 1 is applicable to the same data set and different operation modes. In this case, the client data processing and verification logic is defined in the GUI. Different State objects encapsulate different operation modes;
• Method 2 is applicable to different data sets in the same operation mode. In this case, the client data processing and verification logic is defined in the State object. Different State objects encapsulate different data set operations.

2.1 Type 1: Read-Only & Normal
2.1.1 motivation
The Client GUI accepts user input, verifies the data validity, and then transmits the data to the server. The server checks the Service Logic validity and saves the data; however, in certain circumstances (for example, data already exists and can only be input once), the data is read-only according to the status of the data operated by the Client GUI, that is, the client can only display data and cannot change the data on the server.
Generally, a logic judgment statement is added to the GUI program to determine whether the data should be read-only. If there are multiple client guis (Views) for the same data set (model), you need to add this judgment to each program. This reduces the maintainability of the program and determines whether the data is read-only. Such a business logic will be distributed in multiple places in the program, which is not easy to maintain and may cause inconsistency when the business logic changes.
We can extract the changed parts (different parts in the normal and read-only States) from the GUI and represent them with different classes, when the status of the GUI changes, you only need to change its reference to the status object, and State-related operations are delegated to the status object to complete.
2.1.2 Applicability
Applicable environment of this type: the same data set, different operation modes. That is, the response mode of a specific GUI is changed according to the operation context. Based on whether the data is editable, there are two States: Read-Only state and normal state.
2.1.3 structure (figure 2)

Figure 2 same data set and different operation modes

2.1.4 participants

• Clientstatechangeable: The operation interface provided by the Client GUI to the State object so that the State object can access members of the GUI to complete state-related operations;
  • Getchangeablecomponents (): return the control collection that cannot be edited when the status is converted to read-only;
  • Savechangetoserver (): saves client data to the server when it is editable.

• Aclientgui: completes the Context Function in Figure 1, that is, the Client GUI whose status needs to be changed; maintains an instance of clientstate (State );
  • Init (): uses this reference as a parameter and calls state. setcomponents (this) to set the initial state of the variable control;
  • Okbuttonactionreceivmed (E: actionevent): After the user completes the operation, this method can be used as the actionlistener method of the "OK" button control and call state. Action (this) to complete this operation.

• Clientstate: State interface, which encapsulates behaviors related to a specific State of the Client GUI;
  • Setcomponents (GUI: clientstatechangeable): sets the control status of the Client GUI specified by the GUI parameter;
  • Action (GUI: clientstatechangeable): saves data.

• Clientnormalstate: You can edit the State subclass to implement the clientstate interface;
  • Setcomponents (GUI: clientstatechangeable): Call getchangeablecomponents () of the Client GUI specified by the GUI parameter to obtain the control collection, and traverse and set the status of each control to editable;
  • Action (GUI: clientstatechangeable): Call the savechangetoserver () function of the Client GUI specified by the GUI parameter to save data.

• Clientreadonlystate: a sub-class of the read-only State to implement the clientstate interface;
  • Setcomponents (GUI: clientstatechangeable): Call getchangeablecomponents () of the Client GUI specified by the GUI parameter to obtain the control collection, and traverse and set the status of each control to readonly;
  • Action (GUI: clientstatechangeable): Empty method. There is no data change in the current state and you do not need to save it.

2.1.5 Code example
clientstatechangeable interface:

Public interface clientstatechangeable { /** * To get all changeable components in the GUI object. * @ Return collection contains component objects. */ Collection getchageablecomponents (); /** * To save data to server. */ Void savechangetoserver (); }

Aclientgui class:

Public class aclientgui extends jpanel implements clientstatechangeable { //... Private clientstate state = NULL; Public designstep1view (clientstate state ){ //... This. State = State; This. state. setcomponents (this ); } Private void okbutton_actionreceivmed (actionevent e ){ State. Action (this); // save data } Public Collection getchageablecomponents (){ Collection datacomponents = new arraylist (); Datacomponents. Add (jcomboboxesepattern ); //... Return datacomponents; } Public void savechangetoserver (){ //... } }

clientstate interface:
Public interface clientstate {/*** to set components' state in the GUI. * @ Param Gui A Gui object which implements statechangeable interface. */void setcomponents (clientstatechangeable GUI);/*** when user click OK-button in a GUI, the GUI will call this method. * @ Param Gui A Gui object which implements statechangeable interface. */void action (clientstatechangeable GUI);}
clientnormalstate class:

Public class clientnormalstate implements clientstate { /** * Normally, each control can be edited by default, so no changes are required. */ Public void setcomponents (clientstatechangeable GUI ){} /** * Normally, you need to save the changes made by the user to the server. */ Public void action (clientstatechangeable GUI ){ Gui. savechangetoserver (); } }

Clientreadonlystate class:

Public class clientreadonlystate implements clientstate { /** * Set the GUI Data Control to read-only. */ Public void setcomponents (clientstatechangeable GUI ){ Collection components = gui. getchageablecomponents (); Iterator iter = components. iterator (); While (ITER. hasnext ()){ Jcomponent JC = (jcomponent) ITER. Next (); JC. setenabled (false ); String tooltip = JC. gettooltiptext (); String addedtip = "Read-Only status "; If (tooltip = NULL) tooltip = addedtip; Else tooltip + = "." + addedtip; JC. settooltiptext (tooltip ); } } /** * The GUI is in the read-only status. You do not need to save the data to the server. */ Public void action (clientstatechangeable GUI ){} }

Type 2, 2.2: (reuse GUI)
2.2.1 motivation
When the layout and control types of multiple client guis are similar and the tasks are similar, you only need to carefully design and unify the GUI display forms, the same GUI can be used in multiple scenarios for reuse. In this case, different tasks need to operate different data sets.
These operations on different data sets can be implemented in the GUI class, but this will cause trouble for program maintenance. First, data operations belonging to different logics appear in the same type of files, resulting in logical confusion, increasing program size, and difficulty in debugging. Second, when using the GUI for new datasets, only new code can be added to the same file. At this time, the maintainability of the program is reduced, especially when new jobs are completed by other programmers, It is very laborious to understand the original code.
Similar to the solution mentioned in section 2.1.1: Separate the parts of the change and the unchanged parts so that the changed parts can be modified and expanded independently. Specifically, the operations related to the data set are extracted from the GUI program and an interface (namely, the Status Interface) for all data set operations is defined ), different data set operations exist as an implementation class of this interface. In this way, each data set is independently encapsulated in a State object. To use this GUI for new data, you only need to define a new state interface implementation class, you do not need to modify the existing class or even ignore the existing status.
2.2.2 Applicability
Applicable environment of this type: different data sets, the same operation mode. That is, the Client GUI does not change. Different Data Set Operations are delegated to the changed state object to complete.
2.2.3 structure (figure 3)

Figure 3 different data sets in the same operation mode

2.2.4 participants

• invariablegui: A Client GUI class that does not change itself. It maintains a reference state for variabledatastate and delegates data-related operations to the referenced object;
  • savechangetoserver (): Call state. processdata (this) to complete data-related operations.

• variabledatastate: State interface, which encapsulates data-related operations;
  • processdata (GUI: invariablegui): Call the members of the parameter GUI to obtain and process the data.

• datastate1, datastate2 ,...... Datastaten: A State subclass that implements the variabledatastate interface and encapsulates operations on a specific type of data set. You can define the status classes of multiple variabledatastate interfaces according to different data sets, so as to realize the reuse of invariablegui.

The implementation code of this type is not listed here. Refer to the Code in section 2.1.5 to easily implement the structure of this type.
2.3 combining the above two types
The preceding two types can be used in combination, that is, the GUI can be reused in the data set of the client software, and the GUI can be reused in the operation mode.
During program implementation, the GUI class can maintain a clientstate reference and a variabledatastate reference respectively:

• When initializing the GUI class, the GUI constructor calls the setcomponents () method of the clientstate object to set the control state;
• When a user submits an operation, the GUI calls the action () method of the clientstate object. 2 shows that this method calls back the savechangetoserver () method of the GUI using the passed GUI parameter, while the savechangetoserver () method () as shown in figure 3, the data operation is completed by calling the processdata () method of the State object referenced by variabledatastate.

3. Conclusion
The State mode introduced in this article can be applied to client software in multiple data and multiple operation modes, which can achieve remarkable results. However, if there are few client classes and states, this mode is used, instead, it increases the number of client classes and the complexity of the architecture. In this case, you can use the inherited Class System for reuse without the need to use the delegate and callback operations of State objects.