The first instruction you learned should be the least you use
TL;DR: Remove all your Accidental IF-sentences
Problems Addressed
Code Duplication
Possible Typos and defects
Related Code Smells
Code Smell 36 - Switch/case/elseif/else/if statements
Maxi Contieri ・ Nov 28 '20
Code Smell 133 - Hardcoded IF Conditions
Maxi Contieri ・ May 20 '22
Code Smell 156 - Implicit Else
Maxi Contieri ・ Aug 6 '22
Code Smell 145 - Short Circuit Hack
Maxi Contieri ・ Jun 30 '22
Code Smell 101 - Comparison Against Booleans
Maxi Contieri ・ Nov 11 '21
Steps
Find or Create a Polymorphic Hierarchy
Move the Body of Each IF to the Corresponding Abstraction
Name the Abstractions
Name the Method
Replace if Statements with Polymorphic Message Sends
Sample Code
Before
public String handleMicrophoneState(String state) {
if (state.equals("off")) {
return "Microphone is off";
} else {
return "Microphone is on";
}
}
/* The constant representing the 'off' state is
duplicated throughout the code,
increasing the risk of typos and spelling mistakes.
The "else" condition doesn't explicitly check for the 'on' state;
it implicitly handles any state that is 'not off'.
This approach leads to repetition of the IF condition
wherever the state needs handling,
exposing internal representation and violating encapsulation.
The algorithm is not open for extension and closed for modification,
meaning that adding a new state
will require changes in multiple places in the code. */
After
// Step 1: Find or Create a Polymorphic Hierarchy
abstract class MicrophoneState { }
final class On extends MicrophoneState { }
final class Off extends MicrophoneState { }
// Step 2: Move the Body of Each IF to the Corresponding Abstraction
abstract class MicrophoneState {
public abstract String polymorphicMethodFromIf();
}
final class On extends MicrophoneState {
@Override
public String polymorphicMethodFromIf() {
return "Microphone is on";
}
}
final class Off extends MicrophoneState {
@Override
public String polymorphicMethodFromIf() {
return "Microphone is off";
}
}
// Step 3: Name the Abstractions
abstract class MicrophoneState {}
final class MicrophoneStateOn extends MicrophoneState {}
final class MicrophoneStateOff extends MicrophoneState {}
// Step 4: Name the Method
abstract class MicrophoneState {
public abstract String handle();
}
final class MicrophoneStateOn extends MicrophoneState {
@Override
String handle() {
return "Microphone is on";
}
}
final class MicrophoneStateOff extends MicrophoneState {
@Override
String handle() {
return "Microphone is off";
}
}
// Step 5: Replace if Statements with Polymorphic Message Sends
public String handleMicrophoneState(String state) {
Map<String, MicrophoneState> states = new HashMap<>();
states.put("muted", new Muted());
states.put("recording", new Recording());
states.put("idle", new Idle());
MicrophoneState microphoneState =
states.getOrDefault(state, new NullMicrophoneState());
return microphoneState.handle();
}
Type
[X] Semi-Automatic
Safety
Most steps are mechanic. This is a pretty safe refactoring
Why is the code better?
The refactored code follows the open/closed principle and favors polymorphism instead of using IFs
Limitations
You should only apply it to Accidental IFs.
Leave the business rules as "domain ifs" and don't apply this refactoring
Tags
- IFs
Related Refactorings
Refactoring 013 - Remove Repeated Code
Maxi Contieri ・ Jun 16
See also
How to Get Rid of Annoying IFs Forever
Maxi Contieri ・ Nov 9 '20
Credits
This article is part of the Refactoring Series.
Top comments (1)