the anti-if campaign

I’ve just signed up to the Anti-If Campaign (link via Dave Nicolette). This is a movement to promote the use of strong object-oriented software design principles, by asking us to think twice before we allow any conditional branches into our code. This isn’t dogma, just a hook that can help direct our refactoring.

Long-time readers of this blog will know that I believe most conditionals to be duplication — see the following old posts for examples of my arguments here:

I’ve placed the Anti-If Campaign’s badge on my sidebar to show that I look hard at every conditional, and I invite you to do the same!


A bad citizen in Javaland by Darren Hobbs is a hilarious, and nightmarish, vision of what it would be like to live in most Java – or C# – software. Some of the problems arise from static typing, some from violation of the tell don’t ask principle, and most of the rest from the way we tend to design applications. Brilliant.

designing for testability

Achieving And Recognizing Testable Software Designs is part 1 of a series of articles in which Roy Osherove looks at design for testability. This first part defines “testability”, and then gives a few examples in which Roy refactors C# code to improve its testability. Clear and concise and well worth a read. I’ll be looking out for the next installment.

object thinking

I really must get around to reading Object Thinking. It gets a reasonable review from Darrell Norton among others, and Andy even uses it to support my own metrics!

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!

avoid boolean parameters

You are tempted to create a method with a boolean argument. The caller will set the argument to true or false depending on which code path he wishes the called method to take. This is an extremely convenient way to add a small degree of configurability to an algorithm, and means that both paths through the called method can share setup and cleanup code.

class MyClass

    void dosomething(boolean followPathA) {
        // setup
        if (followPathA)
            // pathA
            // pathB
        // cleanup

However, the use of a boolean argument reduces readability. For example, in a method such as
workspace.createFile(name, true), what does “false” mean? It is much more intention-revealing to call a method such as workspace.createTempFile(name). Furthermore, boolean arguments always create duplication, either of code or of responsibility, and often of a very insidious nature. This is because the called method contains a runtime test to decide between two different code paths, despite thet fact that the calling method already knows which branch it requires! The duplication not only wastes a little runtime, it also spreads knowledge and responsibility further than is necessary. The resulting code is more closely coupled than the design it represents. These effects are magnified exponentially each time the boolean argument is passed on in a further method call.

Therefore avoid the need for a boolean argument by creating two versions of the method, in which the meaning of the boolean is reflected in the names of the new methods. For example, replace

File createFile(String name, boolean istemp)


File createFile(String name)
File createTempFile(String name)

If the resulting new methods have similar logic, extract the duplicate code into shared methods that can be called by each.