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

How to understand that If-Else is a barren polymorphism problem

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

Share

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

This article mainly explains "how to understand If-Else is a barren polymorphism problem". The content of the article is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "how to understand If-Else is a barren polymorphism problem".

I often see many branches on enumerations or other discrete values, and even get annoyed when some developers are asked not to use if-then-else. If-else and switch can certainly generate concise code, and your software should not consist of the fewest lines, nor should it sacrifice readability, maintainability, or flexibility.

What are the consequences of using enumerations in if-then-else statements? Branches based on discrete values make it difficult for the software to change. Each new feature requires tracking where the branch occurs and modifying existing code accordingly.

This is definitely not the way we want. This may be the first step in making your code work, but as you continue to improve your code, switch and if-then-else certainly no longer exist.

I must say that the traditional method of branching with if-else and switch is out of date. It is unreliable and inflexible. There is no object-oriented content in traditional methods. But it is still booming because students are forced to think it is right, even best practice. The code is valid, but you can do better.

Imagine this problem. Suppose that for some reason, there must be a way to update the user. For simplicity, users need to be updated in the system for only two reasons.

The initial set of requirements

You can implement these two simple situations in the following code snippet. Take a moment to read this poorly designed code, which is regarded by many senior developers as a nightmare, and it is even thought to be the snake that triggered the decade of fear of well rope.

Yes, I've seen such crazy wild code. This is a very naive operation that assumes that users will never have so many reasons to change.

Scary code examples of useless if-else instructions

The only benefit of this code is that you can try to implement a semi-CQS design pattern. If you tend to say, "that should be a switch," then you should take some time to think about what is important in software development. Switch doesn't matter to if-else at all.

Who would have thought that you would be hit by new requirements all the time? You thought nothing would happen. The request for you now goes like this:

Do you really want to implement user updates for these two new reasons by adding other enumerated values and attaching two else-if statements? If you decide to go the wrong way, the result will be like this.

A complex and troublesome branch

This realization is essentially a barren polymorphism. In addition to constantly adding extra branches (which is a questionable practice in itself), whenever you need to debug or perform bug fixes, you are surrounded by completely unrelated code.

There's one more question. This method tag is deceiving us because it is not just updating users. It also chooses which algorithm to execute based on the reason for the update, and even knows each implementation. It is now clear that this approach bears a lot of responsibility.

I believe this example deepens all the terrible impressions about if-else and switch. Let's see how to avoid this annoying method.

Refactoring to polymorphic execution is very easy. The branch-based messy code is refactored into cohesive, simple, and practical classes. Before someone says they are afraid of using classes, I want to clarify one thing. The cost of instantiating a new class is usually negligible, so don't try to optimize the code until you encounter a bottleneck.

We can do better and write readable, maintainable, and flexible code. By replacing traditional branches with polymorphic execution, there is a clear relationship between a class and the requirements it manages. Simple, highly cohesive classes with clear responsibilities are easy to maintain. It becomes easy to detect and correct defects. Most importantly, the software can easily accommodate new features without having to modify existing classes.

Let's start refactoring. Let's see how well you can do without using if-then-else or switch. UpdateAsync (Reason,User) is so simple now.

Simplified implementation of UpdateAsync method

Note that you are now using interface parameters instead of enumerations. This method now delegates the responsibility of knowing how to perform updates on specific objects. The specific implementation of IUpdateReason is shown below, and the details of the constructor parameters and method implementation are not detailed.

UpdateReason Interface and its implementation

Each class fully meets the requirements of its management. Debugging, fixing bugs, and testing are now much easier than outdated methods. In this case, any new requirements will result in a special class.

We can easily stop here and finish the day's work. You reconstruct tedious branches and replace them with polymorphisms. Your code is now object-oriented and easy to maintain. But you can also choose to take the final step. UpdateAsync (Reason,User) is a bit redundant now. To solve this problem, we are no longer refactoring-we are redesigning all parts of the system.

In this case, it makes sense to create command objects and command handlers. It simplifies the calling code because it only dispatches commands such as UpdateUserAddress and invokes the operation of the corresponding handler

Thank you for your reading, the above is the content of "how to understand If-Else is barren polymorphism". After the study of this article, I believe you have a deeper understanding of how to understand the problem of If-Else is barren polymorphism, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

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