preface
Unsurprisingly, this should be the last time to share a few tips for actual development.
For example, would you normally write code like this:
if(a){
//dosomething
}else if(b){
//doshomething
}else if(c){
//doshomething
} else{
////doshomething
}
Copy the code
If there’s too many else ifs, then the logic here is going to be confusing and error prone.
Like this:
A judgment condition from a client command in CIM.
In the beginning, there were fewer conditions, so I didn’t care about so much direct writing; Now I have so many functions that I have to double check every time I add an else condition, for fear of affecting the previous logic.
This time I finally had enough and reconstructed it. After reconstruction, the structure here is as follows:
Finally, it becomes two lines of code, which is much simpler.
Previously, all implementation logic was extracted separately into other implementation classes.
So whenever I need to add an else logic, ALL I need to do is add a new class that implements the same interface. Each processing logic is independent of each other.
implementation
A sketch is drawn based on the current implementation.
The overall idea is as follows:
- To define a
InnerCommand
Interface, one of themprocess
Functions are handed over to specific business implementations. - Depending on your business, there will be multiple class implementations
InnerCommand
Interface; All of these implementation classes are registeredSpring Bean
Container for later use. - Enter commands through the client from
Spring Bean
Get one from the containerInnerCommand
Instance. - Execute final
process
Function.
The main goal is to get the InnerCommand instance dynamically based on the current state of the client instead of having multiple criteria.
The most important source is the InnerCommandContext class, which dynamically retrieves the InnerCommand instance based on the current client command.
- The first step is to get all of them
InnerCommand
List of instances. - Get the class type from the list of instances in the first step based on the command entered by the client.
- From class type
Spring
Gets a concrete instance object from the container.
Therefore, the first step is to maintain the corresponding class types of each command.
So the relationship between the command and the class type was maintained in the previous enumeration, and you only need to know the command to know its class type.
This allows you to replace the previously complex if else with only two lines of code, but also to extend it flexibly.
InnerCommand instance = innerCommandContext.getInstance(msg);
instance.process(msg) ;
Copy the code
conclusion
Of course, you can do more flexible, for example, do not need to maintain explicit command and class type correspondence.
Just scan all the classes that implement the InnerCommand interface at startup. There are similar implementations in CICADA, so you can check them out for yourself.
I hope these tips will help you.
All the above source code can be viewed here:
Github.com/crossoverJi…
Your likes and shares are the biggest support for me