Strategy Pattern for Conditional Logic

The Problem: The Brittle if/elif/else Chain

Imagine you're writing a simple command handler. As new commands are added, the if/elif/else chain grows longer and more unwieldy.

This is a classic "Java-ism" translated into Python. While functional, it has several major drawbacks that violate Pythonic principles:

• Poor Scalability: Adding a new command requires modifying the handle_command function directly. This violates the Open/Closed Principle (software entities should be open for extension but closed for modification).
• Low Cohesion: The handle_command function has to know about every single possible command. Its responsibility is too broad.
• Reduced Readability: As the chain grows, it becomes difficult to scan and understand the function's full scope.
• Difficult Testing: To unit test one command's logic, you're implicitly testing it through the handle_command function's branching logic. Testing the commands in isolation is cleaner.

The Solution: A Dictionary of Callables

The Pythonic solution is to use a dictionary to map command names (strings) directly to the functions that implement them. This is known as dictionary dispatch and is a simple, powerful way to implement the Strategy Pattern.

Let's refactor the if/elif/else example:

The "Bad" Way (from your Java habits):

def handle_command_bad(command, user):
    if command == "create":
        print(f"Creating item for {user}...")



        # ... logic for create
    elif command == "delete":
        print(f"Deleting item for {user}...")



        # ... logic for delete
    elif command == "update":
        print(f"Updating item for {user}...")



        # ... logic for update
    else:
        print(f"Unknown command: {command}")

The "Good" (Pythonic) Way:

# 1. Define each strategy as a separate, testable function.
def create_item(user):
    print(f"Creating item for {user}...")



    # ... logic for create

def delete_item(user):
    print(f"Deleting item for {user}...")



    # ... logic for delete
    
def update_item(user):
    print(f"Updating item for {user}...")



    # ... logic for update




# 2. Create the dispatch dictionary (the "command map").
COMMAND_MAP = {
    "create": create_item,
    "delete": delete_item,
    "update": update_item,
}




# 3. The main handler becomes a simple, clean dispatcher.
def handle_command_good(command, user):



    # Use .get() to safely retrieve the function and provide a default.
    handler_func = COMMAND_MAP.get(command)
    
    if handler_func:
        handler_func(user)
    else:
        print(f"Unknown command: {command}")




# Adding a new command is now trivial:
def archive_item(user):
    print(f"Archiving item for {user}...")




# Just update the map. No change to handle_command_good() is needed.
COMMAND_MAP["archive"] = archive_item

This approach is superior because:

• It's Extensible: New commands are added by defining a new function and adding an entry to the COMMAND_MAP. The handle_command_good function never changes.
• It's Testable: create_item, delete_item, etc., are pure functions that can be unit-tested independently.
• It's Readable: The intent is clear. handle_command_good dispatches a command; the COMMAND_MAP shows what commands are supported.

From Object-Oriented to Functional Strategies

Given your background, you may recognize this as a form of the Strategy Pattern. In Java, this is typically implemented with an interface and multiple concrete classes. Python's first-class functions allow for a much lighter, more direct implementation.

Advanced Application: The Registry Pattern

We can take this pattern one step further. Instead of manually maintaining the COMMAND_MAP dictionary, we can have functions register themselves automatically. This is known as the Registry Pattern. It's incredibly powerful for building plug-in architectures where you want to discover available functionality at runtime.

By combining a dictionary of callables with decorators, you can build systems where simply adding a new Python file with a decorated function is enough to extend the application's functionality, without touching any core code.

Exercise: Refactor a Data Transformer

You are given a function that performs various transformations on a list of strings based on a command. Your task is to refactor it using the dictionary-of-callables pattern.

Starter Code:

def transform_data(data: list[str], transformation: str) -> list[str]:
    """
    Applies a transformation to a list of strings.
    This function is poorly designed. Refactor it!
    """
    if transformation == "uppercase":
        return [s.upper() for s in data]
    elif transformation == "lowercase":
        return [s.lower() for s in data]
    elif transformation == "reverse":
        return [s[::-1] for s in data]
    elif transformation == "strip":
        return [s.strip() for s in data]
    else:



        # For an unknown transformation, raise an error.
        raise ValueError(f"Unknown transformation: {transformation}")




# --- Test cases (should still pass after refactoring) ---
dataset = ["  Hello World  ", "   Python Rocks!   "]




# Test existing transformations
print(f"Original: {dataset}")
print(f"Uppercase: {transform_data(dataset, 'uppercase')}")
print(f"Reversed: {transform_data(dataset, 'reverse')}")




# Test error case
try:
    transform_data(dataset, "invalid")
except ValueError as e:
    print(f"Caught expected error: {e}")

Your Tasks:

1. Create separate, single-responsibility functions for each transformation (uppercase, lowercase, reverse, strip). Each function should accept one argument: the list of data.
2. Create a TRANSFORMATION_MAP dictionary that maps the string command to its corresponding function.
3. Rewrite the transform_data function to use this map. It should be no more than 3-4 lines of code.
4. Ensure that an invalid transformation command still raises a ValueError. Using dict.get() with a default that raises an error, or a try...except KeyError block are both valid approaches.
5. Bonus: Add a new transformation, titlecase (which applies .title() to each string), by only defining a new function and adding one line to your TRANSFORMATION_MAP. The transform_data function itself should not be changed.

# 1. Create separate functions for each strategy
def to_uppercase(data: list[str]) -> list[str]:
    return [s.upper() for s in data]

def to_lowercase(data: list[str]) -> list[str]:
    return [s.lower() for s in data]

def to_reverse(data: list[str]) -> list[str]:
    return [s[::-1] for s in data]

def to_strip(data: list[str]) -> list[str]:
    return [s.strip() for s in data]




# Bonus: New transformation function
def to_titlecase(data: list[str]) -> list[str]:
    return [s.title() for s in data]




# 2. Create the dispatch dictionary
TRANSFORMATION_MAP = {
    "uppercase": to_uppercase,
    "lowercase": to_lowercase,
    "reverse": to_reverse,
    "strip": to_strip,
    "titlecase": to_titlecase, # Bonus
}




# 3. & 4. Rewrite the main function
def transform_data(data: list[str], transformation: str) -> list[str]:
    """
    Applies a transformation to a list of strings using a dispatch dictionary.
    """
    handler = TRANSFORMATION_MAP.get(transformation)
    if not handler:
        raise ValueError(f"Unknown transformation: {transformation}")
    return handler(data)




# --- Test cases ---
dataset = ["  Hello World  ", "   Python Rocks!   "]

print(f"Original: {dataset}")
print(f"Uppercase: {transform_data(dataset, 'uppercase')}")
print(f"Reversed: {transform_data(dataset, 'reverse')}")
print(f"Titlecase (Bonus): {transform_data(dataset, 'titlecase')}")

try:
    transform_data(dataset, "invalid")
except ValueError as e:
    print(f"Caught expected error: {e}")

Conclusion

You've now learned a powerful, Pythonic pattern for structuring your code that promotes flexibility and maintainability. This is a significant step away from the rigid conditional blocks common in other languages.

Key Takeaways:

• Identify the Anti-Pattern: A long if/elif/else chain selecting behavior based on a value is a code smell.
• Use Dictionary Dispatch: Replace the chain with a dictionary mapping keys to callable functions. This is a Pythonic implementation of the Strategy and Registry patterns.
• Benefits: This refactoring leads to code that is more extensible (obeys Open/Closed), more testable (strategies are isolated), and more readable.
• Handle Defaults: Always plan for invalid keys, either by using dict.get() to provide a default behavior or by handling a KeyError to fail gracefully.

In our next lesson, we will explore another advanced control flow pattern you specifically requested: modeling simple state machines using generator-based coroutines. This will equip you to manage complex, stateful logic in a clean and sequential manner, further reducing the need for tangled conditional logic.