使用类（而不是接口）来设置插件机制是否不正确？

Question

Assume this hypothetical situation: I have a hierarchy of classes:

public class MyBase : System.Windows.Forms.TreeNode 
{ 
    public virtual void Init() {...} 
}

Now I want to allow third parties to use MyBase to develop their derived classes like these:

public class Drv1 : MyBase { public override void Init() {...} }
public class Drv2 : MyBase { public override void Init() {...} }

I want my application be able to use Drv1 and Drv2 as plug-ins.

Now, my questions are:

1. Is it incorrect (or bad practice) to use classes (instead of interfaces) to set up plug-in mechanism?

2. Did I make a mistake I didn't use interfaces to provide THIRD-PARTIES with an interface ? (because I want to persuade others to develop plug-ins for my app)

3. If answer of question 2 is YES, how could I use interfaces (because MyBase is derived from TreeNode) ? (this answer is critical for me)

Many thanks in advance.

Answer 1

Im using following rules:

If there is any code required in base then go for class .

---

If you need only structure or you need to "inherit" more than one class , use interfaces .

---

If you need both, features and multiple inheritance use both.

---

Its really depends what you do with that classes later on.

In your case you should be using base class as virtual method has some code in it, and you inherit from class that is 3rd party for you.

But once your business classes should use different implementation of that class then its worth of adding interfaces and use it in IoC or something.

I think going for Interfaces for only sake of it is not correct approach.

Answer 2

Is it incorrect (or bad practice) to use classes (instead of interfaces) to set up plug-in mechanism?

Neither C# or .NET has anything that labels this as incorrect. They describe under what circumstances your code will continue to work, and when it won't. Bad practice is a matter of opinion, but there are advantages and disadvantages to both approaches.

If answer of question 2 is YES, how could I use interfaces (because MyBase is derived from TreeNode) ? (this answer is critical for me)

If your callers need to provide a type that is derived from TreeNode , and you wish to use an interface, then you can.

public interface IMyInterface {
    void Init() {...}
}

You cannot require classes implementing IMyInterface to derive from TreeNode , but you do not need to: you can ensure that the only way this gets exposed to your own application is via a generic registration method, where the generic type constraints do force the type to both derive from TreeNode and implement this interface:

public void RegisterTreeNode<T>() where T : TreeNode, IMyInterface {...}

If plugins are able to call RegisterTreeNode<Drv1>() , you're assured at compile time that it's going to match your requirements. You may of course use a different method signature, possibly one that deals with individual instances of the TreeNode class, it's the type constraints that are key here. If a caller attempts

class X : IMyInterface { public void Init() {...} }

and then

RegisterTreeNode<X>();

the compiler will simply reject this. The plugin may create instances of this X itself, but if your application never sees them, they cannot cause any harm.

Then third parties can do:

public class Drv1 : TreeNode, IMyInterface { ... }
public class Drv2 : TreeNode, IMyInterface { ... }

or even

public class Drv3 : SuperTreeNode, IMyInterface { ... }

where SuperTreeNode is derived from the standard TreeNode .

This is probably the main benefit of using an interface here: it's compatible with existing classes which provide additional functionality on top of the standard TreeNode .

This cuts both ways: the main benefit of using a common base class here, rather than an interface, would be that your own code can provide additional functionality.

PS: Depending on what you're after, it may also be possible to decouple this, to make your base class / interface responsible for creating TreeNode objects, rather than deriving from TreeNode . The general rule that favours this approach is called "composition over inheritance", and worth reading up on. It may or may not be a good fit for your particular use case.