This Wednesday (April 22nd) we’ll have another coding dojo at Skillsmatter. This time the challenge will be the Poker Hands:
[...] Your job is to compare several pairs of poker hands and to indicate which, if either, has a higher rank.
Here’s some initial code generated at a previous dojo that may serve as starting point for the solution. The session format will be a Randori, which means everyone is welcome to code.
As usual, registration is required and should be done at Skillsmatter’s website. If you have any questions or suggestions for this session please feel free to participate in the Coding Dojo London mailing list.
Reading Mark Needham’s post about how inexpressive an API can be when using booleans in method parameters, another clear example came to my mind.
A few weeks ago we were using a method similar to the following:
public List listUsers(boolean showDisabled);
We’d expect that once you call this method passing false, it would return all enabled users and if the parameter is true it included all the disabled users in this list, right? Well, not exactly.
Only when we tried passing true we discovered it actually listed ONLY the disabled users. And unfortunately it was simply impossible to predict this behavior by reading the interface.
What if we used a better representation for this boolean instead?
public enum UserFilter {
ENABLED_ONLY, DISABLED_ONLY;
}And the interface now would look like:
public List listUsers(UserFilter filter);
Notice that I didn’t change any behavior, but now it’s clear what this method call will return:
myUsers = service.listUsers(UserFilter.ENABLED_ONLY);
Besides, if we were really interested in having a list including ALL the users, we could easily extend the filter without having to change the original method or loosing in readability.
The problem with booleans is that they are intentionally inexpressive. They are an essential part of our code when it comes to evaluate conditions and control the flow of execution, but when it comes to define domain-specific concepts, my gut feeling says in most cases they should be avoided.
Is it just me who’s loving this whole Ruby vs. Scala debate going on lately? So far it shows that:
- No language can prevent bad code.
- There will be never an ultimate language, but there will always be people to defend the one they are using.
- Java (the language, not the platform) is dead.
I know it’s not the first time we have a language war and I have to confess I was missing that a little. Years ago it was Visual Basic vs. Delphi, then C++ vs Java, now it’s Ruby vs. Scala. And I have to confess: I’m already curious to see what will be the next one.