# if-else-switch

DevFeed: [if-else-switch](<https://devfeed.tech/articles/if-else-switch-21793.md>)

Original publisher: [Read original article](<http://blog.cleancoder.com/uncle-bob/2021/03/06/ifElseSwitch.html>)

Published: 2021-03-06T00:00:00Z

Content type: opinion

Language: en

Sources: [Robert C. Martin](<https://devfeed.tech/sources/robert-c-martin.md>), [The Clean Code Blog](<https://devfeed.tech/sources/the-clean-code-blog.md>)

Topics: [Refactoring](<https://devfeed.tech/topics/refactoring.md>), [Polymorphism](<https://devfeed.tech/topics/polymorphism.md>), [Software](<https://devfeed.tech/topics/software.md>), [systems](<https://devfeed.tech/topics/systems.md>), [cloud-infrastructure](<https://devfeed.tech/topics/cloud-infrastructure.md>)

Tags: [code](<https://devfeed.tech/tags/code.md>), [dependencies](<https://devfeed.tech/tags/dependencies.md>), [monolithic-architecture](<https://devfeed.tech/tags/monolithic-architecture.md>), [polymorphism](<https://devfeed.tech/tags/polymorphism.md>), [refactoring](<https://devfeed.tech/tags/refactoring.md>), [software](<https://devfeed.tech/tags/software.md>), [source](<https://devfeed.tech/tags/source.md>), [structure](<https://devfeed.tech/tags/structure.md>)

## AI overview

The article argues that repeated if/else or switch statements create fragile systems and tangled dependencies. It recommends isolating the conditional logic in a factory and using polymorphic objects to break dependencies on lower-level modules, supporting more flexible component-based architectures.

## Source excerpt

A few days ago someone tweeted a question asking which of the following PHP snippets was better than the others, or whether there might be an even better approach. I tweeted my answer in the following cryptic paragraph. Place the if/else cases in a factory object that creates a polymorphic object for each variant. Create the factory in 'main' and pass it into your app. That will ensure that the if/else chain occurs only once. Others have since asked me for an example. Twitter is not the best medium for that so... Firstly, if the sole intent of the programmer is to translate: 0->'male', 1->'female' otherwise -> 'unknown' ...then his refactoring #2 would be my preference. However, I have a hard time believing that the business rules of the system are not using that gender code for making policy decisions. My fear is that the if/else/switch chain that the author was asking about is replicated in many more places within the code. Some of those if/else/switch statements might switch on the integer, and others might switch on the string. It's not inconceivable that you'd find a if/else/switch that used an integer in one case and a string in the next! The proliferation of if/else/switch statements is a common problem in software systems. The fact that they are replicated in many places is problematic because when such statements are inevitably changed, it is easy to miss some. This leads to fragile systems. But there is a worse problem with if/else/switch statements. It's the dependency structure. Such statements tend to have cases that point outwards towards lower level modules. This often means that the module containing the if/else/switch will have source code dependencies upon those lower level modules. That's bad enough. We don't like dependencies that run from high level modules to low level modules. They thwart our desire to create architectures that are made up of independently deployable components. However, the above diagram shows that it's worse than that. Other hig