Open-Closed Principle

No Change
adopt
First Added:June 24, 2026 Updated: July 2, 2026

Open-Closed Principle is a technique we adopt in the garden.

Summary

What it is: A stability rule. You extend behavior by adding new code (subtypes, plugins, handlers) rather than changing working implementations. Callers depend on abstractions that new variants plug into.

Why it matters: Every edit to shared core code risks regressions across the system. OCP localizes change to new types or modules and keeps proven paths untouched.

When to use: Pricing rules, notification channels, auth providers, export formats, and policy engines where product adds variants regularly. Natural fit with Design Pattern choices like Strategy, Template Method, and Decorator.

When to pull back: Code with one implementation and no forecast of variation. Do not add plugin frameworks before a second behavior exists. YAGNI still applies.

Relation to siblings: Single Responsibility Principle narrows units first. Dependency Inversion Principle supplies the abstractions OCP extends. Apply OCP after you can name the variation axis.

Details

Extension Mechanisms

MechanismFit
Interface + new implementationSwappable backends (storage, payment)
Registry of handlersEvent types, CLI subcommands
Configuration-driven behaviorFeature flags, rule tables
SubclassingUse sparingly; favor composition

Common Failure Modes

  • Abstract factories before a second concrete type exists
  • Deep inheritance trees where each new feature edits a base class
  • “Closed” code that is actually frozen because nobody dares to touch it
  • Plugin systems with no isolation (extensions break the core)

Practical Checklist

  1. Name the axis of change (what varies vs what stays stable).
  2. Introduce an abstraction callers already need for Dependency Inversion Principle.
  3. Add the new behavior as a new type or module, not a branch in the old one.
  4. Keep extension points small; fat interfaces violate Interface Segregation Principle.

Related Garden Items