This page contains an archived post to the Design Forum (formerly called the Flexible Java Forum) made prior to February 25, 2002. If you wish to participate in discussions, please visit the new Artima Forums.

Message:

Confusion is understandable

Posted by Mike Mannion on 17 Nov 1998, 1:40 AM

Like Bill, I also recall battling with the notion of a Java interface when Java first hit the scene.
Of course, once you get used to it, it's quite simple, but Bill's article encouraged me to think about exactly why I, like many people, found the idea so confusing at the beginning.
After some deliberation I came to the following conclusion: At that time I thought I was dealing with something new, something I'd never seen before in (at that time) over six years of working with OO.
Clearly, an interface is not a class, otherwise it wouldn't have been given its own special construct, right? Wrong!
Therein lies the problem: A Java interface IS a class - a purely abstract class.
When we use interfaces we are using nothing other than multiple inheritance itself.

Oooo, but I thought multiple inheritance was sooo BAD! Not so. If it were, only BAD programmers would use Java interfaces, and clearly this is not the case.

MI has, in fact, just one problem: A bad reputation, which stems almost solely from C++�s appalling support for MI.

Java interface advantages:
- Provides (limited) support for MI
- Simplifies compiler and runtime design (an advantage for James Gosling, infact, but not for me)
(Can anyone think of any more?)

Java interface disadvantages:
- Two language constructs required for what amounts to same thing
- Inconsistencies across language constructs (e.g. method modifiers in class vs. in interface)
- Does not map intuitively to domain object models and visa versa (lack of seamlessness)
- Only solves naming conflict from a compiler perspective - not from a modelling perspective

Unlike some other notable kludges of the Java language (primitive types, fixed package names), Java interfaces actually work surprisingly well in practice. Nevertheless, I could easily envisage seeing negative consequences of interfaces at a later stage of Java�s evolution.

For example, suppose Java should one day fully support Design by Contract. Full support would allow us to go beyond a mere method signature in a Java interface and make it possible to specify semantic constraints (pre- and postconditions). Such constraints must, of course, be inherited, but what happens if two interfaces specify two distinct (potentially conflicting) sets of semantic constraints for methods sharing the same signature?

Now we notice that the naming conflict has been with us all along! Just imagine the same situation with totally conflicting comments or usage notes associated with those multiply inherited methods.

Anyone feel differently?

• Is inheritance of semantic constraints a problem? John Rivett-Carnac 30 Nov 1998, 3:13 PM (1)
  • An interesting prospect Mike Mannion 03 Dec 1998, 1:00 AM (0)
• Design by contract in Java Vladimir Blagojevic 27 Nov 1998, 9:57 PM (0)
• Interfaces are NOT MI. Ralph M. Prescott 17 Nov 1998, 10:54 AM (8)
  • Implementations and behaviours Mike Mannion 18 Nov 1998, 4:07 AM (1)
    • Wrong book title Mike Mannion 18 Nov 1998, 10:05 AM (0)
  • Epiphany Bill Venners 17 Nov 1998, 7:37 PM (5)
    • What is fundamental? Mike Mannion 23 Nov 1998, 12:40 AM (4)
      • Abstract class Doug Bell 23 Nov 1998, 11:48 AM (3)
        • asaa aaaa November 30, 2001 at 2:46 PM (0)
        • Abstract Behavioural Specification Mike Mannion 24 Nov 1998, 8:42 AM (0)
        • Absolutely not Mike Mannion 24 Nov 1998, 7:27 AM (0)