3

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?

Community
  • 1
overexchange
  • 2,265
  • 3
    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! – Ordous Nov 13 '14 at 18:40
  • 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 classif it has its own core behaviour. ifLinkedListis trying to inherit core behaviours of both super typesListandQueue` then that is meaningless. – overexchange Nov 13 '14 at 18:58
  • @overexchange If you think a Linked List and Array List share the same implementation, you should do some reading up on how each of the two data structures are typically implemented, and what their strengths and weaknesses are. They are very different things internally, similar only in that they model sequential collections of elements. – KChaloux Nov 13 '14 at 19:03
  • @KChaloux as per my previous update i said the implementation of ArrayList and LinkedList is different. Am still not clear, How same/different implementation related to usage of abstract class? Because i would just declare as public abstract boolean insertFront(); in my abstract class and implement it differently in multiple subclasses? – overexchange Nov 13 '14 at 19:05
  • 1
    @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. – KChaloux Nov 13 '14 at 19:07
  • 11
    @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. – Ordous Nov 13 '14 at 19:26
  • @Ordous abstract class may not always have common implementations. semantically, it make sense to leave it to the derived subclass to implement it as shown in this example for update() method. – overexchange Nov 13 '14 at 19:30
  • @overexchange But that thing does have common implementation details. The location and the equals. And by defining the update method in that class, the author tied its presence to those details - any Critter has an update method, and that update method can rely on the Critter having a Location, which is a concrete mutable Point. – Ordous Nov 13 '14 at 19:35
  • @Ordous if you term update() as defining common implementation detail, then what would you term toEncode() in this same example that every Critter implements it for example - class Fish extends Critter implements IPeripheralBehaviour{}. – overexchange Nov 13 '14 at 19:43
  • @Tom As per the book reference, Did you see why peripheral behaviour can't be introduced in abstract class, a class cannot have more than one parent, and there is no reasonable place(other than interface) in the class hierarchy to insert a mixin . This is the reason i removed toEncode() method from Critter class and placed in IPeripheralBehaviour interface as per this example. Coming back to query, the List is an interface because the abstract methods within are optional functionality at List level. – overexchange Nov 14 '14 at 12:24
  • @Ordous Those two sentences as an answer would have given you an instant 80 points :) – Maarten Bodewes Nov 14 '14 at 14:12
  • @Ordous: "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." Don't default interface methods define common implementation details? – Giorgio Dec 21 '14 at 22:39
  • 2
    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. –  May 26 '15 at 16:10

4 Answers4

13

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.

Community
  • 1
toniedzwiedz
  • 1,355
  • 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. – overexchange Nov 13 '14 at 18:51
  • This answer is trying to just follow the grammar that java compiler agrees for usage of interface and abstract class. I need the semantic aspect of the usage. – overexchange Nov 13 '14 at 19:03
  • 5
    @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. – toniedzwiedz Nov 13 '14 at 19:12
  • i said the same in my first comment for your answer. – overexchange Nov 13 '14 at 19:25
  • 1
    And there is the AbstractList and AbstractSequentialList classes that you base your implementation on – ratchet freak Nov 13 '14 at 19:27
  • @ratchetfreak exactly, these are examples of skeletal implementations for the List interface. – toniedzwiedz Nov 13 '14 at 19:30
  • @overexchange sorry but I fail to understand what you mean by semantic aspect. This is more than just syntax, interfaces and classes allow you to use two types of inheritance that are conceptually different. Maybe this answer will be clearer – toniedzwiedz Nov 13 '14 at 19:34
  • For your point: but the actual behaviour, the algorithms used to perform those operations are not really common. yes they are not common, but the nature of behaviour is same. I dont agree with this answer, May be we can chat further. would you like to invite me? – overexchange Nov 13 '14 at 19:56
  • 3
    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. – toniedzwiedz Nov 13 '14 at 20:02
  • If an abstract class has 3 abstract methods(say), then it is better to be an interface rather than abstract class. Is that what you are saying? If yes, then your design will go for a toss in coming future. – overexchange Nov 13 '14 at 20:06
  • @overexchange that's not what I'm saying. At a level of abstraction as high as List or Collection it would only make sense to make all methods abstract and provide no implementation at all. Besides, providing both an interface and a set of abstract classes implementing it is a win-win situation. You get both the flexibility and the code reuse. This is the case with List and its more concrete variants. So it is with other collections. – toniedzwiedz Nov 13 '14 at 20:11
  • 1
    @Tom I wish I could upvote again, after your edit. – paul Nov 14 '14 at 14:20
  • @paul this is another example, why peripheral behaviour close() sit in interface Closeable instead of abstract class InputStream, because class ByteArrayInputStream do not require close() operation. interface Closeable woulc have been left for concrete class to implement it instead of abstract class InputStream implement it. – overexchange Dec 20 '14 at 14:59
  • @overexchange I do not believe I am the party to whom you wanted to reply for this conversation thread; likely you wanted toniedzwiedz – paul Dec 22 '14 at 15:45
5

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.

Ampt
  • 4,723
  • 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 {}`. – overexchange Dec 01 '14 at 07:20
2

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.

Jules
  • 17,754
  • 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. – overexchange Nov 14 '14 at 13:37
  • 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. – Jules Nov 14 '14 at 13:39
  • 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 – overexchange Nov 14 '14 at 13:40
  • 2
    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. – Jules Nov 14 '14 at 13:41
  • paragraph talks about the basic thought process to be involved while introducing interface or abstract class, in its entirety. – overexchange Nov 14 '14 at 13:45
0

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.

Tom Hawtin - tackline
  • 662
  • 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? – overexchange Nov 20 '14 at 00:52
  • @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.) – Tom Hawtin - tackline Nov 20 '14 at 01:29
  • 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? – overexchange Nov 24 '14 at 02:18
  • @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. – Tom Hawtin - tackline Nov 24 '14 at 03:16
  • Did you get the chance to go thru this Query? – overexchange Jul 06 '15 at 00:36