Attributes or Properties

Question

I want to add some functionality to every module/plugin written such as:

Author, Company, Date, etc

that represents where it's coming from and who wrote it. Then the programmer could have multiple plugins in a single DLL. How should I implement support for these so I can access them in the main application UI? Generally 1 plugin is a single public class.

Should I use Properties or attributes? Also should I use interfaces?

I want these things to be filled by the programmer, and not make it optional.

Answer 1

I would use an interface, myself. nice thing is, you can add it to an existing class and not have to do a major re-write of existing code, just add the properties/methods of your interface.

Answer 2

Personally, I would go for attributes, but would assign the value to a backing read-only property in the constructor.

Best of both worlds. :)

Answer 3

If you use attributes, that would make it harder for plugin implementers to notice if they forgot to fill in one of the fields. With an abstract property, they would be forced to implement it or face compile errors:

public abstract class PluginBase
{
    protected PluginBase()
    {
    }

    public abstract string Author
    {
        get;
    }

    // ...
}

The only downside is that this kind of information is really metadata, so you could argue that attributes look better from a "semantically correct" perspective.

Answer 4

I'd go for attributes, just because it sounds like the items you wish to track don't need to be part of the application, but rather adornments to the code itself.

Also, I think the temptation of programmers to add other junk to this that doesn't really belong would be lesser if it were an attribute.

Answer 5

I think using an interface is a better approach. Because either way every one who wants to write a plugin should do it based on a contract (implementing an interface or putting some attributes over his class members) so it doesn't matter from the plugin developer point of view , but it would be easier ,more structured (and I think faster) for your program to recognize and utilize an implemented class based on an interface.

Answer 6

Since the data is technically metadata about the class, and not actual state required by the plugin, I would use attributes. Attributes are intended to be metadata about the code, which is what you want.

As far as enforcing them, you could have the host application fail to load the plugin if the metadata was missing. That way, the plugin developer would not be able to test the plugin without providing the data. However, you should provide ample documentation so they know what they are missing, or provide detailed errors when you fail to load the plugin.

Most assemblies already have some basic information (Company, Version, etc.) that is set in the AssemblyInfo class. You could also possibly leverage this instead as well.

Also, to prevent the missing data problem, you could use a single PluginAttribute that took all the metadata in as parameters on the property, and require that attribute for your host to load the class. I was initially thinking one attribute per item you wanted to record, but a single attribute would work even better.

Answer 7

There are already attributs for that, so why reinvent the wheel?

using System.Reflection;

[assembly: AssemblyTitle("my app")]
[assembly: AssemblyDescription("good app")]
[assembly: AssemblyConfiguration("")]
[assembly: AssemblyCompany("mycorp")]
[assembly: AssemblyProduct("my prod")]
[assembly: AssemblyCopyright("Copyright © me 2009")]
[assembly: AssemblyTrademark("")]
[assembly: AssemblyCulture("")]
[assembly: AssemblyVersion("1.0.0.0")]

Per default they are already present in the file AssemblyInfo.cs.

This is the standard way for storing version information and other metadata in assemblies. Maybe there are other Attributes also of interest for you, you also can create your own Attributes for that.