My use of "concrete types" was merely a proxy for any code upon which client code should not have an explicit dependency. I don't see interfaces and plugins as

My use of "concrete types" was merely a proxy for any code upon which client code should not have an explicit dependency. I don't see interfaces and plugins as being orthogonal at all, you can't very well have plugins without interfaces (it wouldn't be much of a plugin if the client depended on the "plugin" itself). Besides, orthogonal vectors don't get you to the same place. ;-) In my opinion, the defining feature of a plugin is that it can be loaded and used with no modification of the code that uses it. On architectures with dynamic loading, this means you can drop a DSO somewhere and use it without code modification or relinking. "Factories", as usually described, would require some modification of the factory to support this new implementation (perhaps just a single line). A "factory" with a runtime-extensible list of implementations that it knows about, is a plugin architecture, but a plugin architecture need not look anything like a factory.