Shulou(Shulou.com)06/02 Report--

I. demand

For a communication product, we need to develop a version upgrade management system. The system develops background management through Java, and Telnet initiates commands to the front-end base station equipment to obtain the version information of the base station equipment, and compares the differences with the current latest version in the background to determine what commands are executed to operate the software files of the base station equipment. There are two types of base station equipment:

Main control board (Master Board)

Controlled board (Slave Board)

The commands allowed to be executed by the base station equipment include transfer, active, inactive, etc. These commands are limited not only by the type of device, but also by what kind of terminal the device is running on. The types are as follows:

Shell

UShell

The constraints on the command are roughly shown in the following table (does not represent real requirements):

By logging in, you can connect to the Shell terminal of the main control board. At this time, if you execute the enterUshell command, you will enter the UShell terminal, and if you execute enterSlaveBoard, you will enter the Shell terminal of the control board. EnterUshell can also be executed on the control board to enter its UShell terminal. The system also provides the corresponding exit operation. The changes caused by the entire operation are shown in the following figure:

The process of performing the upgrade is to get the software version information of the base station equipment when the base station equipment is in a state of failure, and then compare it at the back end based on the latest version. After getting the differences between versions, transfer the new files through the transfer command, update the files with the put command, and delete the redundant files with the deleteFiles command. After a successful update, activate the base station equipment. Therefore, a typical upgrade process is as follows:

Login (Master Board Shell)

Inactive (Master Board UShell)

Get (Slave Board Shell)

Transfer (Master Board Shell)

Put (Slave Board Shell)

DeleteFiles (Slave Board Ushell)

Active (Master Board UShell)

Logout

The whole version of the upgrade system requires that no matter which category the current base station equipment belongs to and which terminal it is in, as long as the Telnet connection is not interrupted, the command requiring the upgrade must be executed successfully. If the current equipment and terminal do not meet the requirements, the system needs to migrate to the correct state to ensure the successful execution of the command.

Second, find a solution

Based on this requirement, the client calls we expect are (for simplicity, all method parameters are omitted):

/ / client

Public void upgrade () {

TelnetService service = new TelnetService ()

Service.login ()

Service.inactive ()

Service.get ()

Service.transfer ()

Service.put ()

Service.deleteFiles ()

Service.active ()

Service.logout ()

}

Such a simple and intuitive call actually encapsulates complex rules and transformation logic. How should we design to achieve this effect?

Use conditional branches

One solution is to use conditional branching, because for each Telnet command, you need to determine the current state in order to decide to perform different actions, such as:

Public class TelnetService {

Private String currentState = "INITIAL"

Public void transfer () {

Swich (currentState.toUpperCase ()) {

Case "INITIAL":

Login ()

CurrentState = "MASTER_SHELL"

Break

Case "MASTER_SHELL":

/ / ignore

.

}

/ / execute the transfer command

}

}

However, such an implementation is unacceptable because we need to write similar conditional branch statements for each command, which leads to duplicate code. We can encapsulate this logic into a method:

Public class TelnetService {

Private String currentState = "INITIAL"

Public void transfer () {

SwichState ("MASTER_SHELL")

/ / execute the transfer command

}

Private void switchState (String targetState) {

Switch (currentState.toUpperCase ()) {

Case "INITIAL":

Switch (targetState.toUpperCase ()) {

Case "INITIAL":

Break

Case "MASTER_SHELL":

Login ()

Break

/ / other branches

}

Break

/ / other branches

}

}

}

The switchState () method avoids the repetitive code of the conditional branch, but it also increases the complexity of the method implementation because it needs to judge both the current state and the target state, which is equivalent to a combination of conditions.

Kent Beck said: "all the logic (of the conditional branch) is still in the same class, and the reader does not have to look around for all possible calculation paths. But the disadvantage of conditional statements is that there is no way to modify its logic except to modify the code of the object itself.... the advantage of conditional statements is simplicity and localization." Obviously, because of the centralization of conditional branches, we only need to modify this place when a change occurs; but the problem is that any change needs to be modified, which is actually a bad smell of "Divergent Change" in refactoring.

Introduce responsibility-driven design

Duty-driven design emphasizes thinking about design from the perspective of "responsibility". The duty is the "anthropomorphic" mode of thinking, which is actually the thinking mode of object-oriented analysis and design: regarding the object as the "Siyou youth" with thought, judgment, knowledge and ability. This is what I call "smart objects". As long as you distinguish the responsibility, you can start from the perspective of knowledge and ability to find which object has the ability to perform the duty.

Going back to the example of a version upgrade system, and thinking about responsibilities from the perspective of commands such as transfer, put, and so on, you can identify responsibilities as follows:

Execute the Telnet command

Migrate to the correct state

Run the Telnet command

TelnetService has the ability to execute Telnet commands, and if there are too many commands to run, you can also consider reassigning the responsibility of running each command to the corresponding Command object. So who should perform the "transition to the right state"? See the ability? Who has the ability to migrate? An object can perform a certain duty, must have the knowledge to perform the duty, so it depends on the knowledge.

What knowledge is required to migrate to the right state? -- current state, target state, and how to migrate the state. As long as the current state and target state are determined, you can know how to migrate the state according to the previous state transition diagram. So, who knows for sure about the current state? -- only the state object itself knows! In the implementation of conditional branching, the state is expressed by a string, and the string object itself does not know what its value is, so it needs to take out its value to judge, which is the reason for using conditional branching. When a state is upgraded from a string to a state object, the value of the state is the knowledge that the state object "knows". When each state knows its own state value, they no longer need to judge the current state if they want to perform the duty of "migration state", which is why polymorphism can replace conditional branching.

We can define the inheritance tree of a state:

Public interface NodeState {

Void switchTo (?

}

Public class InitialState implements NodeState {}

Public class MasterShellState implements NodeState {}

When the state becomes the object and has the responsibility, the object is the functional object with thought. Unfortunately, it does not have enough knowledge to fully perform the responsibility of "migrating to the right state" because it does not know which target state to migrate to. This knowledge is known only by specific Telnet commands, so it needs to be passed on to it. One way is to pass it as a method parameter, but this will cause the method body to make a conditional branch judgment on the passed parameter. The other method uses the polymorphism of the method to explicitly define multiple methods to perform the responsibility of migrating to different target states:

Interface NodeState {

Void switchToInitial ()

Void switchToMasterShell ()

Void switchToMasterUshell ()

Void switchToSlaveShell ()

Void switchToSlaveUshell ()

}

Public class InitialState implements NodeState {

Public InitialState (TelnetService service) {

This.service = service

}

Public void switchToInitial () {

/ / do nothing

}

Public void switchToMasterShell () {

Service.login ()

Service.setCurrentState (new MasterShellState (service))

}

Public void switchToMasterUshell () {

Service.login ()

Service.enterUshell ()

Service.setCurrentState (new MasterUshellState (service))

}

Public void switchToSlaveShell () {

Service.login ()

Service.enterSlave ()

Service.setCurrentState (new SlaveShellState (service))

}

Public void switchToSlaveUshell () {

Service.login ()

Service.enterSlave ()

Service.enterUshell ()

Service.setCurrentState (new SlaveShellState (service))

}

}

Public class MasterShellState implement NodeState {

Public MasterShell (TelnetService service) {

This.service = service

}

Public void switchToInitial () {

Service.logout ()

Service.setCurrentState (new InitialState (service))

}

Public void switchToMasterShell () {

/ / do nothing

}

Public void switchToMasterUshell () {

Service.enterUshell ()

Service.setCurrentState (new MasterUshellState (service))

}

Public void switchToSlaveShell () {

Service.enterSlave ()

Service.setCurrentState (new SlaveShellState (service))

}

Public void switchToSlaveUshell () {

Service.enterSlave ()

Service.enterUshell ()

Service.setCurrentState (new SlaveShellState (service))

}

}

Class TelnetService {

Private NodeState currentState = new InitialState (this)

Public void setCurrentState (NodeState state) {

This.currentState = state

}

Public void inactive () {

CurrentState.switchToMasterUshell ()

/ / inactive impl

}

Public void transfer () {

CurrentState.switchToMasterShell ()

/ / real transfer impl

}

Public void active () {

CurrentState.switchToMasterUshell ()

/ / real active impl

}

Public void get () {

CurrentState.switchToSlaveShell ()

/ / get

}

}

This design does not achieve the "open and closed principle". When new states are added, all state classes that implement the NodeState interface need to be modified because of the need to add new methods to the interface. This is equivalent to changing from a "divergent change" bad taste of a conditional branch to a "shrapnel modification (Shotgun Surgery)" bad taste, that is, a change causes multiple modifications. However, compared with the conditional branching scheme, the complexity of the conditional branching scheme is much lower than that of the conditional branching scheme, which can effectively reduce the generation of bug.

State mode

The design idea of transforming a state into an object is the design of the state pattern. According to GOF's Design pattern, a standard state pattern class diagram is as follows:

When the business we want to design has complex state transition, it is often represented by the state diagram. With a state diagram, it can be easily converted to a state mode. Each state of the state diagram is encapsulated with a state object, and all state objects implement the same abstract interface. The method of the abstract interface is the command on the state diagram that triggers the state transition. The Context object holds a global variable that holds the current state object. Each state object holds a Context object and accesses the global current state variable through Context to complete the state migration. When a specific state object implements a state interface, if it is a command that does not meet the conditions, the implementation is empty or an exception is thrown.

According to the state diagram, it can be implemented as a state mode:

Interface NodeState {

Void login ()

Void logout ()

Void enterUshell ()

Void exitUshell ()

Void enterSlaveBoard ()

Void exitSlaveBoard ()

}

Public class InitialState implements NodeState {

Private TelnetService telnetService

Public InitialState (TelnetService telnetService) {

This.telnetService = telnetService

}

Public void login () {

/ / login

TelnetService.login ()

This.telnetService.setCurrentState (new MasterShellState (telnetService))

}

Public void logout () {/ / do nothing}

Public void enterUshell () {

Throw new IlegalStateException ()

}

/ / other methods

}

/ / other status objects are brief

When implementing commands such as Telnet's transfer, this design did not achieve the desired effect:

Public class TelnetService {

Private NodeState currentState = new InitialState ()

Public void setCurrentState (NodeState state) {

This.currentState = state

}

Public void transfer () {

/ / which state is currentState?

If (! currentState.isMasterShell ()) {

/ / need to migrate to the correct state

}

/ / transfer implementation

}

}

After introducing the state mode, the current state still needs to be judged in the transfer () method, which is different from the conditional branching scheme. Is there a problem with the state mode? No! This is actually a problem with the application scenario. Let's think of the scenario in which a subway swipes a card to enter a station. This scenario has only two states, Opened and Closed, and the status transition is shown below:

Compare the two state diagrams. For subway scenarios, when the local iron gate is in Closed, you need to pay by card to switch to Opened. If the conditions are not met, this state will always be maintained. That is, for client callers, the legal call can only be pay (), and if the invocation behavior is pass () or timeout (), the state object will not respond. This is not the case with version upgrade systems. When the system is in the Initial state, the system cannot restrict client callers from initiating the correct login () method. Because the command operations provided to the client are not login (), enterUShell () and other methods that cause state changes, but transfer, put and other commands. At the same time, the requirements require that no matter what state you are currently in and what commands are executed, you must migrate to the correct state. This is the reason why the version upgrade management system cannot be designed according to the standard state mode.

III. Conclusion

If we are familiar with the state pattern, we may first think of the state pattern for the business scenario of this article. However, the design pattern has application scenarios, we can not blindly act recklessly, or follow the pattern to apply, this will lead to problems. By distinguishing the design method of responsibility and clarifying the meaning of the so-called "intelligent object", we can still deduce a good design. Although we abstract the state object, the abstract method is not the behavior that causes the state transition, but the behavior of the state migration. We do not start with the design pattern, but start from the "responsibility" to drive the design, which is the design driving force of the responsibility-driven design.

When we introduce stateful intelligent objects, we do not get a design scheme that fully follows the principle of open and closed. In fact, it is very difficult to be completely open to extensions when the state changes. Even if it is feasible, it is not necessary to pay too much design and development costs when the requirements for state change are unknown. It can be properly designed to meet current needs. Of course, we can consider changing the abstract state interface to an abstract class, so that the impact of adding new methods on the implementation class can be reduced. However, Java 8 provides a default method for interfaces, which can already circumvent this problem.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.