Can an interface define the signature of a c#-constructor

Question

I have a .net-app that provides a mechanism to extend the app with plugins. Each plugin must implement a plugin-interface and must provide furthermore a constructor that receives one parameter (a resource context).

During the instantiation of the plugin-class I look via reflection, if the needed constructor exists and if yes, I instantiate the class (via Reflection). If the constructor does not exists, I throw an exception that says that the plugin not could be created, because the desired constructor is not available.

My question is, if there is a way to declare the signature of a constructor in the plugin-interface so that everyone that implements the plugin-interface must also provide a constructor with the desired signature. This would ease the creation of plugins.

I don’t think that such a possibility exists because I think such a feature falls not in the main purpose for what interfaces were designed for but perhaps someone knows a statement that does this, something like:

public interface IPlugin {
    ctor(IResourceContext resourceContext);
    int AnotherPluginFunction();
}

I want to add that I don't want to change the constructor to be parameterless and then set the resource-context through a property, because this will make the creation of plugins much more complicated. The persons that write plugins are not persons with deep programming experience. The plugins are used to calculate statistical data that will be visualized by the app.

---

Thanks for all the answers.

I’ve decided, that I let it be an interface because I don’t like to force the plugin-programmers to inherit from an abstract class so that he or she loses the possibility to inherit from an own base-class. Furthermore, deriving from an abstract class does not ensure that the plugin programmer really provides the needed constructor. It makes it only more probable (The programmer has still the possibility to add only one constructor that contains the desired parameter but that also has additional parameters, and that’s also bad. See the comments to the answer of Ken Browning).

Although I mentioned in my post that I don’t want such a property, I marked the answer of Danny Varod as accepted because I think in my situation it’s the most appropriate solution. Thanks to all who answered.

Answer 1

Interfaces cannot declare constructors. You might consider using an abstract class instead.

Answer 2

Plug-in extendability is a favorite of mine...

What I do is make sure the plug-in either implements the interface or inherits the base class of the appropriate "plugin socket".

In some places base classes are more appropriate (if the plug-in is a kind of X),
in some interfaces are more appropriate (if the plug-in does IX).

I do not pass the context to the construct, instead I use a property for that and a parameterless public constructor.

This also enables easier deserialization of plug-ins using reflection.

Answer 3

No, this does not exist. You are probably looking for an abstract class here.

Answer 4

Alternatively, you might try using a factory: make the constructor signature a method signature of another type:

public abstract class PluginFactory
{
    public abstract IPlugin Create(IResourceContext context);
}

and then something like (and I always mess up this part if I want it to be short, hence the edit):

public class PluginContainer
{
    public IPlugin LoadPlugin<T>(IResourceContext context) where T: PluginFactory, new()
    {
        var factory = new T();
        return factory.Create(context);
    }
}

Answer 5

Unfortunately, interfaces in C# can only contain methods, properties, events or indexers.

You could use and abstract class that all plugins would inherit from. You'd be able to force them to implement the constructor signature in that case.

Answer 6

The interface can't declare / enforce a constructor.

Define the interface and create an abstract base class that provides the most likely implementation of the constructor -- probably just saving the resource context passed in.

Encourage, but don't require, plugin authors to derive from the base class. There may be other useful methods that the base class could also provide.

Continue to use reflection to check the plugins.

Answer 7

As others have alluded to, using an abstract class to take care of the plumbing details is a common pattern for what you're trying to accomplish. Here is one design that avoids the need for a constructor with special parameters if the consumer inherits from the abstract base class Plugin:

public interface IPlugin
{
    void Initialize(IResourceContext context);    

    //Other methods...
}

public abstract class Plugin : IPlugin
{
    protected IResourceContext Context { get; private set; }

    void IPlugin.Initialize(IResourceContext context)
    {
        Context = context;
    }

    //Abstract declaration of other methods...
}

Your code has to call Initialize behind the scenes after creating the Plugin, but this detail is hidden from typical users, as they generally don't have to implement IPlugin directly. Your typical user can just define a Plugin descendant and work with the Context property.

You might also want to look into various dependency injection frameworks (such as Ninject), though they're probably overkill for what you're doing. Still, looking at how they work may give you some ideas on different ways dependency injection can be managed.