Use the policy pattern to replace complex conditional logic based on type or state with extensible policy classes; 2. Eliminate type checking through polymorphism, so that each object can realize its behavior on its own; 3. Replace simple value-to-value or value-to-action mapping with lookup tables (such as dictionaries); 4. Use guard clauses to return in advance to reduce nesting levels; 5. Extract methods to name and isolate conditional logic. These reconstruction methods convert complex conditional statements into clear and maintainable code, improving readability and scalability, and fully following the principle of opening and closing, ultimately achieving a clean and expressive design.

Complex conditions—often called “God Switches”—are a common code smell that makes software hardware to read, test, and maintain. These sprayling if-else or switch statements, usually driven by multiple conditions or types, tend to grow over time, becoming a breeding ground for bugs and technical debt. Refactoring them is essential for writing clean, maintained code.

The goal isn't to eliminate conditions entirely—they're a necessary part of programming—but to manage their complexity by extracting logic, reducing duplication, and aligning code with object-oriented or functional design principles.

Here's how to reflector God Switches into clean, expressive code.

Replace Conditional with Strategy Pattern

When a switch or if-else block chooses behavior based on type or status, the Strategy Pattern is a powerful alternative.

Example:

 # Before: God Switch
def calculate_bonus(employee_type, sales):
    if employee_type == "manager":
        return sales * 0.2
    elif employee_type == "salesperson":
        return sales * 0.1
    elif employee_type == "intern":
        return 0
    else:
        raise ValueError("Unknown employee type")

This function will grow with every new role and is hard to test and extend.

Refactor:

 from abc import ABC, abstractmethod

class BonusStrategy(ABC):
    @abstractmethod
    def calculate(self, sales):
        pass

class ManagerBonus(BonusStrategy):
    def calculate(self, sales):
        return sales * 0.2

class SalespersonBonus(BonusStrategy):
    def calculate(self, sales):
        return sales * 0.1

class InternBonus(BonusStrategy):
    def calculate(self, sales):
        return 0

# Map types to strategies
STRATEGIES = {
    "manager": ManagerBonus(),
    "salesperson": SalespersonBonus(),
    "intern": InternBonus(),
}

def calculate_bonus(employee_type, sales):
    strategy = STRATEGIES.get(employee_type)
    if not strategy:
        raise ValueError("Unknown employee type")
    return strategy.calculate(sales)

Now adding a new role means adding a new class and updating the map—no touching existing logic. Open/Closed Principle achieved.

Use Polymorphism to Eliminate Type Checks

If you're switching on object type, it's a sign you should be using inheritance and polymorphism.

Example:

 # Before
def pay_employee(employee):
    if employee.type == "full_time":
        return f"Paid monthly: {employee.salary}"
    elif employee.type == "contractor":
        return f"Paid hourly: {employee.hourly_rate * 160}"

Refactor:

 class Employee(ABC):
    @abstractmethod
    def pay(self):
        pass

class FullTimeEmployee(Employee):
    def pay(self):
        return f"Paid monthly: {self.salary}"

class Contractor(Employee):
    def pay(self):
        return f"Paid hourly: {self.hourly_rate * 160}"

# Now usage is uniform
def pay_employee(employee: Employee):
    return employee.pay()

The conditional is gone. Each type knows how to pay itself. This makes the code extendible and easier to reason about.

Replace Conditional Logic with Lookup Tables

For simple mappings—like status codes to messages or actions—use a dictionary or map instead of if/elif chains.

Example:

 # Before
def get_status_message(status):
    if status == "pending":
        return "Your order is pending"
    elif status == "shipped":
        return "Your order has shipped"
    elif status == "delivered":
        return "Your order was delivered"
    else:
        return "Unknown status"

Refactor:

 STATUS_MESSAGES = {
    "pending": "Your order is pending",
    "shipped": "Your order has shipped",
    "delivered": "Your order was delivered",
}

def get_status_message(status):
    return STATUS_MESSAGES.get(status, "Unknown status")

Clean, fast, and data-driven. No logic, just lookup.

You can even map to functions:

 ACTIONS = {
    "save": save_document,
    "load": load_document,
    "delete": delete_document,
}

def handle_action(action):
    func = ACTIONS.get(action)
    if func:
        func()
    else:
        raise ValueError(f"Unknown action: {action}")

Guard Clauses: Simplify Early Returns

Sometimes the issue isn't the switch itself, but nested conditions. Use guard clauses to return early and flatten the logic.

Example:

 # Before
def process_user(user):
    if user is not None:
        if user.is_active:
            if user.has_permission:
                return "Processing..."
            else:
                return "No permission"
        else:
            return "Inactive user"
    else:
        return "No user provided"

Refactor:

 def process_user(user):
    if user is None:
        return "No user provided"
    if not user.is_active:
        return "Inactive user"
    if not user.has_permission:
        return "No permission"
    return "Processing..."

Each condition is handled at the top level. The happy path flows naturally without nesting.

Summary of Refactoring Tactics

• Use Strategy Pattern when behavior varies by type or rule.
• Apply Polymorphism when conditions check object types.
• Replace with lookup tables for simple value-to-value or value-to-action mappings.
• Extract methods to isolate conditional logic and give it a name.
• Use guard clauses to reduce nesting and improve readability.

The key insight: conditions aren't bad—they become problematic when they're repeated, deeply nested, or tied to growing business rules. By replacing them with well-named abstractions, you turn messy logic into maintainable design.

Basically, if your conditional is growing like a weed, it's time to reflector.

The above is the detailed content of Refactoring God Switches: From Complex Conditionals to Clean Code. For more information, please follow other related articles on the PHP Chinese website!