Implicit interfaces

Martin Fowler just wrote an entry on implicit interfaces. This actually would be very useful, but I think I can see why language designers wouldn’t adopt it (at least, not outright).

The idea behind an implicit interface is that classes are characterised by both type and behaviour, while an interface only has type. Type, to put it simply, is the set of messages (aka methods) that an object understands. In Java, you define a type whenever you declare a class or interface. You add a new message to the set the type understands when you declare a new method. You associate behavior with that message when you implement the method (a class avoids associating behavior by declaring the method abstract).

As should be obvious, a class logically has everything an interface has, plus extras. Indeed, in C++, “interfaces” are done as “pure virtual classes” – that is, a class with every method abstract and no state. If you strip the class of the extras, you get an interface. So, then, this example can make a bit of sense:

public class Foo {
   public void foo() { ... }
}

public class Bar implements Foo {
    public void foo() { /* new implementation */ ... }
}

This behaviour would be very useful, not least because it would mean all of the dynamic proxy techniques available for interfaces would be available for classes.

So why isn’t it? I think the big reason would be the final keyword. The final keyword makes a clear statement: this method (or class) always has this behaviour. So, you wouldn’t be able to “implement” a class that is final or has final methods. Martin said that Anders Heljsberg (lead designer of Delphi and C#) gave a similar reason – Heljsberg probably feels quite strongly about this, as he prefers classes and methods to be final by default (as it is in C#). But still, it would be a powerful technique for non-final classes, and worth submitting as an RFE to Sun.

Advertisements

Author: Robert Watkins

My name is Robert Watkins. I am a software developer and have been for over 18 years now. I currently work for people, but my opinions here are in no way endorsed by them (which is cool; their opinions aren’t endorsed by me either). My main professional interests are in Java development, using Agile methods, with a historical focus on building web based applications. I’m also a Mac-fan and love my iPhone, which I’m currently learning how to code for. I live and work in Brisbane, Australia, but I grew up in the Northern Territory, and still find Brisbane too cold (after 16 years here). I’m married, with two children and one cat. My politics are socialist in tendency, my religious affiliation is atheist (aka “none of the above”), my attitude is condescending and my moral standing is lying down.

8 thoughts on “Implicit interfaces”

  1. This sounds like what Objective-C does:

    http://en.wikipedia.org/wiki/Objective-C#Protocols

    “An informal protocol is a list of methods that a class can implement. It is specified in the documentation, since it has no presence in the language. Informal protocols often include optional methods, where implementing the method can change the behavior of a class. For example, a text field class might have a delegate that should implement an informal protocol with an optional autocomplete method. The text field discovers whether the delegate implements that method (via reflection), and if so, calls it to support autocomplete.”

  2. I really like this idea, in fact I’ve discussed this quite extensively with some colleagues a while ago. One problem, at least for Java, is public member variables. If you both extend a class with a public member variable ‘v’ and implement a class with another public member variable ‘v’, but with a different type. How should that be handled?

  3. Magnus,

    Interfaces don’t have non-static variables, so you won’t have any inheritance of instance variables. As such, you’ll only have static variables to contend with. I’d imagine that the same rules that cover this situation would apply:

    bc[java]..
    interface Foo {
    String ACTION = “wibble”;
    }
    interface Bar {
    String ACTION = “wobble”;
    }
    public class FooBar implements Foo, Bar {
    public static void main(String[] args) {
    System.out.println(ACTION); // what happens here?
    }
    }

    p. I could actually whack this in and try it, but I can’t be bothered. 🙂

  4. I’m aware that interface cannot have non-static variables, but IF you were allowed to implement classes, then it will be a problem. For instance (hopefully I get it right):

    bc[java]..
    public class K {
    public void foo();
    public String bar;
    }

    public class J { }

    public class B extends J implements K {
    public void foo() { System.out.println(“A”); }
    }

    p. clearly B instanceof J is true, B instanceof K is true and K instanceof K is true. Now lets use our classes

    K k = new K();
    K k2 = new B();

    k.bar = “Test” is allowed, but is k2.bar = “Test” allowed?
    If it is allowed, imagine J having a member variable, int bar, what will happen to k2.bar = “Test” then, still allowed? What about k2.bar = 3?
    If it is not allowed, then k2 instanceof K cannot really be true, can it?

  5. Ah… I see what you mean. A good point.

    However, the Java compiler already needs to deal with something similar – methods declared on interfaces with the same signature but differing return types. I’m sure this could be handled too – as a compile error.

  6. Also, people feel free to add new methods to classes whenever. Under this very common use case, you suddenly break every would-be implementor of your implicit interface. You can’t just add methods to interfaces on a whim.

  7. Dealing with classes that are final, have final methods or public variables is simple enough. These classes wouldn’t have the free interface.

    If you used it within a project, adding an abstract method isn’t a real problem. You just need to fix the appropriate code, as ever. Perhaps the class should be labeled “interface class” or some such.

    Binary operations cause problems. Typically you access the other object’s privates and don’t want to go through the public interface. Apart from subclassing, it becomes public or nothing.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s