Take the 2-minute tour ×
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.

Let's say we have an abstract class and let this class has only abstract methods. Is this abstract class different from an interface that has same methods only?

What I am looking to know is if there are any differences both philosophically, objectively and in the underlying programming language implementation between an Abstract Class with only abstract members and an equivalent Interface?

share|improve this question
    
which language? –  kevin cline Apr 19 '13 at 14:02
    
as far as I can tell, your question is answered in duplicate twice: here and here. And these two answers are language agnostic, nothing specific for C# there –  gnat Apr 19 '13 at 14:04
2  
@blank I disagreed with the Duplicate status applied to your question so I reopened it. Further I edited your question to further clarify what I believe you are asking. –  maple_shaft Apr 19 '13 at 18:11
    
@maple_shaft I appreciate that. –  blank Apr 19 '13 at 19:29
add comment

6 Answers

up vote 17 down vote accepted

Technically, the differences aren't really significant but, conceptually, they are entirely different things and that leads to the technical differences others have mentioned.

An abstract superclass is exactly what it sounds like, it's a common type that is shared by many other types, like Cats and Dogs are Animals.

An interface is also exactly what it sounds like, it's an interface through which other classes can communicate with the object. If you want to make a Cat Walk, you're ok, cause Cat implements a CanWalk interface. Same for a Lizard, though they walk very differently. A Snake, on the other hand, does not implement CanWalk, so you can't tell it to Walk. Meanwhile, Lizard and Snake (or possibly more explicit subclasses -- I'm not an expert) might both shed their skin, and thus implement CanShed, while a Cat couldn't do that.

But they're all still Animals and have some common properties, like whether they're alive or dead.

This is why all methods on an interface must be implemented as public (or explicitly, in C#). Cause what's the point in an interface that's hidden from the class interfacing with the object? It's also why you can have multiple interfaces to an object, even when a language doesn't support multiple inheritance.

To go back to your question, when you look at it this way, there's very rarely a reason to have an entirely abstract superclass.

share|improve this answer
4  
+1, although cats shed in a much more annoying way than either snakes or lizards. –  Matthew Flynn Apr 19 '13 at 21:01
add comment

In most OOP languages, an implementing class can derive only from one abstract class, but implement multiple interfaces.

share|improve this answer
3  
most? which ones are you counting? Most OOP languages I know don't have interfaces or abstract classes. C++ has only abstract classes. –  kevin cline Apr 19 '13 at 14:03
10  
@kevincline: probably C#, Java, and VB.NET. –  tdammers Apr 19 '13 at 14:20
1  
@kevincline, I think there is just a "having both" lacking. IIRC, in Ada the motivation for interface was that one, the designers didn't want a general multiple inheritance feature but the special case of interface was deemed too important not to be provided. –  AProgrammer Apr 19 '13 at 14:29
    
@tdammers: LOL. That was a joke, right? –  kevin cline Apr 19 '13 at 19:34
add comment

In a language like C++ that allows multiple inheritance, and has no interfaces, abstract classes in which all methods are abstract can serve as interfaces. I haven't worked with C++ that much, but I guess multiple inheritance can cause problems when there are methods with the same name in base classes.

In languages like PHP and C#, interfaces provide a means of achieving similar polymorphism, although I dislike calling it "inheritance" since there's a conceptual difference between inheriting an abstract class and implementing an interface. Interfaces remove the conflict problem, because they themselves provide no implementation.

An interface serves as a contract to the outside world, while an abstract class can provide an implementation, although if used to "fake" an interface, it most likely won't.

The main conceptual difference is that when a class inherits another class (abstract or not), there's a relationship of "is", so a Car is a Vehicle and Dog is an Animal. With an interface, it's what the object does that matters. So both Car and Dog can Move() and the consumer knows it because they implement Movable, but a Car is definitely not a Dog, or an Animal. And the move implementation will be different (wheels vs legs) but the consuming code doesn't and shouldn't care. Interfaces are all about the consuming code, rather than the implementation.

The main point is if you have interfaces in you language of choice, use them for things that they're there for. If not (like in C++), you can fake them by using pure abstract classes.

share|improve this answer
    
Interface is a type as well, so you could have an IAnimal which both Dog and Cat are. –  Amy Blankenship Apr 25 '13 at 21:33
    
You could, but in my opinion, interfaces are about behavior that is exposed to the outside world, and not so much about what the objects are. Inheritance implies that something is a type of something else (Cat is an Animal). An interface just says what that object can do. That's why i like to say that something "implements" rather than "inherits from" an interface, which is what most .Net people I've worked with would say (i guess because the syntax is the same for inheritance and implementation). –  Pinetree Apr 26 '13 at 7:47
add comment

Abstract classes may feature abstract protected methods (in the languages I'm working with), in interfaces methods are usually always public. Whether this difference allows useful exploitations I don't know.

Edit I first thought that a private abstract method is of no use, but now I recalled that it may be used to ensure that that method is never called. This way you can prevent that a copy constructor of an object is called.

share|improve this answer
1  
Protected virtual (override-able) methods can be useful for classes that are part of a framework or something like that. That way they ensure that the custom code in a class that inherits the abstract provides that functionality. Though this can also be achieved by inheriting an interface on the base class but not actually implementing its methods –  Pinetree Apr 19 '13 at 13:02
    
Yes, I was thinking about something like that, but don't have any experience with it, so could not judge. Thanks for the input. –  Thomas Apr 19 '13 at 13:07
add comment

Yes, they are different. Otherwise the language designers wouldn't have provided both. I know of two languages that separate classes and interfaces: Java and C#, mutant clone of Java. The designers created interfaces to avoid supporting multiple class inheritance. Most other languages support multiple class inheritance and consequently don't separate classes and interfaces.

share|improve this answer
add comment

I think the main difference is that : In an abstract class - even if all the methods are all abstract they can still provide data members (instance variables) and some code to the classes that implement it (in form of private methods or constructors), static blocks; doing part of the work for the sub classes and helping them with the implementation.

One positive side effect : code is in one place so one place to make corrections. sub classes can just call super class method and then do something else or nothing if super class actions are enough for their case. Super class wants each sub class to make this decision so has marked all its implementation as abstract (some could be empty too)

Not relevant to question: but having interfaces means one class can implement two different contracts. So that is an advantage of a interface over a abstract super class

share|improve this answer
1  
Aren't abstract methods defined without any implementation, and leave the implementation to the inheriting classes? –  Pinetree Apr 19 '13 at 13:12
    
yes your right then i guess its just the variables, constructors and static & private methods if you count those –  tgkprog Apr 19 '13 at 13:22
    
@Pinetree, in practice most of the time you'll want at least a little "real" code in your Abstract Classes (at least in the language I use, which doesn't have a special construct for Abstract Classes). –  Amy Blankenship Apr 25 '13 at 21:36
    
@AmyBlankenship yes, most of the time abstract classes do have "real" code (that's what they're there for). But I was referring to abstract methods, within the context of a purely abstract class that serves as an interface in a language like C++, which does not have interfaces. –  Pinetree Apr 26 '13 at 7:42
add comment

protected by maple_shaft Apr 19 '13 at 18:09

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

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