Comparison
Late bindingvsPlugin architecture
Late binding
which implementation runs was decided when the program started, from a config value, not when it was compiled.
Deferring the decision of which code a call reaches until as late as possible — runtime rather than compile time. It is the property that makes plugins, hot-swappable strategies and configuration-driven implementations possible, and it is what you give up in exchange when you choose the safety of a direct call. Every technique in this cluster is a way of choosing where on that spectrum a particular decision should sit.
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 →