Plug-In 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 { … } • How does the application know when to use our plug-in class? • How can the application instantiate our plug-in class? • It doesn’t know the class name to call “new” on (PerlSyntaxHighlighter) • At installation time, a new plug-in has to “register” with the application • Example

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 • Registration techniques • Just copy the plug-in DLL into a special directory. The host application loads all DLLs in the plug-in directory, and queries each DLL for information about its plug-in • Installer puts an entry in a configuration file that indicates where the plug-in DLL is located

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 uses reflection to instantiate plug-in classes by name, which causes the classes to be loaded into the VM

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 (crashes, memory leaks, etc.)