Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

Analysis of the reasons why if-else of refactoring of Java programming details is not good code

2025-03-01 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Development >

Share

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

Editor to share with you the details of Java programming refactoring if-else is not a good code analysis, I believe that most people do not know much about it, so share this article for your reference, I hope you will learn a lot after reading this article, let's go to know it!

Preface

The main difference between process-oriented design and object-oriented design is whether to use lengthy if else judgment in the business logic layer. If you are still using if else a lot, except for the interface presentation layer, even if you use a completely object-oriented language like Java/C#, it only means that your mind is stuck in the traditional process-oriented language.

Do you usually use if-else in development?

In fact, this is a normal coding habit, when we have a small amount of code to make conditional judgment is very simple.

But for good programmers, this is not good code.

Why?

Putting aside the dose and talking about toxicity is a hooligan.

Where conditional judgment statements are used, if the amount of code is small and there are few scenarios to judge

Then there is no more appropriate statement than if-else, such as the following

.. if (object.getIndex () > 0) {/ / do something} else {/ / do other things}

So under what circumstances will if-else get worse?

Take the above code as an example, as the situation that needs to be judged increases gradually, the above code may become difficult to maintain.

On the way to advanced development, this sense of foresight should be cultivated step by step.

Even if the code is still in its infancy, you should be able to see the trend of code development in the future.

For example, in the above code, as there are more and more situations, if-else may develop many branches:

This is entirely possible, and in my experience I have seen such code on a number of projects.

And the logic in the code execution block can become very complex after several iterations, like this

The first feeling when I saw this code was to kill a little friend to sacrifice to heaven.

How to ReFactor this Code

The goal of refactoring for this kind of code can have two depths, depending on the severity of our obsessive-compulsive disorder.

Continue to use if-else, only reach stripping the execution code block

Decoupling with factory mode

In fact, it is not an either-or relationship between the two, but the depth of optimization is different. The first is relatively simple and can be reconstructed as follows

The code is much cleaner.

Now this code can clearly see what situations have been dealt with, and the code for condition judgment only pays attention to the differences in conditions.

And for the specific processing logic of different conditions, we stripped it to other places.

In this way, even if you write until you are confused, you will not be able to say which conditions have not been judged.

Further optimization

After the optimization above, how to continue the refactoring using the factory pattern?

From the code above, we can see that the execution logic is different under different conditions, so we can abstract this execution logic and use the concept of polymorphism to define different execution methods.

After this step is completed, the methods under different conditions in the code block can be extracted into different concrete classes.

Can it be further optimized? Yes, even the conditions here can be avoided. We can define a factory to contract new ExecutorWithTag ().

Do you still remember the factory pattern? the above code appeared in my previous article on the factory pattern, which can be regarded as a practical application of the factory pattern.

After this round of refactoring, the pile of code we wrote in one class has been extracted into several different classes

What happens to the code in the original class now?

After refactoring, the coupling between each Executor and the main class has been reduced to a very low level.

And the cleanliness of the code has been improved a lot. A piece of 50 + lines of code in the previous class has become 2 lines, which is the meaning of refactoring.

The above is all the content of the article "Java programming details refactoring if-else is not a good code". Thank you for reading! I believe we all have a certain understanding, hope to share the content to help you, if you want to learn more knowledge, welcome to follow the industry information channel!

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.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Development

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report