Abstract class + Inheritance vs Interface

Question

Hello fellow programmers,

I am reading a book on C# and the author is comparing Abstract classes and Interfaces. He claims that if you have the following "abstract class:"

abstract class CloneableType
{
public abstract object Clone();
}

Then you cannot do this:

public class MiniVan : Car, CloneableType
{}

This, I understand. However he claims that because of this inability to do multiple inheritance that you should use an interface for CloneableType, like so:

public interface ICloneable
{
object Clone();
}

My question is, isn't this somewhat misleading, because you can create an abstract class which is "above" class Car with the method Clone, then have Car inherit that class and then Minivan will inherit Car with all these methods, CloneAble class -> Car class -> Minivan Class.

What do you think? Thanks.

• svick: Not directly related to your question, but having ICloneable like this is usually not a good idea. You would end up casting the result anyways, so there is no reason to use an interface (or abstract class) here.
• tdammers: Note that both approaches are in fact wrong here; you don't want a class MiniVan than inherits from Car; instead, you want a class Vehicle, with properties of types Chassis, Wheel, Engine, etc., and make those polymorphic. This is known as Composition, and you should favor code reuse through composition over code reuse through inheritance whenever possible.
• Job: One thing that is really cool about interfaces is that methods can accept them as parameter types. I do not have a great example, but it is very powerful. You can accept an IEnumerable interface type for a parameter and not have to care about the particular implementation. You cannot achieve the same with a class hierarchy - you will end up dragging a much bigger view into an object (if you will) than you actually need.

Answer 1

The difference between the abstract classes and interfaces in your case could allow the developer to well-define the pattern of your design with abstract class create "is a" relationship and interface create "can do" relationship.

Put it this way, if you have a Toy car and it would be not make sense to make them "is a" relationship with Minivan since you can use interface to exhibit toy car specific behaviour like water resistance tolerance.

So you can define like:

public Interface IToyCarResistance
{
 int ToleranceLevel { get; }
}
public class ToyCar : Car , IToyCarResistance
{
}

• George Duckett: You can't have fields in interfaces, so ToleranceLevel would probably be a get property.

Answer 2

The idea that the author is trying to emphasize is that designing an abstract class instead of an interface limits your ability to mix and match that class with other parts of your system later on. This is a tradeoff between an ability to share an implementation in exchange for inability to combine multiple abstract classes later on.

Answer 3

Short Answer: Author is just emphasizing that a class may inherit only from one, and ONLY one Base class. However, it may have as many Interfaces as needed. This is true for C#, VB.NET languages.

However, you may have set of classes that inherit one from another. You may also build change inheritance, which should be carefully designed, and better to be avoided.

Long story short, interfaces are very handy to propagate common behaviors (actions like Create, Update, Delete, etc..) to classes.

Answer 4

Abstract classes are used to "Setup" any class that is inherited from it, meaning that it can have default implementations of its properties and methods that all derived classes would then inherit. So for example if a derived class will inherit the startEngine default implementation, but not necessarily need to implement its own version, it can use its own version of the base class startEngine, and interface cannot have any completed methods, and would require you to define your own in every case. This allows in many cases better code re-usability, since the default implementation has all of the default methods and properties if you change something in your derived class it will not likely break previous code, where as with an interface, you have to go though and find all of the instances where the interface is being used and make the changes.

• gnat: this post is rather hard to read (wall of text). Would you mind editing it into a better shape?
• akousmata: "...where as with an interface, you have to go though and find all of the instances where the interface is being used and make the changes." You are completely missing the point of using interfaces.