I didn't make the original "of course it's a type" comment, but I totally agree. A Java interface is still a type.

Why? Well - what is a type? According to wikipedia:

"A data type can also be thought of as a constraint placed upon the interpretation of data in a type system, describing representation, interpretation and structure of values or objects stored in computer memory."

Although, I prefer a slightly simpler description - a type is anything you can refer to without explicitly requiring an understanding of it's structure.

So in that case, a Java interface is a type, because you can define a variable that is referred to only by that Java interface name.

So if I had, say:

interface Shape {
void draw();
}

I can then refer to a shape somewhere - eg.

class Screen {
void render(Shape s) {
}
}

In the render method, there is a variable s, which is a Shape (eg. has the type of shape). It's irrelevant that Shape is a Java interface (or ABC) in this case.

So what is the difference between a Java interface and an ABC? A Java interface cannot contain attributes or default method implementations. This is purely for trickery for the Java language, since having multiple inheritance in the presence of attributes or default method implementations is confusing.
 

I should add - I used "Java interface" in my last comment on purpose. If your talking about the concept of interfaces in general - then I'd agree, they are not a type. An interface is a description of how you can interact (or interface...duh) with a component/object/whatever.

Which leads to the statement:

Java interfaces are not interfaces.

Simple, huh? ;-)
 

Hi Chris, thank you for explaining your thoughts and giving me an opportunity to express my thoughts more clearly.

As I mentioned in the beginning of the post its only the conceptual difference between the two, I am focusing on.
Or when to use class and when to use interface. When I mean type/class I mean the existence of a real world type/class.


As anything I can draw is a Shape, I prefer to design Shape an abstract class rather than a Drawable interface.



In the other example Pet, Robot, Human are real world types. Eventhough all of them have a 'walk' behaviour,
the behaviour is not sufficient to identify any of the types Pet, Robot or Human. When I need to tie them together based
on the 'walk' behaviour you may use a Walkable interface. And 'walk' is only a subset of the interfaces(behaviours) exposed
by the types Pet, Robot or Human and that is why I would say Walkable does not define a real world type.


Now let us assume that 'walk' is the central behaviour we are concerned about in our domain.
I prefer to design a Walker class as below

abstract class Walker {
abstract void walk();

}

Pet extends Walker {

void walk(){....}
}

Robot extends Walker {

void walk(){....}
}
......
 

Sure - but your use of an ABC in this case is really just a personal preference. Syntactically, there really is no difference between this and defining Walker as a Java interface. Either way, you can use 'Walker' as the type of a variable anywhere in the system.

How would you deal with something that has two base 'types' that you can refer to in different areas of the system? Say you have a ProdegeMusician - which has the base types of Student and of Musician. This is the classic multiple inheritance requirement. In some cases you would want to pass a ProdegeMusician object to parts of the system that are only concerned with Students (eg. billing them for time?) and in other cases to parts of the system that are only concerned with Musicians (eg. getting them to play?).

Since classical multiple inheritance where two base classes containing attributes or default method implementations can lead to ambiguity and confusion (eg. the diamond problem in C++), they introduced the concept of a Java 'interface' to allow you to have two 'base types', whilst avoiding this area of confusion.

But in this example, you couldn't define both Student and Musician as ABC's in Java - at least one would have to be an interface, even though you will use it as a type.

This is one reason why many people strongly encourage the use of Java interfaces for defining all exposed types in a system (eg. the classic Foo and FooImpl scenario). This is because two types that are not Java interfaces cannot be combined later into class represents both types, which puts a constraint on the extensibility of the system.

(note: I personally prefer this as well, but I hate the Impl part - people should be more creative ;-) )
 

In the original post example of Shape there is no requirement for combining with another type (atleast I cannot think of any). As there is no multiple inheritance requirement my clear choice would be a class here.

However in cases where multiple inheritance is required we are left with no option than to use an interface. Its a limitation of language and all of us have to live with it.

From a system extensibility point, ProdegeMusician is a Person who changes his/her role as a Student or Musician depending on the context will be a more extensible design.