A perspective on interfaces

How to solve problems with Java's interfaces

By Peter Kriens, JavaWorld.com, 02/01/98

When Java introduced interfaces and I started to understand how they worked, it dawned on me that they were similar to the signatures I'd read about in that article. They have exactly the same purpose: To create type safety without the tight coupling of inheritance. Once I fully understood the purpose of Java's interfaces, I began to really love them.

Having used interfaces for two years now, I still love them, but my view of them has matured. In fact, I have identified several problems with interfaces:

1. Significant increase in package sizes
2. No version migration path
3. Name scoping
4. No default implementation

Increase in package sizes

The first problem is the explosion in the number of classes and interfaces. I just downloaded the JDK 1.2 beta 2 and immediately looked at the package overview. The first thing that becomes obvious is the huge number of packages and classes. The simplicity promised by JDK 1.0.2 appears to be awfully far off in the distance. I guess that's progress for ya. ;)

Looking a bit further into interfaces, I found that Swing, the new lightweight user interface framework, is causing the biggest expansion in Java 1.2 (along with the abstract windowing toolkit [AWT]). One of the reasons for this, strangely enough, is the interface. The interface has caused the number of classes and interfaces to double, at least. The designers of Java 1.2 seem to have a particular rule: to use interfaces whenever possible. While this provides a lot of flexibility, it also increases the conceptual complexity of the design. To do something useful, however, an implementation is needed, and this results in a class that has a name very similar to that of the interface. Personally, I do not like this explosion because of the significant increase in complexity that comes along with it.

Future extensibility

The second problem I see is future extensibility. Once an interface is distributed, there can never be a change in its definition. A change would immediately break all existing code. For example, let's say we have the following interface:

public interface I {
    public void f();
}

Now, in the next release we want to extend it with a new method:

public interface I {
    public void f();
    public void g();
}

When a class that implements the original interface is compiled with the updated interface, then the code breaks. The old class does not implement the new, now required function g().

Name scoping

Another problem is the scoping of the method names in an interface definition. A class that implements an interface with function f() can not implement another interface with function f(). But what do you do if interfaces overlap in their function names? You could take the precaution of using rather large and descriptive names, but this often makes the interfaces less readable.