Comparison
Open–closed principlevsPremature abstraction
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 →Premature abstraction
there is an interface with one implementation and a config flag that has never been anything but its default.
Building a general mechanism before there is a second case to generalise from, so the abstraction encodes a guess about which axis will vary. It is worse than duplication because the wrong abstraction is harder to undo — every caller now depends on its shape, so removing it is a change to all of them. Sandi Metz's formulation is the one to remember: prefer duplication over the wrong abstraction.
Full entry →