10

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?

3
  • 1
    which language? Commented Apr 19, 2013 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
    Commented Apr 19, 2013 at 14:04
  • 3
    @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
    Commented Apr 19, 2013 at 18:11

6 Answers 6

22

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.

2
  • 4
    +1, although cats shed in a much more annoying way than either snakes or lizards. Commented Apr 19, 2013 at 21:01
  • Technically: Abstract methods can be made protected. Interface methods cant. Commented Mar 15, 2019 at 12:45
19

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

4
  • 3
    most? which ones are you counting? Most OOP languages I know don't have interfaces or abstract classes. C++ has only abstract classes. Commented Apr 19, 2013 at 14:03
  • 10
    @kevincline: probably C#, Java, and VB.NET.
    – tdammers
    Commented Apr 19, 2013 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. Commented Apr 19, 2013 at 14:29
  • @tdammers: LOL. That was a joke, right? Commented Apr 19, 2013 at 19:34
3

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.

2
  • Interface is a type as well, so you could have an IAnimal which both Dog and Cat are. Commented Apr 25, 2013 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). Commented Apr 26, 2013 at 7:47
2

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.

3
  • 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 Commented Apr 19, 2013 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
    Commented Apr 19, 2013 at 13:07
  • Just a note. In some languages, private virtual methods can be overridden in derived classes. Commented May 16, 2014 at 21:30
2

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.

2

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

4
  • 1
    Aren't abstract methods defined without any implementation, and leave the implementation to the inheriting classes? Commented Apr 19, 2013 at 13:12
  • yes your right then i guess its just the variables, constructors and static & private methods if you count those
    – tgkprog
    Commented Apr 19, 2013 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). Commented Apr 25, 2013 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. Commented Apr 26, 2013 at 7:42

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