jamesladdcode.com

I’m currently out of work and looking for a new job (let me know if you have a position), so I’m working on a Google Web Toolkit App which I will launch in beta in a few weeks.

I was writing this sort of code:

public void boolean isAccountBalanceInRange(float low, float high) {
    float balance = customer.getAccount().getBalance();
    return (balance > low && balance < high);
}

And I winced realizing that I was breaking the Law of Demeter by asking for information from an object rather than asking the object with the information to do the work. By doing this I was exposing innards of other objects that I didn’t need to know about, and should other parts of the code need to do the same “check” then they would be repeating the code, violating the DRY principle.

According to wikipedia the Law of Demeter says:

an object should avoid invoking methods of a member object returned by another method. For many modern object oriented languages that use a dot as field identifier, the law can be stated simply as “use only one dot”. That is, the code “a.b.Method()” breaks the law where “a.Method()” does not. There is disagreement as to the sufficiency of this approach.

Using this approach would mean that my method was not actually required, since the method would be moved to the Customer class, which was good as removing code always makes me happy. However, was I removing code or just moving it elsewhere?  This is where I wrestled with the same reasoning as others who disagreed with the Law Of Demeter. Was I making things better or worse?

The code now looked like this:

customer.isAccountBalanceInRange(low, high);

Hmmmn. The method I had written moved into the Customer class which in turn could ask the Account class if the balance was in range or it could just get the balance and do the check. After reflecting for a while it appeared to me that it was more useful for an account to have a method like “isBalanceInRange” than to leave it in the Customer class, so the Customer class just forwards the call onto the Account class.

While applying the Law Of Demeter it did feel like I was chasing a rabbit through a maze of burrows but it did occur to me, that now, the only Class that knew the actual “type” of an Account balance was the Account class and this felt right. Should the type of an Account balance change then there would be one class that had to handle this.

Most of the principles, rules and techniques have their trade offs and some appear to be more work than an alternative approach, however, when followed through I think the process of understanding the rules and principles improves more than just the code at hand.

Why the picture of mustache guy, because there is a similarity between the Hollywood Principle and the Law of Demeter, and who would want to expose their wallet to mustache guy ?

This entry was posted on Friday, January 23rd, 2009 at 7:22 am and is filed under software development. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.