Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question
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. – svick Sep 30 '12 at 7:54
1  
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. – tdammers Sep 30 '12 at 11:20

3 Answers

up vote 3 down vote accepted

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;
}

public class ToyCar : Car , IToyCarResistance
{
}
share|improve this answer
1  
You can't have fields in interfaces, so ToleranceLevel would probably be a get property. – George Duckett Sep 30 '12 at 10:53

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.

share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.