Concepts

Patterns

Pattern: Plug-In

Factor out functionality, and place it in a separate component that is activated at run time. This component is called a Plug-In. The application defines functionality that it does not provide itself, but must be added by Plug-Ins. The application is shipped with a well defined interface for Plug-Ins (Plug-In Contract).

A Plug-In consists of executable code that the application loadsdynamically at run time. Each Plug-In complies with the defined interface. The application does not depend on a Plug-In internals, and often not on the presence of a particular Plug-In kind. Plug-Ins can be used to factor out essential functionality. In this case the presence of a particular Plug-In is required, and the application is always shipped with that Plug-In.

„Plug-In kind“ - different Plug-Ins are of the same kind when they conform to the same predefined interface. The OO analogon would be a superclass.

„Plug-In type“ - the Plug-In implementation denotes the type. The OO analogon would be a derived class.

„Plug-In instance“ - a currently active Plug-In. The OO analogon would be a class instance.

 Pattern: Plug-In Contract

Publish the interface the Plug-In is expected to fulfill, and the interface offered to it. The Plug-In uses not only system services, but application services as well. Also the expected Plug-In functionality requires a custom interface. The figure shows the major components, and their dependencies.

Plug-In Definition is the interface the framework requires from the Plug-In. The Plug-In is modeled as one or several abstract classes, together with their respective abstract factories or factory methods.

Plug-In adds specific knowledge to the application. It offers a factory or method that returns classes conforming to the expected interface. The internal implementation is hidden, and the visible class can serve as a Facade to it. The Plug-In may use services of the application, and must use the domain objects the framework provides.

Framework Interface defines the services and domain objects of the framework. Their implementation is hidden from the Plug-In by (abstract) factories, or product traders.

Implementation provides a process for execution, implements the framework services and domain objects, invokes the Framework Interface component, and activates the Plug-In by calling the factory and giving references to the framework objects.

All clients to the Plug-In can only access it through the Plug-In Definition component and interface, and the Plug-In can only access those instances and services published by the Framework Interface.

Pattern: Framework-Providing Application

The application offers a framework. This is a black box framework offering no insights in the host application, but defining opportunities for subclassing and parameterisation. Only part of the application is a framework. Other parts control loading and activating the Plug-Ins, or deal with completely unrelated stuff. Each interface for a Plug-In kind corresponds to a set of related „hot spots“.

Pattern: Plug-In RegistrationHow are the Plug-Ins known to the application?

The application defines a place where it looks for available Plug-Ins. Each Plug-In installs itself there.

Pattern: Plug-In Lifecycle

The application defines the life cycle of the Plug-In. The life cycle for a Plug-In instance contains loading, activation, deactivation, and unloading. The life cycle for a Plug-In type includes registration when Active Registration is chosen. The transitions correspond to member functions within the Plug-In Definition to allow the Plug-In to react.

Both cycles must be cleanly differed especially when registration is done in the Active variant manner and may occur during run time of the application. They may be merged when only one Plug-In instance per kind may be active at a time.

Pattern: Plug-In Package

Define and ship the functional extension as a package consisting of many files of many different types. The Plug-In interface consists of the custom Plug-In Definition classes, and a number of additional files. The central Plug-In is packed together with related executables, Plug-Ins, resource files, and „little helpers“. Application requests resources and „little helpers“ in standard formats.

To determine which files and file kinds to pack, start by identifying the functions throughout the life cycle, that the functional extension is expected to fulfil. Then try to find technical interfaces for these functions. Prefer technical standards of a long (expected) lifetime, and use custom Plug-In Definitions where necessary.

Pattern: One Plug-In per Task

Define a distinct Plug-In Definition for each distinct task or domain. Provide a common identifier so that the application can activate the appropriate counterpart.

This allows for extension specific data and classes added to the model. This data can only be added by an extension specific Plug-In, and be viewed by another extension-specific Plug-In. The application cares for the data exchange and processing in between, and ensures that the corresponding Plug-In gets in control on the viewing side. Each extension consists of one Plug-In type of each predefined Plug-In kind.

Configurable application domain objects need a reference to the extension identifier. The application must also ensure that distinct extensions come with distinct identifiers. The extension must ensure that no version conflicts between different Plug-Ins occur.

Avoid addressing all extension functionality through one interface - it would look like a swiss army knife. Separate into consistent domains (and employ further standard file formats, see Plug-In Package).