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:

Implementations and behaviours

Posted by Mike Mannion on 18 Nov 1998, 4:07 AM

> But on the other hand, in the more general object oriented
> meaning of the word class, Mike is right in saying that
> Java's interface is just a special kind of class: a "purely
> abstract class."

The reflection API underlines this observation e.g.
Class[] myClass.getInterfaces()
^^^^^
> Although it's usually not helpful to argue about terminology,
> it's helpful to define your terms when you are trying to
> debate the meaning behind the words.

I feel that a refined terminology is central to OO, and to software engineering in general. Indeed, I would attribute much of the software crisis to ambiguity in one form or another.

>> That and its common misuse by blurring implementation and interface.
>> C++ supports interfaces. They're called pure virtual base classes.
>> They aren't often used when designing except by OO purists.

This was a common and useful idiom to achieve MI in C++ without all of the naming conflict headaches. In fact, I wouldn't be surprised if that's where Mr Gosling got the idea for interfaces from.

More importantly, it is not implementations and interfaces which were (and are still) being blurred, its implementations and *behaviours*.

> - Provides (limited) support for MI
>>It limits MI of implementation not MI of behavior.

Yes! This is an absolutely correct and important observation. And the behavioural aspect is clearly far more crucial and fundamental than implementation when we talk about modelling and design. Yet it leads us to perhaps the greatest deficiency of the Java language: Not a single construct exists for stating the behaviour of class of objects - other than (a) the implementation itself and (b) /* programmer comments */

Java interfaces are empty shells. The only semantic contraints present are the ones implied by parameter and return value types. This is clearly insufficient for specifying non-trivial behaviour, as potentially ANY behaviour - even totally ludicrous or incorrect behaviour - can be attached to an interface.

Comments are by nature ambiguous and cannot be checked by a compiler or at runtime. Comments (even if they are 100% accurate) from multiply inherited methods sharing the same signiture may, in addition, completely contradict each other - not good for long term maintainability.

Back to Design by Contract.

> - Only solves naming conflict from a compiler perspective - not from a modelling perspective
>> I disagree strongly here as well. You simply have to switch to
>> modeling things by the "roles" they fill -> contracts they keep -> interfaces they >> implement

Obliging the implementor of an interface to conform to a set of method signitures is not what I call a contract. It's a skeleton with no meat. (And no, the meat is NOT the implementation.)

>>Check out Peter Coad's recent work. He explains this better than I can in

I have no problem with "roles" and I'm very familiar with Peter Coad's work. In fact, earlier this year I exchanged some mails with Peter on this very subject. We basically agreed upon relatively superficial nature of the Java interface.

With any luck, you'll find a new section on the matter in the new edition of the "Java Design" book, called "Java Design; Designing with Components" (not yet released).

- mm

• Wrong book title Mike Mannion 18 Nov 1998, 10:05 AM (0)