Plugin architecture vs Interface Segragation Principle (SOLID) [closed]

Question

Uncle Bob's Interface Segragation Principle (ISP) tells us that many client-specific interfaces are better than one general-purpose interface. But plugin architecture in common case suppose to have one or more general-purpose interfaces. Thus a so-called micro-kernel doesn't know anything about specificity of clients and how they will use this general-purpose interface. So seems that ISP and plugin architecture are the opposite things, i.e. plugin architecture violates ISP.

I guess that the main reason (advantage (+)) for plugin architecture not to comply with ISP is to increase runtime extensibility. Your micro kernel just works and someone just writes and inserts plugins extending functionality. In case of set of specific interfaces you will need to add new interface, recompile and redeploy the module, which expose this new interface.
The main disadvantage (-) of plugin architecture is that if this thick interface will have even minimal changes, all the modules connected to general purpose interface must be adapted, recompiled and redeployed.
In other words:
(+) cheap runtime extension
(-) expensive micro-kernel updates (plugin interface change entails making changes to all depending modules)
There is a feeling that my comparison is at least incomplete. Are there any other differences, (dis)advantages?
In what cases does it make sense to choose the plugin architecture, and in what cases to separate interfaces?

Answer 1

The purpose of a plugin may be specific to your current application, but whatever it is, it is strictly delineated in your domain. The generic codebase has certain expectations of what a plugin is or isn't able to do - this is precisely what the plugin's interface describes.

The logical conclusion here is that "the plugin" is therefore a strictly defined concept that should not be broken into many possible sub interfaces. ISP describes the separation of interfaces when the individual pieces have no bearing on one another, which is simply not the case for "the plugin" as defined by your current application.

You didn't mention any specifics, but I infer that you're bringing ISP into the mix here because you likely have two or more distinct types of plugin that are currently sharing a single interface.

In that case, the thick interface (as per your phrasing) should indeed be subdivided until you have an interface for every specific type of plugin you wish to use. But you should stop subdividing when you get to the granularity level of "the specific plugin type", because this should no longer be divided into smaller parts if you want to retain the logical coherence of what "a plugin" represents in your domain.

The main disadvantage (-) of plugin architecture is that if this thick interface will have even minimal changes, all the modules connected to general purpose interface must be adapted, recompiled and redeployed.

There's a few things to consider here.

If the interface changes, then your core logic inherently will have to change too, since it is the consumer of the interface. That is an inescapable consequence. However, the core logic needing to change is often the reason as to why you're updating the interface to begin with.

In regards to the implementations of the interface needing to change when the interface changes, there are a few possible scenarios here.

If the interface changes, then you are inherently stating that the implementers of this interface must respond to this introduced change. Having to update your implementers is then not a bad thing, but rather an intentional part of the change process.

If you are trying to update your interface but want to remain backwards compatible with old implementations (e.g. you're trying to innovate the interface for your future plugin development); then you should look into versioning your plugin interfaces.
This means that the core logic needs to be able to handle both the old and new versions of your plugin; but this again is a logically inevitable consequence based on the original premise of wanting the core logic to retain backwards compatibility.