IanG on Tap

Martin Fowler recently posted an entry on Implicit Interface Implementation. The basic idea is that Java and C# both offer two kinds of 'interface' that you can program against. There's the kind explicitly declared with the interface keyword. And there's also the set of methods offered by a class - that is, in a sense, an 'interface'.

I put 'interface' in quotes because it's a different kind of a thing from an interface in the C# or Java language sense. The big difference being that the latter kind of interface is wholly abstract - any class can choose to implement an interface. But the members of a class are associated with the class that defines them. A method Foo.Bar is different from Quux.Bar. And only the class Foo, or classes derived from Foo can implement Foo.Bar

Fowler's proposed 'implicit interface' is essentially a proposal to allow any class to provide an implementation of Foo.Bar even if Foo is a class.

This is really just an expression of a limitation one runs into from time to time with Java and C#. It's a helpful way of looking at it because it provides an insight into the nature of the problem.

The problem is this: sometimes it's useful to be able to pass some piece of code a different kind of object from the type it was expecting; sometimes, you can't do this in Java or C#.

The most fashionable example of where this is useful is unit testing. For example, a couple of years ago I was working on some C# code that used MSMQ. Obviously I wanted my unit tests to run the relevant code without hooking it up to a real message queue. So it'd be useful to provide my own mock MessageQueue object in order to test the code in isolation.

The problem is that if I write code like this in C#:

public void UseQueue(MessageQueue q)
{
    q.Send("Hello!");
}

that code expects to be passed something that's an instance of the MessageQueue type. I won't be allowed to compile code that tries to pass in something else. If I were to write my code in raw IL to avoid type checking, it'll be unverifiable. I'm hosed because it wants to call MessageQueue.Send, not IansMockMessageQueue.Send.

Actually I'm not completely stuffed in this particular case. By lucky chance, MessageQueue derives from MarshalByRefObject. This means I can get the remoting infrastructure to cruft up a transparent proxy for me. A transparent proxy is something that looks and feels like the real type, but isn't. It's just a runtime-generated shim, and it does nothing but notify the code of your choosing whenever something tries to do something to the object.

(Java supports a similar trick - that's what Fowler is referring to when he mentions 'dynamic proxies' towards the end.)

But it's a bit of a hack. It doesn't seem like the most direct way of expressing that you want to pass something that has the same 'implicit interface' as MessageQueue.

Moreover, this hack isn't always available. (At least not in C#.) You can only create transparent proxies for things that derive from MarshalByRefObject. If you're dealing with a type that doesn't, then you really are out of luck.

Dynamic Languages Don't Have This Problem

With a dynamically typed language you wouldn't get this problem, because the UseQueue method above wouldn't be specific about what kind of object it required as a parameter - it'd take anything. And so long as whatever you pass in had a Send method. We could write C# code that behaves the same way:

public void UseQueue(object q)
{
    q.GetType().GetMethod("Send").Invoke(q, "Hello!");
}

(Yes, I know it's not quite the same. This is broken for overloaded Send methods. But the fix is as straightforward as it is tedious, so I decided not to clutter the example.)

This is sometimes known as 'duck typing'. Ostensibly because it's based on the principle that if it walks like a duck and quacks like a duck, it is a duck. But that's actually a bad analogy. The reality is closer to: "If it walks and quacks, that's close enough for me - who cares if it happens to be Dr. Nick Riviera?" (This is a big fallacy with duck typing: you're never checking whether the way in which it walks and quacks is in fact like a duck. But that's a topic for another blog entry.)

Advocates of dynamic languages are already pouncing on Fowler's post and claiming that it's indicative of the inherent superiority of dynamic languages.

But here's the thing...

It's Got Nothing To Do with Being Dynamic

COM doesn't suffer from this problem either. And nobody would accuse COM of being dynamically typed.

(Well, OK, yes, there's Automation, but I'm not talking about IDispatch here. I'm talking about proper COM with its high-fibre vtbls.)

In COM, Fowler's need for implicit interfaces would never arise because everything's an interface. If you want to use an object in COM you have to do so via an interface. So you're always able to make your own implementation.

So we have two opposite ends of the spectrum - COM and dynamic languages. Both of them avoid the issue. Clearly static typing wasn't the problem. So what is the problem with C# and Java?

Mixing Interface with Class Considered Harmful

The problem Fowler describes only arises if you comingle the concepts of interface and implementation.

COM avoids the problem because the only way you can use an object is through an interface type that has no association with any particular class. Dynamic languages avoid the problem by avoiding the notion of an interface type entirely. Java and C# suffer from this problem because you can use the class as a poor kind of interface, thus binding yourself to the implementation, or something derived from it.

If you're disciplined enough, you can avoid the problem: just because you can program against a class doesn't mean you have to. You can use COM-style interface-based programming if you like. It's just a lot of work, particularly when it comes to using system and 3rd party components - you end up having to define interfaces and write shims for all of them!

What Fowler is suggesting is essentially something that automates this work. When someone writes a class, all the class members are essentially private, but you get an auto-generated interface representing what would otherwise be public members.

This would then enable any class to implement, say, Duck.Walk, indicating that not only is it walking, but that it is walking like a duck, and can therefore be treated as a duck.

Dynamic typing isn't necessary. What's necessary is a clean separation of interface from implementation. Clearly we should all go back to using COM. :)