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
Interfaces are NOT MI.
Posted by Ralph M. Prescott on 17 Nov 1998, 10:54 AM
I have to disagree with some of your points.
> 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.
A class is a class too. It's also an Object. Does that make it NOT a class? This is flawed logic.
> When we use interfaces we are using nothing other than multiple inheritance itself.
Yes all behavior and zero implementation.
To paraphrase Bill: it's the separation of concerns between "what" is done (the interface) and "how" it is done (the implementation).
> 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.
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.
> Java interface advantages:
> - Provides (limited) support for MI
It limits MI of implementation not MI of behavior.
> - Simplifies compiler and runtime design (an advantage for James Gosling, infact, but not for me)
> (Can anyone think of any more?)
Forces you to reduces unneeded class coupling by separating concerns. Oh bother.
> Java interface disadvantages:
> - Two language constructs required for what amounts to same thing
They aren't the same thing.
> - Inconsistencies across language constructs (e.g. method modifiers in class vs. in interface)
Yes, the goal of minimal keywords can be a drag.
> - 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
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
(it's all the same thing) separatly from their implementation.
Check out Peter Coad's recent work. He explains this better than I can in
this short space. Also consider why the UML provide a very concise
shorthand for interfaces -- the lollypop. It's not JUST for COM anymore ;-)
> 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.
fixed package names? What's the problem here?
Well, I could see the need to play games with dynamic interfaces.
Roles that come and go over time. But you could roll your own mechanism for that.
[DBC stuff snipped]
Won't touch that one.
> Anyone feel differently?