0

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?

0

1 Answer 1

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.

5
  • Thank you for your explanation! Actually I just want to choose ISP, because I don't need to have runtime extensibility. But I'm trying to understand, are there any other benefits of plugin architecture. Maybe I'm missing something and I need to choose it after all..
    – red0ct
    May 2 at 10:46
  • "ISP describes the separation of interfaces when the individual pieces have no bearing on one another" - But I think plugins can be no bearing on one another too.. doesn't it?
    – red0ct
    May 2 at 10:48
  • @red0ct: Runtime extensibility is definitely a main benefit to a plugin interface (e.g. game mods), but it is not the only reason to use plugin interfaces. In cases where the core logic is developed prior to the concrete plugins and/or separate from the concrete plugins, the approach also makes sense.
    – Flater
    May 2 at 11:14
  • @red0ct: "I think plugins can be no bearing on one another too.. doesn't it?" The question isn't whether two plugins (i.e. two implementations of the same interface) can be separated; the question is whether the plugin interface itself should be separated into smaller digestible chunks. By definition of what a "plugin" constitutes, the answer here is no; provided that what you've defined as a plugin isn't a lumping together of several conceptually distinct plugins.
    – Flater
    May 2 at 11:16
  • In cases where the core logic is developed prior to the concrete plugins.. - Yep, this is something that follows from the specificity of general purpose interface. Also one more advantage follows from this fact - plugin general purpose interface is absolutely independent from plugins specificity - it knows nothing about individual plugins, but in ISP the interface provider knows every client needs specificity. So with ISP if the client starts to need something more - interface also must be updated, in plugin arch - every client already has all the data and behavior ("thick" interface).
    – red0ct
    May 2 at 19:51

Not the answer you're looking for? Browse other questions tagged or ask your own question.