In FluentInterface Martin Fowler describes an object design style that he and Eric Evans have termed “fluent”. This is not a new idea – see the Ruby libraries for many examples, and the Cascade and Yourself patterns from Kent Beck’s Smalltalk Best Practice Patterns. But I believe it is certainly a style that deserves wider recognition and use – try it today!
As many folks have mentioned, repeating a kata over and over can lead to new insights, even on code you thought you understood inside-out. Uncle Bob asked us all to help improve the name of a variable in a piece of code he’s worked dozens of times, and the feedback is enlightening. What looked like a simple naming problem reveals deeper issues with the design.
I like simple rules of thumb that will help developers create better, more adaptable designs. So here’s another: Never throw an exception. And if someone throws one at you, catch it immediately and don’t pass it on.
Why? Aren’t exceptions one of the mainstays of modern programming? Joel Spolsky outlines the basic arguments against throwing exceptions:
“…I consider exceptions to be no better than “goto’s”, considered harmful since the 1960s, in that they create an abrupt jump from one point of code to another. In fact they are significantly worse than goto’s…”
But then he goes on to give advice that I consider questionable at best, by suggesting that you catch exceptions quickly and convert them into return codes. I agree that they should be caught at the earliest possible moment, but I disagree with converting them into return codes. Because although that certainly makes the mechanism visible to the reader of the code, it still represents strong coupling where there should be none. The caller – or someone further back along the call stack – has to know about, and take action in response to, someone else’s problem. It seems to me that such coupling violates the pragmatic programmers’ tell don’t ask principle.
When it comes to coaching teams in object-oriented design, I’ve always had trouble finding good reading material to give out. Books I’ve tried include:
- Bertrand Meyer’s Object-Oriented Software Construction. Back in the early nineties this was just about all that was available. While it does emphasise the behavioural view of objects, the use of Eiffel doesn’t help, and there’s little help with concepts such as refactoring or the need to eliminate duplication.
- Rebecca Wirfs-Brock’s Designing Object-Oriented Software. I’ve always liked this book, but for some reason British Java programmers never seem comfortable with it. And again, it has little to say about code structure or quality.
- Kent Beck’s Smalltalk Best Practice Patterns. This is my favourite of the three, because the patterns directly apply to refactoring code into great designs. But again, I’ve found that Java programmers seem scared to death of reading smalltalk.
Is Object Thinking what I’ve been looking for? Or is there another book out there that can show talented programmers what great code looks like?
Update, 9 may 05
At last, I’ve found a very good candidate!