Refactor to Delegation in preference to Abstract Classes

Minimize, eliminate, delegate, and routinize. Decide what’s important and forget the rest. — Donna N. Douglass.

I've noticed a few times that factoring the difference between subclasses into explicit delegation results in cleaner code that is easier to test, especially when I use mock objects. Perhaps this is a useful Mock Object testing pattern: Replace Duplicated Behaviour with Delegation Through an Interface.

I recently refactored some of the jMock code to hook customisable formatting into the code that generated error messages on test failure. The end result is that InvocationMocker objects — objects that represent expectations or stubs — delegate to a Describer interface when asked to give their description and the concrete describer can be set when the object is constructed. In this way, the objects of the generic framework can be configured to create error messages that reflect the high level API used to compose them.

As part of the refactoring, I found a subclass of InvocationMocker that existed just to override the default describe implementation (to give no description, as it happens). I replaced instantiations of this class with instantiations of the base class with a custom Describer. This is a much cleaner design and much easier to test. The delegation of the descriptions to a Describer object is very easy to unit test with mock objects; the existing implementation and the overridden version were only tested in the acceptance tests and not actually unit tested at all.

If we had originally factored the differences between base class and subclass into a separate object, and defined the interaction with that object with an interface, the Describer design would have been already implemented by the time we needed it. We would also have been better able to test our classes. We should have listened to our tests and pulled out that interface when we originally wrote the subclass of InvocationMocker.

Update: Ivan Moore has posted a good article about refactoring inheritance into composition and delegation.

Invasion of the Pod People

The other night I was at an alt.country gig where two DJs played tunes by linking their iPods into the PA system. Rather disappointing from my point of view: I'm an old fashioned kind of chap who thinks a DJ should follow tradition and spin vinyl. And a 7" 45 sounds better than an MP3. No, really, you get more top end from a 45.

Anyway, I digress. At some point a punter requested a song that the DJs hadn't brought with them. So he pulled his own iPod out of his pocket, plugged it into the system and played the song.

I have seen the future. The pod people are taking over!

Using Colourful Language

I realised recently that the dynamic mock object frameworks that I have worked on over the last few years are really an attempt to create embedded domain specific languages for specifying the expected outgoing calls of an object under test. The latest version of the dynamic mock object framework is jMock, written for the Java language. Java does not support embedded languages very well because of all the syntax it requires: round brackets here, curly braces there, square brackets somewhere else, type declarations and casts willy nilly. They all get in the way of what I want to write and read: the identifiers I have defined and literal values. It turns out that fiddling with the syntax colouring in Eclipse helps a great deal. Although the colouring rules are not fine grained enough to be perfect, slight changes in colour scheme have made my tests easier to read.

I would contend that the art of programming is the creation of languages in which you can express your solutions to problems in the application domain — that is, the creation of domain specific languages. Some programming languages, such as Forth, Haskell, LISP or Smalltalk, make it very easy to create domain specific languages because they provide the programmer with less instead of more. Each of those three languages has very little syntax, provides very few core abstractions and control structures, but gives the programmer powerful ways to combine existing abstractions into new abstractions. Java takes the opposite approach: it provides quite a few core abstractions with lots of syntax and limits the way that the abstractions can be smoothly combined. But we all know that Java is not the best language in the world. We use it for practical reasons and because the excellent tool support makes us very productive. So I tried a quick experiment to see if I could make my IDE of choice, Eclipse, support my use of a domain specific language.

My experiment involved fiddling with the syntax colouring to see if different colour schemes could make my mock object tests easier to read. Here's a test case displayed with the usual syntax colouring. The identifiers and values get a bit lost among all the brackets:

If I make the brackets the same colour as the background, the lines that set up expectations are now very descriptive, but the colour scheme is totally impractical for anything else. Furthermore, Eclipse gives the same colours to brackets as to commas, all operators and even decimal points!

But using 50% grey works nicely. Java's syntactic noise is still visible but now the identifiers and values stand out: