Question

I’ve made an application that supports plugins. At the moment, the plugin’s base class implements an abstract class and supplies it with the name of the plugin (stuff omitted):

public class AppExecutePlugin : APlugin
{
    public AppExecutePlugin() : base("Application Execute")
    {

    }
    ... (other stuff here)
}

Now, I am thinking of naming plugins using custom attributes as so (don’t care about syntactical errors):

[PluginName("Application Execute")]
public class AppExecutePlugin : APlugin
{
    public AppExecutePlugin()
    {

    }
}

Since I rarely use attributes for my own apps, I would like to know whether the second approach will lead to more abstract implementation or in general if it has pros comparing to my first approach.

Answer 1

It will not lead to more abstract implementation (as it is hard to evaluate how this affects ‘abstractness’), but it has a few benefits:

• you don’t need to instantiate plugins in order to read metadata – you can just read the attribute info using reflection
• plugin instances don’t need to add state (i.e. members) just for the sake of having metadata
• you can easily add additional attributes, or extend this one, without polluting the plugin interface

E.g. my plugins look like this:

[Plugin("FriendlyName", Description = "..", Version = "1.0")]
[RequiresLicense("LicKey.XYZ")]
class MyPlugin : PluginBase {...}

Without attributes, I would need to add all of this info to base class constructor. Of course, you could always avoid it by having a method in your plugin interface like this:

public static PluginInfo GetPluginInfo()
{
   return new PluginInfo() { Name = "FriendlyName",
                             Description = "..", 
                             Version = "1.0",
                             License = "lickey.XYZ" };
}

You could execute it using reflection without instantiating the plugins, thus achieving the same as with attributes. I prefer attributes to this approach, as it feels a bit more declarative, but that might easily be just personal taste.