Stable routing logic
Backend & Runtime / Knowledge library
Open-Closed Principle
Designs behavior to be extendable without repeatedly editing stable code
Why learn Open-Closed Principle?
It protects proven paths while enabling controlled variation
The problem it solves
It reduces regression risk when adding new cases
Where it came from
Open-Closed Principle is a software design principle that designs behavior to be extendable without repeatedly editing stable code. Its guarantees and tradeoffs depend on the concrete implementation and operating context.
Build your understanding
Work through these exercises in order. Try the task before opening a reference.
- Define Open-Closed Principle and distinguish it from a neighboring concept.
- Choose a realistic task where Open-Closed Principle is appropriate.
- Identify a failure mode caused by misusing Open-Closed Principle.
- Interpret a small design or result involving Open-Closed Principle.
- Explain one tradeoff or limitation of Open-Closed Principle.
Documentation and sources
- Software Engineering at Google (abseil.io)
Connect the ideas
Explore next
Real World Example
Modular Logistics Routing Engine
A global logistics provider managing diverse delivery fleets including drones, electric vans, and cargo ships.
The business problem
The core routing engine contained a massive conditional block checking vehicle types. Every time a new vehicle type was introduced, developers had to modify the stable, tested routing logic, leading to frequent regressions and deployment delays.
How this topic solves it
Applying the Open-Closed Principle, the team refactored the routing engine to accept an interface for route calculation. New vehicle types are now implemented as separate classes that satisfy the interface, allowing the core engine to remain untouched while supporting new delivery methods.
- Define a common interface for all routing strategies.
- Extract existing vehicle-specific logic into separate concrete classes.
- Inject the required strategy into the routing engine at runtime.
- Register new vehicle types through a configuration registry rather than code changes.
This diagram illustrates how the core engine interacts with new vehicle modules without modification.
Contract for calculations
New vehicle logic
Existing vehicle logic
- Core Engine → depends on → Routing Interface
- Drone Strategy → implements → Routing Interface
- Van Strategy → implements → Routing Interface
Expected business outcome
The core routing engine achieves high stability, as it no longer requires modification to support new vehicle types, significantly reducing the risk of side-effect bugs in existing delivery routes.
Limitations and checks
The primary tradeoff is increased architectural complexity due to the proliferation of small classes. To verify this, developers should monitor the number of classes in the routing package; if the count grows excessively without clear domain boundaries, it indicates an over-abstraction of the system.