Strategy enumeration: eliminate the elegant gesture of mass use of if else in the project

Wen / Zhu Jiqian

When I first came into contact with java object-oriented programming, if I encountered a large number of process judgment statements, almost the full screen was full of if else statements, which made me forget where the head and tail were. However, even if the full screen was full of if else, I didn't feel uncomfortable at that time. When you wait until your programming ability is gradually improved, and then look back at the full screen if else you once wrote, there is only one picture in your mind, all of which are Xiang

Maybe beginners will ignore this. In fact, if else is a process oriented implementation.

So, how to avoid using if else in object-oriented programming?

There are many solutions on the network, including factory mode, strategy mode and even rule engine (this is too heavy)

All of these have a common disadvantage. They are still too heavy to use. Although too many if else are avoided, many additional classes will be added. I always think it is very impractical and can only be used as a learning mode.

It can replace a large number of if else statements, has good readability and scalability, and can be lightweight. I recommend using policy enumeration to eliminate if else.

How to use it? Let's start with a business case——

If there is such a requirement, it is necessary to realize the memo function of knowing what to do within seven days a week, which will involve a process judgment. You may immediately think of using if else, so it may be realized in this way——

In the business logic, a small number of such codes are OK. If there are hundreds of judgments, the whole business logic may be full of if else, which is neither elegant nor redundant.

At this point, you can consider using the policy enumeration form to replace this pile of process oriented if else implementations.

First, define a gettodo () calling method. If "Monday" is passed in, that is, the parameter "Monday".

In the gettodo () method, through dayenum Valueof ("Monday") can obtain a dayenum enumeration element. Here, we get the Monday.

Next, execute checkday Day (dayenum. Valueof ("Monday") will enter the day () method. Here, when a policy match is made through dayenum. Todo(). Be careful, dayenum Valueof ("Monday") gets the Monday in the enumeration. In this way, the Monday is actually executed Todo(), that is, todo() in Monday will be executed——

Why is the above execution process like this? Only by entering the dayenum enumeration can I know what's going on - (voice over: when I first came into contact with the strategy mode, I was surprised. It turned out that enumeration can still be played like this)

In the dayenum enumeration attribute, an abstract method that implements todo () is defined——

The todo () abstract method is overridden in each enumeration element. In this way, when passing reference dayenum Valueof ("Monday") is transferred to dayenum Todo() is essentially to find the enumeration element corresponding to the definition of Monday in the dayenum enumeration, and then execute its internally overridden todo() method. Expressed in the form of if esle, it is similar to "Monday" When equals (day) matches true, you can get its internal things.

To sum up, the policy enumeration uses the policy mode in the enumeration. The so-called policy mode is to give you a key. In a certain agreed way, you can be immediately guided to find the door that can be opened. For example, the key I gave you is "Monday", so you can use the agreed way dayenum Todo(), immediately find the Monday gate in the enumeration, and then go into the gate to do what you want to do todo(), in which the rooms behind each door have different functions, but they all have the same abstract function - todo(), that is, the common place of each room can be used to do some things, but the specific things are different. In this case, todo () in each gate can get different string returns according to different strategy modes, such as "English class today", "Chinese class today", and so on.

It can be seen that extracting process judgments into policy enumeration can also decouple a pile of judgments to avoid presenting a large number of redundant if else in business code logic.

Here, there will be a situation, that is, if there are multiple repeated judgments with the same function, for example, in if else——

So, how should we use it under policy enumeration to avoid code redundancy?

You can refer to the following ideas to set an internal policy enumeration and point external references with the same function to the same internal enumeration element, so as to call the duplicate function——

To extend its judgment process, you only need to directly add an attribute and internal todo (Implementation) in the enumeration to add a new judgment process. For the outside, you can still use the same entry dayenum. Todo().

There may be such a question: why is an abstract method defined in enumeration implemented in each enumeration element?

This function is similar to the practice of subclass inheriting parent class. Dayenum is similar to a parent class, and the elements in the dayenum enumeration are its subclasses. When the abstract method todo() is defined in the parent class, its inherited subclasses will implement the todo() method by default. In this way, the following can be written in the enumeration:

I like to use policy enumeration to eliminate substitution in a large number of if else. In a word, using policy enumeration can flexibly handle various complex judgments, and has good readability and scalability. It is more like functional programming, that is, passing in a parameter can get the value returned in the corresponding mode.

If a large number of if else are used in business logic in Java, it is process oriented, because the if else in business logic is judged from top to bottom if one by one. If you make a breakpoint on each if and debug, you will understand that it is actually process oriented.

It can be seen that if there are a large number of if else in the project, it will really affect the performance. Although the performance is negligible, isn't it better to have a better replacement scheme?

welcome to the official account, about thinking, about culture, about growth --