Difference between abstract class and interface in Objective-C

Question

One of the most frequently asked questions on iOS developer interview is - difference between abstract classed and interface.

I don't know an answer and i don't get it neither. Interface is a section of class, when you declared methods. it could be open for other classes (public, .h file) or hidden in implementation.

Abstract class is a class, that is only used to create hidden subclasses and it should not have own init methods (if i understand correct).

So, what exactly is answer for that question? And what does that question mean?

I did spend time searching for an answers, but answers wasn't related to Obj-C, so i can't figure out by myself.

I hope someone could provide clear answer and that question would be helpful for those guys, who want to pass an interview.

Answer 1

A good way to approach this problem is first think about it in general programming theory, and then in more concrete Objective-C context.

---

Abstract Class - is a class intended purely for subclassing, one must not instantiate it. Abstract class declares something and has also the implementation for that.

What is the reason for having such special class? It is modelled after real life! :) Imagine an abstraction - an animal. What has each animal in common? They are all alive (and can die). They need to eat. The can move in space. These traits are common and fundamental to all animals. I heaven't heard about an animal that doesn't needs food, cannot move and lives forever. Other then that there is a LOT of not so fundamental differences between various animals.

There is no animal on the planet which is purely an abstract animal like that. That set of fundamental behaviours, traits is simply not enough to be a concrete animal.. There is an implied principle, that to be a concrete animal, you have to have some additional traits besides those fundamental ones.

Now, in programming, we need to be able to somehow

• express these fundamentals (interface declaration)
• have a way of describing how they work (implementation)
• attribute them to a class
• prevent instantiation
• ensure that any concrete animal will have them (inheritance)

We know, what these fundamentals are (declared public interface) and we know in practice how they manifest themselves concretely (implementation of those declared traits). We want them to be inherited by all concrete entities. So we do it in the abstract class because it satisfies these condition I mentioned. It contains all the fundamentals, has their implementation, but cannot be instantiated on its own.

Abstract class is an abstraction over a set of related entities that captures what is fundamentally common between all of them., tells us how it is done..and ensures all more concrete entities will inherit this.

---

Interface - is something less. Let's a have a real life analogy. Person, robot, animal, wind (a force of nature). Some people can sing. A robot has a voice synthesizer module embedded so it can sing. The autumn wind touching my teracce glass "sings" a lot I can tell you. And Tinka (r.i.p) my dog, was actually a good singer too.

But really, "singing" between these four has the only thing in common - you can hear it as pleasing sound in your ears. How the singing happens for those four, differs a lot in reality. (implementation)

Another complication is, certainly not all people, dogs, winds, or animals can sing. Some of them can.

So how would we reflect this situation in programming? Via interface :)

You can have an interface called "SingInterface" which in our case has one behaviour/trait/functionality declared and it is sing. Interface simply declares something and that's it. Interface doesn't say how that something is done, there is no concrete implementation. Nor does it say who can do it, the trait in the interface is not limited to one type or one class really. (see http://www.nasa.gov/centers/goddard/universe/black_hole_sound.html)

Interface is a list of 1 to N traits/functionalities without knowing how concretely will they be realized, and that list of traits/functionalities that can be arbitrarily (no rules exist to who) attributable to entities from disparate sets that are fundamentally different (animals or robots).

Object oriented programming borrows many concepts from real life. That's why these analogies work so well.

---

In Objective C, contrary to some other languages (C# etc),

there is no language level support for abstract classes. It is not possible to enforce that a class is abstract during compilation. A class is abstract only by convention and respecting that convention by developers.

As for interfaces, a word "protocol" is used in objective C. It's just a different word for the same thing.

In objective C you can

• code against the interface ..by declaring some object as

   id<protocolName>
  

• add additional functionality to classes by declaring that they conform to protocol which you do in the class interface

  @interface ClassName <protocolName>
  

So, there might possibly be even a case where your class is a subclass of abstract class, and it also conform to some protocol.

Answer 2

Thanks to Rob Napier's comment at here. My answer is:

An interface is just the outside view of a class. What it reveals publicly.

In Swift you just write a class in a single .Swift file, and if ask Xcode to show you can generate its interface. Xcode will only then show properties/functions that are public/internal.

In Objective-C. You first have to manually write the interface...declaring what of the class is public and then manually write the implementation. An interface without implementation is not compilable. It's like you saying this is how my class will look like, but then you have provided nothing for how it implements the public methods or how you manipulate your properties—when you must (provide).

Abstract relieves you of how it implements

For abstract classes, you shouldn't provide any implementation, only that it would have such parameters or it would have such functions with such signatures. However an abstract class is compilable on its own. Because you don't need to provide anything more than that.