Open-Closed Principle OCP: Real Meaning

OCP sucks as named.

Everyone mangles the Open-Closed Principle (OCP). You know, that SOLID darling from Uncle Bob, rooted in Bertrand Meyer’s 1988 tome. “Software entities should be open for extension, but closed for modification,” he declared. Sounds noble. But try it. Predict every future tweak? Build hooks from day one? Pure fantasy. I did. Felt like a fraud every refactor.

Here’s Meyer’s exact words, straight from the source:

“Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.”

Noble on paper. Hell in practice. Coders — me included — twist it into precog mandates. Write code with invisible slots for tomorrow’s features. Miss one? Shame spiral. Nail it? Over-engineered mess. Anxiety fuel.

Then Jon Skeet drops truth bombs. 2013 blog post. Decade old, still slaps. He doesn’t trash low-level design tips. Nah. He eviscerates the name. “Open” and “closed”? Word salad. Clients — code clients, not users — shouldn’t shatter when you tweak internals. That’s the game.

Why Does OCP Trip Up Every Swift Dev?

Swift’s protocols scream OCP. Enums with associated values? Chef’s kiss for variation. Yet we biff it. Picture a payment processor. Start simple: CreditCardHandler. Works. Boom, users demand PayPal. Hack it? Switch statement explodes. Clients everywhere — order services, UIs — now rewrite. OCP violated. Not because you modified code. Because change rippled.

Bad Swift:

class PaymentProcessor {
    func process(_ type: String) {
        switch type {
        case "credit":
            // credit logic
        case "paypal":
            // paypal logic
        default:
            fatalError()
        }
    }
}

Ugly. Add Venmo? Clients scream. Fix: Protocol. Stable contract.

protocol PaymentHandler {
    func process(amount: Double)
}

class CreditCardHandler: PaymentHandler { ... }
class PayPalHandler: PaymentHandler { ... }

class PaymentProcessor {
    func process(_ handler: PaymentHandler) {
        handler.process(amount: 100.0)
    }
}

Clients depend on protocol. Swap handlers. No ripples. That’s OCP. Not zero mods. Contained change.

Skeet loves Craig Larman’s Protected Variations. “Identify points of predicted variation and create a stable interface around them.” Spot the wobble — payment types, say. Fence it. Rest of app chills.

But predicting? Skeet’s blunt: It’s hard. Overdo it, YAGNI violation. Underdo, refactor hell. My twist? Echoes microservices mania, 2015. Everyone sharded everything. Monoliths rotted from bloat. OCP’s the same trap — abstract prematurely, ship late.

Is Predicting Variation Just Over-Engineering?

Damn right, often. Domains shift. SwiftUI yesterday’s darling? VisionOS tomorrow. Build for ghosts, waste cycles. Real OCP: Spot current tremors. Users whining about formats? Protocol that now. Logs show payment flux? Stabilize.

Take reporting. Bad: Monolithic ReportGenerator. PDF, CSV, HTML crammed in. New Excel? Gut it.

Good:

protocol ReportFormatter {
    func format(data: [ReportData]) -> Data
}

class PDFFormatter: ReportFormatter { ... }
// etc.

Generator takes formatter. Clients oblivious. Variation caged.

Here’s Skeet’s killer line:

The goal is to design the boundary between them so that when the first part changes, the second part does not need to change every time as well.

Boundaries. Not bans on edits. Code evolves. Pretend otherwise? Delusional.

Swift shines here. Extensions. Protocol-oriented programming. Apple’s gift, if you don’t abuse it. Yet forums overflow: “OCP broken, modified class!” No, dummy. You skipped abstraction.

My bold call? In five years, textbooks ditch “open-closed.” Protected Variations wins. Skeet predicted it. Tools like Swift’s actor isolation already enforce boundaries. AI code-gen? It’ll bake this in, or spit garbage.

Swift Implementation: Do This, Not That

Real talk. ShapeDrawer app. Circles, squares. Naive:

class Canvas {
    func draw(shape: String) {
        if shape == "circle" { /* draw */ }
        else if shape == "square" { /* draw */ }
    }
}

Triangle? Rewrite Canvas. Clients (UI layers) cascade.

OCP fix:

protocol Drawable {
    func draw(on: Canvas)
}

class Circle: Drawable { func draw(on canvas: Canvas) { ... } }

class Canvas {
    func render(_ drawable: Drawable) {
        drawable.draw(on: self)
    }
}

Add Triangle. Canvas yawns. Clients untouched.

Scale it. Dependency injection. Factories. Swift’s got @MainActor, async/await — all boundary friends. Ignore? Your app’s a house of cards.

Corporate spin? Uncle Bob’s fans evangelize like zealots. “Predict changes!” No. React. Stabilize axes of change. Anxiety drops. Velocity soars.

One paragraph wonder: Tools evolve. Humans don’t.

History lesson: Meyer’s 1988 Eiffel pushed this. Pre-web. Now? Git, CI/CD eat mods for breakfast. OCP’s about resilience, not rigidity.

Prediction: Misuse OCP, watch your Swift app balloon. 20% abstraction bloat standard in enterprise. Fix understanding, trim fat.

🧬 Related Insights

• Read more: Why React’s map() Turns Arrays into Magic – Ditch For Loops Forever
• Read more: ClassPilot v2.0.3: Liquid Glass Glow-Up and AI Smarts for Stressed Students

Frequently Asked Questions

What is the Open-Closed Principle OCP really?

It’s about shielding clients from internal changes via stable interfaces, not banning all modifications.

How to implement OCP in Swift?

Use protocols for variation points. Inject dependencies. Let extensions handle growth.

Does OCP mean no code changes ever?

Nope. Just contain the blast radius.