Open-closed principle

What it means

The open-closed principle suggests that software should be open to useful extension while closed to unnecessary modification of stable behavior. Polymorphism, configuration, composition, and data-driven rules can support this goal. It is a tradeoff, not a command to predict every future variation.

Example

A shipping calculator adds a new carrier by implementing a carrier contract and registering it, leaving existing carrier logic unchanged. The team still reviews whether the contract captures the real variation.

Limitations

Premature extension points add abstractions and can freeze a poor model. Some changes are clearer and safer when made directly. Use evidence of repeated variation, consumer ownership, and test coverage before generalizing.

How to use the signal

Wait for evidence of repeated variation before generalizing, because speculative extension points can freeze the wrong model.

Weave can show whether extension-oriented refactors reduce repeated changes or create review overhead. Keep the architecture decision explicit and use workflow evidence to evaluate the tradeoff.