OOP & Design Principles • SOLID PrinciplesMedium⏱️ ~2 min
Open/Closed Principle (OCP): Extend Behavior Without Modifying Code
The Open/Closed Principle states that components should be open for extension but closed for modification. New features are added by writing new code that plugs into stable extension points, not by editing existing, battle tested modules. When Amazon adds a new payment method like buy now pay later (BNPL), the checkout flow should not require code changes; instead, a new PaymentProvider implementation registers with the existing provider interface.
At scale, OCP preserves latency and error profiles for existing consumers while shipping new capabilities. Kubernetes originated at Google and runs production clusters with 5,000+ nodes and scheduler throughput of tens to low hundreds of pod placements per second. The Container Network Interface (CNI) and Container Storage Interface (CSI) let cloud providers extend networking and storage without touching the core scheduler or kubelet. When a vendor adds a new CNI plugin, existing network policies and pod networking continue with identical performance; the new plugin simply registers and handles its own traffic without modifying kubelet code paths.
Microsoft Visual Studio hosts over 4,000 public extensions via stable extension points. Adding a new linter, refactoring tool, or language server does not require recompiling Visual Studio core. Extensions declare capabilities through interfaces, and VS loads only what they use (Interface Segregation Principle working alongside OCP). This keeps startup time predictable even as the extension ecosystem grows, because each extension's initialization overhead is isolated and lazy loaded.
The cost is designing the right abstraction up front. A poorly chosen extension point either becomes too rigid (forcing workarounds) or too wide (leaking implementation details and creating coupling). Google Ads real time bidding adapters honor strict contracts: respond within 100 to 120 milliseconds, respect rate limits, and return well formed bids. New bidders extend the auction engine by implementing the bidder interface without modifying core auction logic. If the interface doesn't capture timeout policies or error semantics correctly, implementations diverge and violate Liskov Substitution Principle, causing revenue impacting latency spikes. When variation pressure is low or the domain is unstable, prefer simple concrete code and defer abstraction until the extension pattern becomes clear.
💡 Key Takeaways
•Stable contracts enable safe extension: Kubernetes CNI and CSI interfaces let vendors add networking and storage plugins to clusters with 5,000+ nodes without modifying scheduler code, preserving sub millisecond plugin call overhead.
•Latency and error profiles stay stable: When Amazon adds a new payment provider, existing checkout flow keeps its p95 latency (150 to 400 ms for provider calls) and circuit breaker policies; only the new provider's behavior is new.
•Extension points require upfront design: Google Ads bidder interface must encode timeout (100 to 120 ms), rate limits, and error contracts. Poorly designed abstractions force workarounds or leak details, violating the principle.
•Reduces regression risk: Microsoft Visual Studio ships new linters and refactorings as extensions without recompiling core. Existing features see zero code edits, so testing scope shrinks and release velocity increases.
•Cost is premature abstraction: Adding extension points before variation appears creates unused complexity. Defer OCP until you have at least two real implementations or clear evidence of diverging requirements.
•Works with strategy injection: High level policies (checkout, auction, scheduling) depend on strategy interfaces (PaymentProvider, BidderAdapter, StorageBackend). Concrete strategies are injected at runtime per tenant or market.
📌 Examples
Kubernetes CNI: Add Calico, Cilium, or cloud provider CNI plugins by implementing the CNI interface. Core kubelet and scheduler remain unchanged; plugin overhead budgeted at sub millisecond per call path to maintain scheduling throughput.
Amazon checkout PaymentProvider interface: New payment methods (cards, wallets, BNPL, regional methods) implement the interface. Checkout logic calls provider.charge(amount) without conditionals; tens of thousands of checkouts per second during peaks stay stable.
Microsoft Visual Studio extensions: Over 4,000 public extensions add linters, refactorings, and language servers via stable extension points. Core VS code is closed; extensions are open.