nosewheelie

I’ve spent the last two afternoons helping friends with their introduction to all things agile course: Boost Kickstart. This is an excellent learning opportunity for all involved (students & coaches) and usually brings out some lively discussions. This course was no exception.

Towards the end of the first day I got to speaking with one of the students who turned out to be responsible for maintaining some code I wrote at a previous employer (this is always a good test of character!). He asked me a good question about using interfaces, when & why should he use them. I drilled down a bit and he was basically lamenting the fact that I had developed most of the code with an interface for every class. To him, this was very confusing as it meant he had to drill into the interface first, then the implementation in order to discover what the class was doing. This problem can be quickly overcome with decent tool support, the Command-Option-B trick in IntelliJ is one such feature.

Apart from having two classes that represent the same concept (in the worst case - anyone remember .c & .h files?), using interfaces on every concrete class is something I consider a good idea. The most practical reason for this is that when you are testing a class that uses an another class, the collaborator can be mocked out, while its concrete implementation can be closed off (using final in Java) to prevent concrete inheritance (we’ll have the close/open discussion another time).

This scenario brings out the usual reason interfaces are used in Java, when you have to implementations of something that represent the same “type”. In the testing example, the first implementation is the real one and the second the mock (probably constructed dynamically).

de Alfaro and Henzinger [1] comment on interfaces as follows:

Good interface design is based on two principles. First, an interface should expose enough information about a component as to make it possible to predict if two or more components are compatible by looking only at their interfaces. Second, an interface should not expose more information about a component than is required by the first principle [SourceInterface-based Design].

Here are some of the good points about using interfaces:

• Flexibility - Tests can use mock implementations. IoC containers can proxy implementations with transactions, logging etc. ORM tools (e.g. Hibernate) can proxy implementations that do lazy loads, etc.
• Limits the amount of behaviour you expose to only what is visible on the interface.
• Testing becomes easier. If you have a complex domain model for example, you don’t need to create large and cumbersome test data in order to create test objects, this becomes especially important if you have interdependencies between those objects at different levels in the graph.
• Classes that use DI to obtain dependencies don’t need to care what implementation they get, just its type. This may be the most important thing about interfaces, you only care about type not implementation.

Some would argue that f you’re doing the simplest thing, you should always just create the concrete class and then when you need it, pull out an interface. In my experience, you always need the interface, so it’s easier to always do it right off the cuff. Even someone I generally disagree with goes as far as saying that “a piece of code is completely “pure” if all the type names it uses start with I” (where an I represents an interface).

Languages such as Ruby don’t have interfaces (and also don’t allow final access modifier on classes) and hence avoid the interface argument altogether. This has its good points if you are into testability, but if you are looking for interfaces as contracts, this is arguably worse than Java.

I’ve conveniently avoided the whole contract debate (i.e. you should never be able to instantiate a concrete class directly & instead should get everything only by interface) for now, we can come back to that one later. We could also go further with the use of interfaces if Java allowed dynamic type composition, but alas it doesn’t…