Open Closed Principle Explained with Python Examples

Imagine you buy a smartphone. Great! It does everything you need. A month later, you want to add new features — maybe a better camera app, a fitness tracker, or a game. Now picture this: Every time you want to add something new, you have to crack open the phone’s case, rewire the motherboard, and hope you don’t break the existing features. Sounds insane, right?

That’s exactly what happens when you violate the Open/Closed Principle. You keep modifying tested, working code to add new features, and each change is a game of Russian roulette — will it work, or will it blow up spectacularly? Today, we’re learning how to make your code work like smartphones: add new features by plugging them in, not by tearing everything apart.

🤔 Why Should You Care About OCP?

Without OCP (The Danger Zone):

• Every new feature requires modifying existing code
• “Small changes” break unrelated functionality
• Testing becomes endless (you retest EVERYTHING each time)
• Code becomes increasingly fragile
• Fear of touching anything paralyzes development

With OCP (The Safe Zone):

• New features are added via extension, not modification
• Existing code stays untouched and stable
• Testing focuses on new code only
• Confidence in deployments skyrockets
• Code scales beautifully

Think of OCP as the difference between a house where you can add rooms versus one where you have to demolish walls every time you want to redecorate.

---

🔓 The Golden Rule of OCP

“Software entities should be OPEN for extension but CLOSED for modification.”

Translation: Once you’ve written, tested, and deployed code — leave it alone. Add new functionality by extending it, not by rewriting it.

---

🚨 The Problem: The Never-Ending Function

Let’s see what disaster looks like. Meet the filter class that never stops growing:

class ProductFilter:
    def filter_by_name(self, products, name):
        for product in products:
            if product.name == name:
                yield product

Looks innocent, right? But then requirements come flooding in…

The Nightmare Begins:

class ProductFilter:
    def filter_by_name(self, products, name):
        for product in products:
            if product.name == name:
                yield product
    
    def filter_by_price(self, products, max_price):
        for product in products:
            if product.price <= max_price:
                yield product
    
    def filter_by_category(self, products, category):
        for product in products:
            if product.category == category:
                yield product
    
    def filter_by_name_and_price(self, products, name, max_price):
        for product in products:
            if product.name == name and product.price <= max_price:
                yield product
    
    def filter_by_name_or_price(self, products, name, max_price):
        for product in products:
            if product.name == name or product.price <= max_price:
                yield product
    
    # ... This goes on FOREVER! 😱

The horror: With just 3 criteria (name, price, category), you need:

• 3 individual filters
• 3 AND combinations (name AND price, name AND category, price AND category)
• 1 triple AND (name AND price AND category)
• Multiple OR combinations
• NOT combinations

That’s 15+ methods minimum! Add a 4th criteria? Now you need 31 methods. Add a 5th? 63 methods. It’s exponential chaos.

---

✅ The Solution: The Specification Pattern

Instead of endlessly modifying our filter class, let’s make it extensible. Enter the Specification Pattern — the OCP hero.

Step 1: Create the Base Classes

class Specification:
    """Base class for all specifications"""
    def is_satisfied(self, item):
        pass
    
    def __and__(self, other):
        return AndSpecification(self, other)
    
    def __or__(self, other):
        return OrSpecification(self, other)

class Filter:
    """Base filter that works with any specification"""
    def filter(self, items, spec):
        for item in items:
            if spec.is_satisfied(item):
                yield item

Key insight: The Filter class is now CLOSED for modification. We'll never touch it again!

Step 2: Create Specific Specifications (Extensions!)

class NameSpecification(Specification):
    def __init__(self, name):
        self.name = name
    
    def is_satisfied(self, item):
        return item.name == self.name

class PriceSpecification(Specification):
    def __init__(self, max_price):
        self.max_price = max_price
    
    def is_satisfied(self, item):
        return item.price <= self.max_price

class CategorySpecification(Specification):
    def __init__(self, category):
        self.category = category
    
    def is_satisfied(self, item):
        return item.category == self.category

Step 3: Combination Specifications (The Magic!)

class AndSpecification(Specification):
    def __init__(self, *specs):
        self.specs = specs
    
    def is_satisfied(self, item):
        return all(spec.is_satisfied(item) for spec in self.specs)

class OrSpecification(Specification):
    def __init__(self, *specs):
        self.specs = specs
    
    def is_satisfied(self, item):
        return any(spec.is_satisfied(item) for spec in self.specs)

class NotSpecification(Specification):
    def __init__(self, spec):
        self.spec = spec
    
    def is_satisfied(self, item):
        return not self.spec.is_satisfied(item)

---

🎉 Using It (The Beautiful Part)

# Sample products
products = [
    Product("Laptop", 1000, "Electronics"),
    Product("Mouse", 25, "Electronics"),
    Product("Desk", 300, "Furniture"),
    Product("Chair", 150, "Furniture")
]

# Create our filter (NEVER needs modification!)
filter_engine = Filter()

# Simple filters
cheap_items = filter_engine.filter(
    products, 
    PriceSpecification(100)
)

electronics = filter_engine.filter(
    products,
    CategorySpecification("Electronics")
)

# Complex combinations using operators!
cheap_electronics = filter_engine.filter(
    products,
    PriceSpecification(100) & CategorySpecification("Electronics")
)

expensive_or_furniture = filter_engine.filter(
    products,
    PriceSpecification(500) | CategorySpecification("Furniture")
)

# NOT operator
not_electronics = filter_engine.filter(
    products,
    NotSpecification(CategorySpecification("Electronics"))
)

What just happened?

1. We created filters using simple, composable specifications
2. We combined them with & (AND), | (OR), and Not
3. We added ZERO new methods to existing classes
4. The Filter class remains unchanged and stable

---

🚀 Adding New Criteria (The Power Move)

Need to filter by brand? Stock availability? Rating? No problem!

class BrandSpecification(Specification):
    def __init__(self, brand):
        self.brand = brand
    
    def is_satisfied(self, item):
        return item.brand == self.brand

class InStockSpecification(Specification):
    def is_satisfied(self, item):
        return item.stock > 0


class RatingSpecification(Specification):
    def __init__(self, min_rating):
        self.min_rating = min_rating
    
    def is_satisfied(self, item):
        return item.rating >= self.min_rating
# Use immediately without modifying Filter!
popular_in_stock = filter_engine.filter(
    products,
    RatingSpecification(4.5) & InStockSpecification()
)

You added 3 new filter types without touching the Filter class. THAT’S OCP in action!

---

💡 Real-World OCP Examples

Example 1: Payment Processing

❌ Bad (Violates OCP):

class PaymentProcessor:
    def process(self, payment_type, amount):
        if payment_type == "credit":
            # Credit card logic
        elif payment_type == "paypal":
            # PayPal logic
        elif payment_type == "crypto":
            # Crypto logic
        # Every new payment method = modify this class!

✅ Good (Follows OCP):

class PaymentProcessor:
    def process(self, payment_method, amount):
        return payment_method.process(amount)

class CreditCardPayment:
    def process(self, amount):
        # Credit card logic
        pass

class PayPalPayment:
    def process(self, amount):
        # PayPal logic
        pass

class CryptoPayment:
    def process(self, amount):
        # Crypto logic
        pass

Example 2: Notification System

✅ Good (Follows OCP):

class NotificationSender:
    def send(self, notification):
        notification.deliver()

class EmailNotification:
    def deliver(self):
        # Email sending logic
        pass

class SMSNotification:
    def deliver(self):
        # SMS sending logic
        pass

class PushNotification:
    def deliver(self):
        # Push notification logic
        pass

---

📚 TLDR Cheat Sheet

✅ OCP Rule: Open for extension, closed for modification
✅ Bad sign: Adding features by modifying existing classes
✅ Good sign: Adding features by creating new classes
✅ Specification Pattern: Perfect OCP example for filtering
✅ Benefits: Stable code, easier testing, fearless deployment
✅ Real analogy: Smartphone apps vs rewiring the phone

---

Start applying OCP today: Before adding a new method to an existing class, ask — “Can I extend instead?” If yes, create a new class. Your code will thank you by not breaking every deployment! 🔓

What’s your biggest “I modified code and broke everything” story? Share below! 💻✨