Comparison
Open–closed principlevsSOLID
Open–closed principle
adding the fourth payment method meant editing the same switch statement for the fourth time.
The principle that a module should be extensible without editing its existing source: new behaviour arrives as new code rather than as a change to code that already works. In practice it is achieved by putting the variation behind an abstraction the module calls out to — a strategy, a registered handler, a plugin. The honest caveat is that you cannot make a module open to variation you did not anticipate, so applying it before you know the axis is how speculative generality gets built.
Full entry →SOLID
someone rejected the pull request citing a five-letter acronym, and only two of the five letters were actually about the problem.
Five object-design principles collected under one acronym: single responsibility, open–closed, Liskov substitution, interface segregation and dependency inversion. Taken individually they are useful heuristics with genuine failure modes to point at; taken as a checklist they are the most reliable way to talk a team into more indirection than it needs. Being able to name all five and say honestly which ones you find load-bearing is a better interview answer than reciting them.
Full entry →