This project has moved and is read-only. For the latest updates, please go here.

How can we avoid redundant interface/contract implementation in plug-ins?

Apr 30, 2011 at 12:12 PM

I have a design question for the geeks. We are trying to implement MEF in our application to support plugged-in objects that derive from some predefined contracts. I shall present a hypothetical situation.

There are a couple of interfaces required by my application to make an object usable. Let’s say they are;

  1. IAdult.cs, with two properties
    1. Age
    2. LicenceNo.
  2. IEducated.cs, with two methods
    1. Read()
    2. Write()

Now these are the contracts that the exportable objects shall derive from. If we had to implement an abstract class out of these interfaces, we could simply create a class, say, abstract class EducatedAdult{}. Let’s assume that the implementation of these interfaces shall remain the same most of the times.

Now we define three different objects with their own respective inheritances and a set of respective properties;

  1. Carpenter.cs (derives from class A)
  2. Plumber.cs (derives from class B)
  3. Programmer.cs (derives from class C)

(Here class A, B, C belong to an external library). These are the classes that shall be imported into the host application. To make these objects usable in the Program (and of course, to import them), they need to implement the above given interfaces. So the issue is that for each one of these classes, I’ll have to explicitly implement the above stated interfaces - redundantly. Could there be a better design where I do not have to implement the interfaces with the same code in all the classes?

May 1, 2011 at 1:14 PM

This looks like the most suitable solution for me (solution 3 by Nishant, on the link page below);