Comparison
Open–closed principlevsPlugin architecture
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 →Plugin architecture
someone added a feature by dropping in a package, and you did not change or redeploy the application to allow it.
Any design where third-party or optional code is discovered and loaded against a published extension point at runtime. It is the practical form of the open–closed principle at application scale, using late binding to make the extension possible without a rebuild. The costs are the ones every extensible product carries: a versioned contract, a trust boundary and failure isolation, because a plugin's crash is your crash.
Full entry →