Modelling a Plugin System

When building an infrastructure which require some kind of controlled extensibility one of the most common approaches is to consider a plug-in system. But how should it be considered in the requirements and design?

The best approach seems to be specify and close the interface with the plug-in subsystem in the main system and afterwards develop each new subsystem independently.
The bad point of this procedure is that it can lead of loads of documentation since you need requirements and design documentation for each new plug-in.

The good point is that the system is completely isolated by analysis, and obviously design, of each subsystem which increase cohesion and encapsulation, decrease coupling and produce a cleaner product.

6 thoughts on “Modelling a Plugin System

  1. How about just setting the interfaces for such extensibility. The first thing to do is to define the aspects which are going to be extensible, after that just establish a contract which defines what the system requires from the plug in.

    Most certainly this kind of extensibility has to be established and defined in the analysis and design phase.

    Now regarding documentation, that is just the nature of software architecture and development. We need to document what we do. If those subsystems were not developed as plugins, they still have to be documented. So I don’t think that is a bad point against plug in architectures, it is just the nature of development.

  2. Hey! Having feedback from community is a very nice feeling 🙂

    I agree with you that software == documentation, and that’s not a bad point at all. I just find it a pia, having e.g. 5 documents to describe a whole plug-in system, but it it is just my point of view.

    I don’t get your point of aspects extensibility, could you explain yourself better?

    Thank’s a lot 🙂

  3. Yep, I agree documentation sucks, that is why Software Factories seems so interesting…anyways…sorry for not explaining myself correctly, but English is my second language and sometimes I use words that I shouldn’t.

    What I meant with ‘aspects extensibility’ I meant: what parts/features of the software are going to be extensible.

    For example let’s say you want to make a feature which parses files. You can make the File Parser aspect of the application extensible or interchangeable (maybe following an Strategy pattern). One plug in for PDF files and another for the DOC files.

  4. I think I got your point, but I do not agree. After you design and develop the system you shuldn’t go to it everytime you need to add a new plug-in system, it should somehow be able to pass message through a well-defined API which will not change.

    Of course you can use stratage pattern or whatever you like more for achiving a plug-in system but if you are creating a new plug-in to store documents in PDF format you should just develop the subsystem from the given API e.g. “newDoc()”, “title()”, “author()”, “sign()” and so on.

    You should not allow to extend this API since otherwise the point of having a plug-in system is blurred.

    If I have not got your point you can turn into spanish and try it again 🙂

  5. I think you misunderstood me…. but it is ok. Because what you just described is exactly what I had in mind.

    What I meant was that you need to decide what parts can be extensible, for example the Parser mechanism: PDF or DOC. Not extend the PDF mechanism, but the parser mechanism.

Comments are closed.