PlugIn Architecture Pattern

1
Plug-In Architecture Pattern
2
Problem

• The functionality of a system needs to be
  extended after the software is shipped
• The set of possible post-shipment extensions is
  large
• Specific details on future extensions are not
  available, but their general nature is
  predictable
• It should be possible to extend the system
  without access to the system's source code, by
  people who were not the system's original
  developers
• It should be easy to add and remove extensions in
  whatever combination is desired by the customer

3
Example Syntax Highlighting

• You are writing a text editor intended for use by
  software developers
• You want to support syntax highlighting, but the
  set of possible programming languages is
  unbounded
• Even if you could list all of the possible
  languages, you don't have enough resources to
  implement syntax highlighting for them all
• Third-party developers and end-users will need
  the ability to add syntax highlighting for their
  favorite languages without your help

4
Solution

• Define an abstract interface that captures the
  general nature of the necessary extensions
• interface ISyntaxHighlighter
• Extensions are components that implement the
  abstract interface
• class PerlSyntaxHighlighter implements
  ISyntaxHighlighter
• When extensions are installed, they register with
  the system by providing
• A description of when the system should use the
  extension
• "Use me on files with a .pl extension"
• A way to instantiate the extension component
• A replacement for calling "new"

5
Solution

• Extensions are called "plug-ins" because they can
  be "plugged in" to the system without
  recompilation
• The system instantiates plug-in components
  indirectly through a registry
• The system invokes plug-in functionality through
  an abstract interface

6
Solution
7
Dynamic Behavior Plug-in Registration
8
Dynamic Behavior Plug-in Selection and
Execution
9
Dynamic Behavior Plug-in Un-registration
10
Implementation

• Plug-ins are frequently implemented as
  dynamically-linked libraries
• The host application loads the plug-in DLLs that
  have been registered, and queries them for
  factory and type information
• Registration techniques
• Just copy the plug-in DLL into a directory. Host
  application loads all DLLs in the plug-in
  directory
• Installer puts an entry in a registration
  database that indicates where the plug-in DLL is
  located and type information
• Windows registry, Configuration file

11
Implementation

• In Java a plug-in could be a .class file
  containing the plug-in class
• Registration could be as simple as putting the
  name of the plug-in class in a configuration file
  
• The host application loads the plug-in classes
  listed in the configuration file, and queries
  them for factory and type information

12
Known Uses

• Web browser plug-ins for different file formats
• PDF, PowerPoint, Word, etc.
• Web servers
• Apache Modules
• SSL, user authentication, caching, logging, etc.
• IIS ISAPI Extensions
• MS-Windows compound documents
• "Insert Object" menu in many Windows applications

13
Known Uses

• Syntax Highlighting
• Eclipse
• Framework for building integrated development
  environments (IDEs)
• Provides basic shell for IDE UI
• All actual work is done by plug-ins for specific
  development tasks
• Editors, compilers, debuggers, wizards
• Database drivers
• Generic database APIs ODBC, JDBC
• Plug-in drivers for specific DBs SqlServer,
  MySQL, Postgres, etc.

14
Consequences

• Results in a system that can be extended
• After it's shipped
• By people other than the original developers
• Without recompiling the system
• Users are free to choose which plug-ins they want
  to install
• Commercial opportunities for third-party plug-in
  developers
• Buggy plug-ins can destabilize the system since
  they're usually loaded directly into the host
  application process (crash, memory leaks, etc.)