When you see a switch statement based on type or state, it should be replaced with polymorphism to improve code quality. 1. Encapsulate behavior inside the object by defining the abstract base class Order and allowing each order type to implement its own process method. 2. The client code directly calls order.process() without conditional judgment. 3. When adding an order type, you only need to add a new class, without modifying the existing code, and it complies with the principle of opening and closing. 4. Switch can be retained in scenarios such as cross-sectional logic or external data processing, but should be considered for packaging using factory or policy mode. 5. For complex behaviors, a policy pattern can be introduced, the algorithm can be independently encapsulated and dynamically injected to achieve decoupling. Finally, we obtain a scalable, easy-to-maintain, and highly cohesive code structure.

When you're working in object-oriented programming, it's common to see code littered with switch statements or long chains of if-else conditions that branch based on an object's type or state. While this approach works, it often leads to tightly coupled, hard-to-maintain code. A better way? Replace those conditions with polymorphism—let objects decide their own behavior.

Why Switch Statements Become a Problem

Switch statements, especially those based on types or status codes, tend to spread throughout the codebase. Every time you add a new type or state, you have to hunt down every switch block and update it. This violates the Open/Closed Principle—software entities should be open for extension but closed for modification.

For example:

 public void processOrder(Order order) {
    switch (order.getType()) {
        case STANDARD:
            // handle standard
            break;
        case EXPEDITED:
            // handle exposedited
            break;
        case RETURN:
            // handle return
            break;
    }
}

This logic is rigid. Add a new order type? You'll need to modify this method—and potentially others like it.

Polymorphism to the Rescue

Instead of asking an object what it is and then deciding what to do, let the object do the thing itself . This is the essence of polymorphism.

Start by defining a common interface or base class:

 public abstract class Order {
    public abstract void process();
}

public class StandardOrder extends Order {
    public void process() {
        // standard processing
    }
}

public class ExpeditedOrder extends Order {
    public void process() {
        // exposed processing
    }
}

public class ReturnOrder extends Order {
    public void process() {
        // return processing
    }
}

Now the client code becomes trivial:

 public void processOrder(Order order) {
    order.process(); // No switch needed
}

The behavior is encapsulated within each type. Adding a new order type? Just implement the Order interface—no existing code needs to change.

Benefits of This Approach

• Extensibility : New types can be added without modifying existing logic.
• Maintainability : Each class handles its own behavior—single responsibility.
• Testability : You can test each implementation in isolation.
• Readability : The intent is clear—no mental mapping from enum to action.

When to Keep the Switch

There are cases where switch (or if-else ) still make sense:

• When the logic is truly cross-cutting or coordinating (eg, routing, logging, error handling).
• When you're working with external data (like JSON or API responses) where polymorphism isn't directly applicable.
• In languages with strong pattern matching (like modern Java or Kotlin), switches can be more expressive and safer.

But even then, consider encapsulating the dispatch logic in a factory or strategy registry.

Strategy Pattern: Taking It Further

For more complex cases, the Strategy Pattern formalizes this idea. You define a family of algorithms, encapsulate each one, and make them interchangeable.

 public interface ShippingStrategy {
    void ship(Order order);
}

public class StandardShipping implements ShippingStrategy { ... }
public class ExpressShipping implements ShippingStrategy { ... }

public class Order {
    private ShippingStrategy shippingStrategy;

    public void ship() {
        shippingStrategy.ship(this);
    }
}

This decouples behavior from the core object and allow runtime selection.

Basically, whenever you see a switch on type or state, ask: Can this behavior live inside the object itself? If yes, let polymorphism handle it. The result is cleaner, more maintainable code that grows gracefully.

The above is the detailed content of From Switch to Strategy: Decoupling Logic with Polymorphic Alternatives. For more information, please follow other related articles on the PHP Chinese website!