Sometimes it can be difficult to predict all the required functionality for an application, beyond a core set of features. This may be because:
- It is anticipated that new features may need to be added over time as requirements change.
- Different users of the application have different requirements. Providing all the required features to all users would result in an overly complex system and user interface.
- It is anticipated that some users will want to develop their own functionality for the system, tailoring it’s features to suit their personal needs.
- The application will run on a variety of different platforms, some of which will not be able to support all the application’s functionality, or will do so in different ways.
A plugin architecture provides a flexible mechanism for extending the functionality of a software system. In the pattern, an application is able to dynamically search for and load components that contain additional functionality into the main system.
Plugin Abstract
The diagram illustrates the key components in the plugin architectural pattern. The main component in the in architecture is the Registry that stores the specification of all plugins available to the system. A plugin component normally provides a standard interface that complies with the requirements of the plugin architecture. This can provide:
- details of how to instantiate the plugin in the application;
- details of how the component can be used in the application.
The main Application can query the registry for available plugin specifications of a particular type. When an appropriate plugin is located, a Loader component is used to instantiate and configure the component for use by the main application, using the specification supplied by the Registry. The plugin’s functionality can then be accessed via the specified interface, just like any other component in the system.
A plugin architecture is similar to a software framework that exhibits hooks and slots. However, the purpose of the two are different: A software framework is not an application. It is a collection of utilities, libraries and infrastructures for building applications in a particular architectural style, or for a particular purpose
How Flexible Should A Plugin Arch Be?
A plugin architecture is useful for extending the functionality of a specific application, not for building the whole application.
Consequently, the range of ways in which a plugin can extend the application’s functionality and purpose should be tightly constrained. An application that is built purely from plugins is in serious danger of exhibiting the inner platform effect. Another way of expressing this is to observe that this process simply re-invents the Java language’s primitive mechanism of instantiating classes as objects using the new keyword.
To a certain extent this is correct, except that the programmer does not need to know what class will be instantiated as a plugin at runtime. In addition, creating an instance via the newInstance method is computationally much more expensive.
So, it is important to choose which classes will be implemented as plugins because they are better suited to being loosely coupled components, and which are core parts of the main application.