Game Development Reference
Designing a Common Interface
Each plugin is unique in terms of functionality, but there must be some common
elements between all plugins in order to load them with a generic framework, and
this is best accomplished through the use of interfaces. Interfaces are reference
types and contain only abstract members. Interfaces are, in essence, a contract, so
any classes implementing an interface are enforced to implement all members on
the interface. This means that an application only needs to know about the inter-
face in order to communicate with the class.
Information about classes can also be inspected with reflection, so we can use this
common interface's type to dynamically locate plugin classes within an assembly.
Classes that do not implement this common interface will not be loaded as plugins.
The common interface should be placed in a separate assembly so that the applica-
tion and the plugins can reference the interface as a shared assembly. You can even
go a step further by placing the shared assembly in the Global Assembly Cache so
that the application and plugins do not need local copies to compile or run.
The following code shows the common interface from the example for this chap-
ter. The two methods are used, respectively, to initialize and release plugin
resources. The actual implementation details for these two methods are left up to
the individual plugins.
public interface IPlugin
Embedding Plugin Metadata Information
A common feature of most plugin-aware applications is a plugin manager or
browser that can display a listing of all the plugins referenced by the application.
Some of these browsers go even further by showing information about each plug-
in to describe functionality and author credits.
The same functionality can easily be accomplished by decorating a plugin with an
attribute that describes what the plugin does.