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 07 - Boolean Variables Code Smell 36 - Switch/case/elseif/else/if statements Code Smell 133 - Hardcoded IF Conditions Code Smell 156 - Implicit Else Code Smell 119 - Stairs Code Code Smell 145 - Short Circuit Hack Code Smell 101 - Comparison Against Booleans Code Smell 45 - Not Polymorphic 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 https://hackernoon.com/refactoring-013-eliminating-repeated-code-with-dry-principles?embedable=true See Also https://hackernoon.com/how-to-get-rid-of-annoying-ifs-forever-zuh3zlo?embedable=true This article is part of the Refactoring Series. How to Improve your Code With Easy Refactorings The first instruction you learned should be the least you use. The first instruction you learned should be the least you use. TL;DR: Remove all your Accidental IF-sentences TL;DR: Remove all your Accidental IF-sentences Problems Addressed Code Duplication Code Duplication Possible Typos and defects Possible Typos and defects Related Code Smells Code Smell 07 - Boolean Variables Code Smell 07 - Boolean Variables Code Smell 36 - Switch/case/elseif/else/if statements Code Smell 36 - Switch/case/elseif/else/if statements Code Smell 133 - Hardcoded IF Conditions Code Smell 133 - Hardcoded IF Conditions Code Smell 156 - Implicit Else Code Smell 156 - Implicit Else Code Smell 119 - Stairs Code Code Smell 119 - Stairs Code Code Smell 145 - Short Circuit Hack Code Smell 145 - Short Circuit Hack Code Smell 101 - Comparison Against Booleans Code Smell 101 - Comparison Against Booleans Code Smell 45 - Not Polymorphic Code Smell 45 - Not Polymorphic 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. Find or Create a Polymorphic Hierarchy. Find or Create a Polymorphic Hierarchy. Move the Body of Each IF to the Corresponding Abstraction. Move the Body of Each IF to the Corresponding Abstraction. Name the Abstractions. Name the Abstractions. Name the Method. Name the Method. Replace if Statements with Polymorphic Message Sends. 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. */ 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();
    } // 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 [x] Semi-Automatic [x] 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 . Accidental IFs Accidental IFs Leave the business rules as "domain ifs," and don't apply this refactoring. "domain ifs," Tags IFs IFs Related Refactorings https://hackernoon.com/refactoring-013-eliminating-repeated-code-with-dry-principles?embedable=true https://hackernoon.com/refactoring-013-eliminating-repeated-code-with-dry-principles?embedable=true See Also https://hackernoon.com/how-to-get-rid-of-annoying-ifs-forever-zuh3zlo?embedable=true https://hackernoon.com/how-to-get-rid-of-annoying-ifs-forever-zuh3zlo?embedable=true This article is part of the Refactoring Series. How to Improve your Code With Easy Refactorings How to Improve your Code With Easy Refactorings

Code Smell 257 - Simplifying Property Names By Removing Prefixes

Finding the Stinky Parts of Your Code: Code Smell 256 - Mutable Getters

Buy My Book

Share your ideas with me!

Refactoring 014 - How to Remove IF

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

10 Predictions About the Future of Finance

5 Essential Software Architecture Design Principles

A Beautiful Architecture of Server-Side Alarm

A Deeper Look into Clean Architecture: Flutter vs Kotlin

An Introductory Guide to Monolith Software Applications

10 Predictions About the Future of Finance

5 Essential Software Architecture Design Principles

A Beautiful Architecture of Server-Side Alarm

A Deeper Look into Clean Architecture: Flutter vs Kotlin

An Introductory Guide to Monolith Software Applications

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps