Why 'List<E>' is an 'interface' but not 'abstract class'?

Question

Amidst defining the hierarchy, firstly, one can think to embed the abstract method(behavior) in abstract class only because the derive concrete class possess that behavior as core behavior with it's specific implementation, secondly, one can think to embed the abstract method(behavior) in interface only because derived concrete class possess that behavior as non-core behavior(peripheral) having it's specific implementation.

As I would not rely on this example which supports above point, below are the two references, I would rely on.

---

1) First reference that supports this point:

Interfaces are ideal for defining mixins. Loosely speaking, a mixin is a type that a class can implement in addition to its "primary type" to declare that it provides some optional behavior. For example, Comparable is a mixing interface that allows a class to declare that its instances are ordered with respect to other mutually comparable objects. Such an interface is called a mixin because it allows the optional functionality to be "mixed in" to the type's primary functionality. Abstract classes can't be sued to define mixins for the same reason that they can't be retrofitted onto existing classes: a class cannot have more than one parent, and there is no reasonable place in the class hierarchy to insert a mixin.

2) Second reference that support this point:

In UML sketch, the relation between interface model and concrete class model is named Realisation, where as, the relation between abstract class model and concrete class model is named is-a relation. Here is-a can be told, when concrete class has core behavior unlike realisation relation.

So, with these two references, It looks list<E> and Collection<E> are abstract class but not interface.

---

With this above explanation, I would like to understand,

Why Collection<E> and List<E> is designed to be interface in java.util package?

Is my understanding correct?

• Ordous: Now why in the world would you do that? What specific behaviour would an array-backed list and a linked list have that is the same in implementation? Also, is your logic the same for a Queue as well? A LinkedList is both, but it can't have double inheritance!
• overexchange: For your question: What specific behaviour would an array-backed list and a linked list have that is the same in implementation?, am not sure, why the implementation of array-backed list and linked list will be same(for example, insertFront() say)?, they will be different but for same behaviour name(i.e., insertFront()). for your second question: Yes, Queue should be an abstract class` if it has its own core behaviour. if LinkedList is trying to inherit core behaviours of both super types List and Queue then that is meaningless.
• KChaloux: @overexchange Apologies. I'm going to be honest, I'm having a very hard time following what exactly the question is asking, as the English isn't very well formed.
• Ordous: @overexchange Java abstract classes are not used that way... You use an interface to define common behaviours and contracts, while abstract classes are to define common implementation details.
• user40980: Please do not fundamentally change the nature of the question after it has garnered a number of answers and sat for a period of time. Doing so may confuse future readers and require the answers to get updated to the newly asked question.

Answer 1

Having these abstractions implemented as interfaces allows more flexibility.

Interfaces allow programmers to use multiple inheritance of type in Java. This way you can treat any class as an instance of the interface regardless of its inheritance hierarchy.

You can implement any number of interfaces in a single class but you can only have a single superclass (as expressed by the extends keyword).

At the same time, nothing prevents you from providing a skeletal implementation of any given interface. Just write an abstract class implementing it and use it as you please. You still have a single place to put the common parts and you don't make the clients of your API dependent on any actual implementation.

Besides, lists can have vastly different implementations and the details of the core behaviours can rely on mechanisms that are not at all similar.

Take a look at LinkedList and ArrayList for example.

The first one is backed by a number of interlinked objects. The latter stores its elements in an array. The way you access elements of these data structures is simply different. The effect of these operations is identical (and understandably, both these collections implement the List interface) but the actual behaviour, the algorithms used to perform those operations are not really common.

Coincidentally, these concrete classes also have abstract superclasses that serve as their skeletal implementations. LinkedList is an instance of List and AbstractSequentialList while ArrayList is a List and an AbstractList

List is an interface because of how general it is. It does not assume anything about implementation. AbstractSequentialList and AbstractList on the other hand do assume certain ways of element access. Hence they're implemented as abstract classes.

In response to the very beginning of your question

While defining the hierarchy, one can think to embed the abstract method(behaviour) in abstract class only because the derive concrete class posses that as core behaviour with it's specific implementation, one can think to embed the abstract method(behaviour) in interface only because derived concrete class does not posses that as core behaviour(but as peripheral) having it's specific implementation.

Above definition can be understood well with this example

One of the good reference also supports this point:

Joshua Bloch - Effective Java

It's true that implementing multiple interfaces in a single class allows you to combine possibly unrelated sets of behaviour, or as you express it, peripheral behaviour but this is just a use case rather than the purpose of interfaces in its entirety.

Using interfaces to create mixins is a great use case for them and the only way to have multiple inheritance in Java but you're free to use interfaces outside this context.

It's perfectly valid to use an interface to define a set of core behaviours for a family of classes. In this case, I wouldn't say it is used as a mixin. It just defines a contract. At the same time, it can be used as a mixin by any other class if the programmer so desires. This is a matter of naming and the context in which you use these concepts.

The distinction between core and peripheral behaviour is completely separate from the distinction between classes and interfaces. What truly makes the difference here is that the set of implemented interfaces specifies what you can do with an object while the classes (abstract or not) in its inheritance hierarchy define how these things are to be done.

An abstract class with all its methods declared as abstract is just like a poorly implemented interface with its usage severely limited by the lack of capability regarding multiple inheritance of type.

• overexchange: I would not use interface because subclass can inherit behaviour from multiple super types. This thought process would not help me to decide when to use interface.
• toniedzwiedz: @overexchange a subclass can not inherit behaviour from multiple super types (unless all of those types are arranged in a linear hierarchy of subclasses). You only get a single line of inheritance. Java does not support traits or mixins, you have to handle these cases using composition and a combination of interfaces.
• ratchet freak: And there is the AbstractList and AbstractSequentialList classes that you base your implementation on
• toniedzwiedz: yes they are not common, but the nature of behaviour is same and this is precisely why List is an interface. The goal you want to achieve with each of its methods is exactly the same but the actual code required is vastly different. This is why you cannot have concrete methods providing this behaviour at this level of abstraction. If you wanted to make List an abstract class, you'd have to make one without concrete methods. Such an abstract class has no advantage over an interface and it bears all limitations imposed by the nature of class inheritance.
• paul: @Tom I wish I could upvote again, after your edit.

Answer 2

So an interface implies a contract - You guarantee that any class implementing the interface contains these methods, with these parameter types, and returns this type. This is great when you know there are many different ways of doing the same thing (maintaining lists, sorting, etc)

An abstract class, on the other hand, says that there are different ways of implementing this thing, but they will all share some set of functionality and I'll provide that functionality in this class. This is where the two diverge. One says that you have some knowledge that lets you know that ALL implementations will do one part the exact same way. This may apply in many cases, but for things like Lists or Sorting, there's almost always going to be some new, novel way to do things that you haven't thought of yet. That's why you use an interface and not an abstract class.

• overexchange: Am not sure, how do you define the word contract (in oops world) but what does contract mean in this context 'public interface java.awt.EventListen er {}`.

Answer 3

You're quoting your reference (Joshua Bloch, Effective Java) out of context. It isn't stating one particular purpose for interfaces and that they should only be used for that purpose. It's enumerating a (non-exhaustive) list of possible applications for them, all of which fall under the general heading "Prefer interfaces to abstract classes". How you get from this to deciding that List<> would be in some fashion better as an abstract class, I'm not quite sure, but it seems that you're picking up details of Bloch's argument without comprehending the overall purpose of it.

• overexchange: As per my comment above, i already said that List must be an interface, because all the abstract methods in List are mixins. I said the same ate hte botom of the query: As per the above definition, all the abstract methods(behaviour) embed in List<E> are not core behaviours.
• Jules: I'm not sure I understand what you're saying then. It seems to me to be quite clear, for instance that boolean add(E) represents a core behaviour of any well-designed object that implements List.
• overexchange: there is actual content to read in this attached paragraph(in the query) than concentrating on single line of heading. I would not care, what heading tells me. His paragraph clearly explains when to use interface and when to use abstract class
• Jules: No, the paragraph you've highlighted clearly explains one particular circumstance in which to use interface rather than abstract class. There are others, many of which are listed in the surrounding paragraphs.
• overexchange: paragraph talks about the basic thought process to be involved while introducing interface or abstract class, in its entirety.

Answer 4

Collection types using interface instead of abstract class is a mistake. Indeed, such a huge mistake that the Java SE 8 language has had bizarre extensions grafted onto it so that interfaces could have implementation methods.

So why the mistake? Ideally you want to define an interface (general definition of "interface", not the Java keyword) without depending on implementation. The Java 2 collections framework was developed with the arguably arrogant assumption that all the methods that you would ever want for the type could be determined upfront. This attitude has led to hacks to support collections in almost every major revision of Java.

There is the odd advantage of List being an interface. AbstractCollection is used for common implementation of both List and Set but you wouldn't want it to subtype those. Though, more often than not, such subtyping is inappropriate.

• overexchange: In general terms,you mean, an Abstract_data_type is an implementation class [class Date{}(in java(say))] that has well defined interface. That interface instructs in plain English to programming partner or yourself on how to use this class, how to use methods & fields of this class? That way, you can change the implementation of a class without jeopardizing the programs that depend on it. Is that what the scope of the definition of interface that any prog language has to follow?
• Tom Hawtin - tackline: @overexchange Well, it's more than just the English (or natural language) API docs. A class specifies much the same in terms of interface as an interface does. (And it needn't be a type - a static method defines an interface to its implementation.) (When talking about the general concept of an "interface" I remove the backticks as I don't mean the Java keyword.)
• overexchange: whether i use java 7 or java 8, while designing class hierarchy, can i say that, common implementations sit in abstract class and common functionality sit in interface. Is this the same approach that holds good using java 8?
• Tom Hawtin - tackline: @overexchange You can still do that. Legacy collection interfaces in java.util have default methods. java.util.stream doesn't use non-static default methods, though nor does have any public Abstract* classes. java.util.function has (arguably trivial) default instance methods.
• overexchange: Did you get the chance to go thru this Query?