Design-Patterns

📘 Design Patterns for Builders — Part 2 In Part 1, we used Strategy to remove if-else from business logic. Now we fix the next problem: who decides which strategy to create—and how? ⚡ TL;DR Don’t scatter SomeClass() across your codebase Centralize creation behind a factory Separate usage from creation Evolve toward registry/DI as systems grow The Problem (Picking Up From Strategy) After introducing Strategy, you often end up here: ...

You start simple. A small feature. A couple of conditions. Then it grows. And suddenly, your code looks like this: def process_payment(method, amount): if method == "credit_card": return f"Processing {amount} via Credit Card" elif method == "paypal": return f"Processing {amount} via PayPal" elif method == "upi": return f"Processing {amount} via UPI" elif method == "crypto": return f"Processing {amount} via Crypto" else: raise ValueError("Unsupported payment method") Looks fine… until it doesn’t. The Problem At first glance, this works. But the real issue isn’t the if-else. It’s this: ...