I am starting out in Java API design and in reading existing code bases, I have found that most APIs consist of interfaces only with their implementations bundled in a different package.

Having read that interfaces are generally more problematic to use/maintain than abstract classes, why aren't abstract classes used instead of interfaces?

  • 2
    Can you provide a source, where you read about the interface vs. abstract classes comparison – Benni Jun 24 '14 at 12:25
  • Can't provide exact source but i think if an interface is changed, all its implementations are really broken, unlike an abstract class. – Pawan Jun 24 '14 at 12:35
  • 1
    Having all the implementations break is exactly what you want if an interface changes. It happens if you change an abstract class too. – Doval Jun 24 '14 at 12:37
  • 1
    But adding a method to an abstract class won't break implementations. Although i am beginning to see your point now. Interfaces are used to ensure that the given methods are implemented. – Pawan Jun 24 '14 at 12:41
  • 1
    If you add an abstract method to an abstract class, implementations will break. – Doval Jun 24 '14 at 12:49

What's an API ? It is an interface by definition.

Consider the software you're using as a blackbox. You're not supposed to know how things are done internally, nor are you supposed to want that, or you would just build things yourself. Besides, trying to extend an API class yourself may break the tool's behaviour (which, once again, you don't really know).

The software you are using and your own softwares are two different softwares, so the only thing you should need is the link between them, namely the interface. See what an interface means in computer science and you should understand why it applies to the OOP meaning of the word.

Now as for your abstract class argument, it seems completely subjective. As far as I'm concerned, a class in Java can implement several interfaces but extend only one base class.


Not sure where you read that interfaces are more problematic to use or maintain. You can only inherit from one base class, but you can implement as many interfaces as you want, so interfaces are inherently more flexible. E.g. Consider what would happen if Closeable and Readable were abstract classes; you'd have no way of making, say, a FileReader that subclasses both.

  • But how is that applicable in api design? Won't adding any new method to the api interface readily break all implementations? – Pawan Jun 24 '14 at 12:37
  • Yes. API design is hard. There is no silver bullet. Think long and hard about whether you've separated all your concerns and have identified the most fundamental abstractions before you let an API loose to the public. Aside from that there's nothing you can do; requirements change, code breaks. Come up with any API you like; there's always a requirement it can't handle. Use a proper versioning scheme so that when you inevitably make a backwards-incompatible change, your users know. – Doval Jun 24 '14 at 12:41

The main reason is that Interfaces allow you to provide a common ground between your implementation and who ever is making use of your code. There are scenarios where you do not want the caller to know how you are executing certain pieces of logic. The reasons for this can be security or proprietary algorithms, to mention a few.

When you define an interface, you outline what functions you will be offering. In most cases, the caller will not care how you have implemented, say, a sorting mechanism. The caller simply cares that it works.

Coding to an interface also gives you a relatively large degree of freedom since you are, at no point, constraining yourself to implemented logic. So, if your method yields a List instead of an ArrayList, you are giving the freedom to the caller to resolve that to any class which implements list.

As @Benjamin Rogge said, I would also like to see where you read that abstract classes are more difficult to maintain.

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