Comments on: Unit Testing and the Law of Demeter

By: Herman Radtke

Herman Radtke — Thu, 25 Mar 2010 16:16:36 +0000

Looking at this post again, you are correct. This was just contrived example, but it definitely violates some OO principles. I can’t remember exactly what I was working on when I decided to post this, but it makes me want to review it and make sure I did not make the same mistake there.

Thanks for keeping me honest!

By: John Kleijn

John Kleijn — Thu, 25 Mar 2010 08:31:40 +0000

I am leaning toward disagreement about the parse method. Passing the subject of the parsing really doesn’t constitute a stateful interface in its current form (the method might as well have been defined as static). But lets say the parsing is a more involves process, that does require certain instance variables. Wouldn’t it then be more appropriate to “encapsulate the concept that varies”, and create a “PersonNameParser”? In fact, I think that would be more appropriate in any case, unless you intend the parsed name to be the default output (merged with “getFullName”).

My point is that I think it defeats the purpose of a domain object to request operations on the state of that same object. Actually I think you’ve done the exact opposite of Tell Don’t Ask. Tell Don’t Ask doesn’t mean “pass arguments instead of using internal state”, it means “decisions based entirely upon the state of one object should be made ‘inside’ the object itself”. And in trying to improve testability you actually violated that and broke encapsulation. Because the decision of what to use an argument to explode() has effectively been delegated to the client.

Sure, one should try to keep to the Law of Demeter to avoid “train wrecks” and improve cohesion on a package or application level, but I don’t think that extends to methods used within the same class to fetch internal state.

On a side note I think you have very nice blog here. I came across it when looking for info about Thrift for a HBase adapter I’m planning to write, but found a few other interesting topics as well. They have given me some ideas for my own blog as well.

By: Herman Radtke

Herman Radtke — Sun, 17 Jan 2010 20:10:33 +0000

The parseFullName method was a simple example, not something I was actually working on. It is obviously much more complicated than just splitting on spaces and thus, facilitates the need for unit testing this method.

I think the above idea applies best to methods that do some business logic like calculate or parse something. Even if the method is part of a large, highly coupled class, we can still tell the method what to parse/calculate/etc rather than let it ask. But there is obviously a trade off here: now something must know what to pass into that method. No problem If there is a service layer, but as you mention, most people just slap code in a controller and move on.

Maybe I will write another post showing how a service layer facilitates good design, which implicitly helps unit testing.

By: Miles Johnson

Miles Johnson — Sun, 17 Jan 2010 19:56:18 +0000

Nice post and easily understandable when it comes to unit testing. However, it seems this theory won’t really apply to applications that aren’t specifically low/loose coupled (Like most large web applications).

Also, when using parseFullName() in actuality, just seems it would be a lot longer to write. I guess it depends on the context of how you will be using it in your app.

$name = $this->parseFullName($this->getFullName());