C# Interfaces with a Constructor?

I recently had the chance to answer a five year old question on stack overflow with fresh insight from my own programming experiences.  The question basically went like this:

"It's weird that this is the first time I've bumped into this problem, but: How do you define a constructor in a C# interface?"

The technical answer is that you can't; defining a constructor on an Interface is not allowed in any programming language that I know of, definitely not in C#.  However there is a sneaky way to get the same desired behavior.

First though, the main reason why you can't have a constructor defined on an Interface is because it would create quite a problem for the compiler if you had a class that inherited from multiple interfaces and each interface had its own constructor defined.  Which one would be called?  Would they all be called?  What if you want to bypass all of them and use your own constructor in the calling class?  There are other theoretical problems as well, such as the separation of behavior and implementation (Interfaces define behavior, how they get implemented is up to the class that uses them).

The accepted solution for this particular stack overflow question had been a suggestion of using an abstract class instead of an interface; since abstract classes allow the definition of a constructor.  This is a perfectly acceptable solution but we can actually do better than this.

Must Initialize

I'm going to call this coding pattern the MustInitialize pattern, for lack of a better term.  It's easiest to explain this pattern by giving you an example.

Let's say you have an existing interface that looks like this:

public interface ICustomer
{
    void Update();
    void Search();
}

This is a simple example with only two methods, but for argument's sake, imagine there are, say, fifteen methods defined on this interface.  And to make matters worse, imagine that each method on the interface requires a user authentication token.  You would have to modify the interface so that each method would take a user token as a parameter.  You certainly could modify each method in this way described and your code would work just fine.  However it would look a little cluttered and it would be hard to enforce to future developers that any new methods must also take a user authentication token as a parameter.

This is where the MustInitialize pattern comes in very handy.  Keep in mind though that this is not a silver-bullet solution and there is one caveat that can cause this pattern to fail which I'll discuss at the end.

The next step in the MustInitialize pattern is to create an abstract class that utilizes generic types in C#.  It will look something like this:

public abstract class MustInitialize<T>
{
    public MustInitialize(T parameters)
    {

    }
}

Next we're going to take this abstract class and inherit from both it and our ICustomer interface in our actual Customer class:

public class Customer : MustInitialize<UserAuthToken>, ICustomer
{
  UserAuthToken _token;

  public Customer(UserAuthToken token)
    : base (token)
  {
    _token = token;
  }

  public void Update()
  {
    //use _token here to do our update logic
  }

  public void Search()
  {
    //use _token here to do our search logic
  }
}

The "magic" here is that our abstract class which we inherited from defines a mandatory constructor that accepts one parameter of type "T" that we are free to define on our own.  In this case it is a UserAuthToken but it could be any C# type or class that we want to use.

Now all that is left to do is create an instance of the Customer class and use it like we normally would:

ICustomer customerService = new Customer(myUserAuthToken);

The cool thing here is that the customerService class still behaves just like a plain old implementation of the ICustomer interface, like we would expect; in other words, we don't even have to know about the MustInitialize abstract class.

The caveat:

If you are using a class that already inherits from another class, you won't be able to use this pattern in C# because multiple class inheritance is not allowed.  For example, maybe our Customer class already inherits from some class like Entity.  In that case we would have to use a different design pattern or if we had access to modify the Entity class we could make it implement the MustItitialize pattern.  Like I said, it's not a silver bullet solution but it works well in straight forward situations where an interface would normally require you to pass the same parameters over and over again to each method.

Link to the original Stack Overflow question/answer