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 aInnerCommandInterface, one of themprocessFunctions are handed over to specific business implementations.
  • Depending on your business, there will be multiple class implementationsInnerCommandInterface; All of these implementation classes are registeredSpring BeanContainer for later use.
  • Enter commands through the client fromSpring BeanGet one from the containerInnerCommandInstance.
  • Execute finalprocessFunction.

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 themInnerCommandList 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 typeSpringGets 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