How does implementing an interface provide additional functionality?

Question

I understand that an interface is a contract for classes and that if a class implements an interface, then all methods in the interface must be in the class.

Here is an example involving interfaces from this question that confuses me:

public class Contact implements Comparable<Contact> {

    private String name;

    public int compareTo(Contact other) {
        return name.compareTo(other.name);
    }
}

You can then obviously create an ArrayList and sort it by name.

List<Contact> contacts = new ArrayList<Contact>();
Collections.sort(contacts);

But if Contract does not implement Comparable like so:

public class Contact {

    private String name;

    public int compareTo(Contact other) {
        return name.compareTo(other.name);
    }
}

Calling Collections.sort will give a compile time error even though the compareTo method still exists.

Clearly there can be additional functionality provided by implementing interfaces. What is the purpose of interfaces other than for enforcing structure?

No, "enforcing structure" is entirely the purpose of interfaces. (This changes a little in Java 8, though...) — Oliver Charlesworth, Sep 12 '14 at 07:36
Interfaces are excellent, very flexible design tool. It's about typing. Collections.sort is declared like sort(Collection extends Comparable>) so again typing issue. I'd recommend you to take a look at Java 8 feature: some methods in Java 8 would work like Collections.sort(collection, Contract::compareTo) — krems, Sep 12 '14 at 08:29
@krems `sort(Collection extends Comparable>)` is patently wrong, it allows classes to be passed that don't `extends Comparable` of _themselves_. Please check your facts before posting. — Boris the Spider, Sep 12 '14 at 08:34
@Boris the Spider I didn't say that's exactly that way, just tried to make the stuff a bit easier to understand. BTW sort function can't have a Collection as an argument, cause not every collection is ordered, in fact Collections.sort takes List, the actual signature is given in answers below and is as follows: `> void sort(List list)` So I didn't really want to duplicate complicated and already written stuff. — krems, Sep 15 '14 at 07:04

Boris the Spider · Accepted Answer · 2014-09-12T08:29:25.723

Because if Contact implements Comparable<Contact> then Contact is a Comparable<Contact>.

Lets take a look at the source code, deep down in ComparableTimSort.countRunAndMakeAscending() there is the line:

if (((Comparable) a[runHi++]).compareTo(a[lo]) < 0)

The pertinent bit is ((Comparable) a[runHi++]) - a[runHi++] is cast to a Comparable and then the compareTo is called on that as a Comparable.

So if Contact implements Comparable<Contact> I can do this:

final Comparable<Contact> contact = new Contact();

If it does not, then I obviously cannot assign the instance to a Comparable type and therefore I have no idea (without resorting to reflection) what methods Contact has.

By implementing Comparable I am telling the compiler that this class is a Comparable and therefore can be treated as one where required. Having to implement the methods is merely a side effect of that.

As to why it's a compile time rather than run time error, you only need to look at the declaration of the method Collections.sort to find out:

public static <T extends Comparable<? super T>> void sort(List<T> list)

So this method is a generic method and it's signature asks for a List<T> where T extends Comparable<? super T>. This is a little tricky to lets break it down.

We need T to extends Comparable<? super T>. So T needs to implements Comparable<? super T> or some subclass of Comparable. ? super T means that it can be Comparable on the type T or any supertype - i.e. if your compareTo can sort Object then it can also sort T (by the Liskov substitution principle).

score 0 · Answer 2 · answered Sep 12 '14 at 07:42

The above answer is the technical one, but from a design point of view they create a layer of abstraction between the layers of program. This is important when designing a complex system because it reduces dependencies between classes and allows for greater maintainability.

Serge Ballesta · Answer 3 · 2014-09-12T08:37:18.153

0

Other answers gave more common usages of interfaces. There are 2 more I am thinking about :

simple marker. Serializable contains no method, nor constants, but simply declare that an instance of the class can be successfully serialized to a stream and de-serialized back.
JDK proxying. A Proxy can only proxies interfaces. So to proxy a class, you must first export its public methods to one or more interfaces. It is commonly used in Spring framework AOP.

edited Sep 12 '14 at 08:37

answered Sep 12 '14 at 07:51

Serge Ballesta

143,923
11
122
252

It's not `@Serializable` because that would be an annotation. In fact the usage of `Serializable` is one of the worst design decisions in the JDK and should not be held up as a example to beginners. Marker interfaces should not be used as annotations exist. Your second example is a massive over-simplification of what is a very complex runtime process. – Boris the Spider Sep 12 '14 at 08:30
@BoristheSpider: thank for noticing the extraneous `@`. I agree that it is a bad design, but it is in the JDK and it took me quite a long time to understand that interfaces could be used as simple markers (I learnt Java by myself ...). And I also admit that proxying is much more complex than what I wrote. I only wanted to insist on the fact that layer separation with interfaces was required to use Spring AOP. But your answer is much better than mine :-) – Serge Ballesta Sep 12 '14 at 08:48

How does implementing an interface provide additional functionality?

3 Answers3