1

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?

Pawan
  • 121
  • 2
  • 6
  • 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
  • My question is specifically related to api design. I am aware of the difference between interfaces and abstract class, just asking why interfaces are preferred in api design. – Pawan Jun 24 '14 at 12:36
  • 2
    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
  • 2
    If you add an abstract method to an abstract class, implementations will break. – Doval Jun 24 '14 at 12:49
  • I want to emphasize what the I in API stands for: interface. Granted, that does not mean that all API's must be interface-only, but it does seem appropriate. – Brandon Jun 24 '14 at 14:15
  • In addition to the answers above, isn't one of the major benefits of doing interfaces the ability to develop and mock unit tests? – ganders Jun 24 '14 at 12:54
  • As a minor side note, this is only the case because of Java's restrictions. In other languages like Standard ML and OCaml it's possible to have static dispatch while still substituting one module for another. The problem is that Java wants you to hard-code a unique identifier for the class into the source. – Doval Jun 24 '14 at 13:01
  • @Brandon That was the whole reason of my answer, actually. However I still disagree with the "duplicate" part, as there are two questions here (why are API written with interface? Why is an interface better than an abstract class?) and I focused on the first one, which was never asked on the network. – Pierre Arlaud Jun 25 '14 at 07:21

3 Answers3

4

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.

Pierre Arlaud
  • 1,339
1

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.

Doval
  • 15,397
  • 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
0

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.

npinti
  • 1,654