Java – Why ‘List‘ is an ‘interface’ but not ‘abstract class’

abstractioninheritanceinterfacesjavaobject-oriented

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?

Best Answer

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:

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.

Related Solutions

C# Design Patterns – Using Abstract Base Class with Interfaces as Behaviors

[1] Add virtual "getters" & "setters" to your properties, I had to hack another control library, because I need this feature:

abstract class Control
{
    // internal fields for properties
    protected int _Width;
    protected int _Height;
    protected int _BackColor;
    protected int _X;
    protected int _Y;
    protected bool Visible;

    protected int BorderWidth;
    protected int BorderColor;


    // getters & setters virtual !!!

    public virtual int getWidth(...) { ... }
    public virtual void setWidth(...) { ... }

    public virtual int getHeight(...) { ... }
    public virtual void setHeight(...) { ... }

    public virtual int getBackColor(...) { ... }
    public virtual void setBackColor(...) { ... }

    public virtual int getX(...) { ... }
    public virtual void setX(...) { ... }

    public virtual int getY(...) { ... }
    public virtual void setY(...) { ... }

    public virtual int getBorderWidth(...) { ... }
    public virtual void setBorderWidth(...) { ... }

    public virtual int getBorderColor(...) { ... }
    public virtual void setBorderColor(...) { ... }

    public virtual bool getVisible(...) { ... }
    public virtual void setVisible(...) { ... }

    // properties WITH virtual getters & setters

    public int Width { get getWidth(); set setWidth(value); }

    public int Height { get getHeight(); set setHeight(value); }

    public int BackColor { get getBackColor(); set setBackColor(value); }

    public int X { get getX(); set setX(value); }

    public int Y { get getY(); set setY(value); }

    public int BorderWidth { get getBorderWidth(); set setBorderWidth(value); }

    public int BorderColor { get getBorderColor(); set setBorderColor(value); }

    public bool Visible { get getVisible(); set setVisible(value); }

    // other methods

    public Rectangle ClipRectange { get; protected set; }   
    abstract public void Draw();
} // class Control

/* concrete */ class MyControl: Control
{
    public override bool getVisible(...) { ... }
    public override void setVisible(...) { ... }
} // class MyControl: Control

I know this suggestion is more "verbose" or complex, but, its very useful in real world.

[2] Add an "IsEnabled" property, do not confuse with "IsReadOnly":

abstract class Control
{
    // internal fields for properties
    protected bool _IsEnabled;

    public virtual bool getIsEnabled(...) { ... }
    public virtual void setIsEnabled(...) { ... }

    public bool IsEnabled{ get getIsEnabled(); set setIsEnabled(value); }
} // class Control

Means you may have to show your control, but don't show any information.

[3] Add a "IsReadOnly" property, do not confuse with "IsEnabled":

abstract class Control
{
    // internal fields for properties
    protected bool _IsReadOnly;

    public virtual bool getIsReadOnly(...) { ... }
    public virtual void setIsReadOnly(...) { ... }

    public bool IsReadOnly{ get getIsReadOnly(); set setIsReadOnly(value); }
} // class Control

That means the control can display information, but cannot be changed by the user.

Object-Oriented Interfaces – Can Interface Be Not Abstract?

Simple answer to your question : No, your friend is wrong.

An interface provides no implementation of the methods it defines. Would it make sense if we could instantiate one of those? Of course not. Interfaces are only that, an abstraction.

This is obviously assuming that when you say interface, you think about the interface language feature as defined by C#, Java, C++, etc with the interface keyword. In the case your friend means an API interface, then the question does not really make sense to me. APIs may allow you to extend functionality through subclassing or by adhering to a particular contract as defined by an interface or an existing class of the system.

Best Answer

In response to the very beginning of your question

Related Solutions

C# Design Patterns – Using Abstract Base Class with Interfaces as Behaviors

Object-Oriented Interfaces – Can Interface Be Not Abstract?

Related Topic