Replacing If‑Else: Five Techniques from Basic to Advanced

Hello everyone, I'm your friend "Architecture Jun", a architect who writes code and poetry.

This article does not endorse or reject any particular coding style; it simply offers alternative ideas and useful patterns for developers.

It starts by explaining that if‑else is usually a poor choice because it makes designs complex, reduces readability, and hampers refactoring, yet it remains a common default for many developers.

The first technique shows how to eliminate an unnecessary else block, simplifying the code and making it look more professional by returning early when a condition is met.

The next technique introduces guard clauses for precondition checks, ensuring that a method only proceeds when inputs are valid, thereby improving defensive coding.

Then the article demonstrates converting if‑else logic into a dictionary (or map), which removes the need for multiple conditional branches and makes the code more maintainable.

It also covers extending applications without relying on additional if‑else statements by using a strategy pattern: extracting each branch into its own strategy class, dynamically discovering implementations, and selecting the appropriate strategy at runtime.

The refactoring steps are summarized as: (1) extract each branch into a separate strategy class via a common interface, (2) dynamically locate all implementations, and (3) decide which strategy to execute based on input.

Finally, the article concludes with a brief promotion of a Java architecture community and related resources.