Inheritance design using Interface + abstract class. Good practice?

Answer 1

Well, that's what the where keyword is for. You probably need to evaluate your object model to make sure that the depth of your inheritance is necessary. Deep inheritance hierarchies tend to complicate projects and are generally a red flag, but it depends on the situation.

Usually, you don't need the abstract class to pull off the functionality you're talking about with the lists, and interfaces are the 'preferred' method for specifying type restrictions. I'd only use the abstract version of your class if there is common functionality you want to encapsulate.

Short answer: make sure you're not going inheritance crazy.

Hope that helps!

Answer 2

You could also just use interfaces. There is no reason to use an abstract class.

public interface Foo : IFoo
{
}

 public interface  Bar : IFoo
{
}

Answer 3

I am not quite sure if this is what you are looking for but perhaps what you want to do is scrap the interface all together and do this:

abstract class Base
{
    public abstract string ToCMD();
}

abstract class Foo : Base { }

abstract class Bar : Base { }

Hopefully you have other members in the Foo and Bar classes! This will allow you to either restrict your custom collection by Base or just use a plain List<Base>.

Answer 4

you need the interface; you may or may not need the abstract class.

in general, if you can provide some useful behavior in a base class, then provide a base class; if the base class is not complete by itself then make it abstract (MustInherit in VB parlance)

otherwise, the interface is sufficient

Answer 5

The need for an inheritance chain is questionable, in general.

However the specific scenario of combining an abstract base class with an interface.. I see it this way:

If you have an abstract base class like this, you should also have a corresponding interface. If you have an interface, then use the abstract base class only where the inheritance chain is sensible.

That said, if I'm writing a library and this is part of my API/Framework, I will generally include a "default implementation" that can be used as a base class. It will implement the interface methods in a naive, general way, where possible, and leave the rest for inheritors to implement/override as needed.

This is just a convenience feature of the library though, to assist people who want to implement the interface by providing a functional example that may cover most of what they need to implement already.

In short, the interface is more valuable than the base class, but a base class might save a lot of time and reduce buggy interface implementations.