googletesting: Breaking the Law of Demeter is Like Looking for a Needle in the Haystack

Breaking the Law of Demeter is Like Looking for a Needle in the Haystack

Monday, July 21, 2008

Miško HeveryLaw of Demeterclass Mechanic {
Engine engine;
Mechanic(Context context) {
this.engine = context.getEngine();
}
}MechanicContextMechanicContextMechanicContextEngine

Most applications tend to have some sort of Context object which is the kitchen sink and which can get you just about any other object in the system aka the service locator.

If you want to reuse this code at a different project, the compiler will not only need Mechanic and Engine but also the Context. But Context is the kitchen sink of your application. It tends to have reference to just about every other class in your system, hence the compiler will need those classes too. This kind of code is not very reusable.

Even if you don't plan to reuse the code, the Context has high coupling with the rest of the system. Coupling is transitive, this means Mechanic inherits all of the badness through association.

Your JavaDoc is not very useful! Yes, by examining the API I can see that the Mechanic needs Context, but Context is the kitchen sink. What does the mechanic really need? (If you don't have source code nearby than it may be hard to figure out).

Every time I have to write a test I have to create a graph of objects (the haystack) which no one really needs or cares for, and into this haystack I have to carefully place the needles (the real object of interests) so that the code under test can go and look for them. I have to create the Context just so when I construct the Mechanic it can reach in the Context and get what it realy needs, the Engine. But context is never something which is easy to create. Since context is a kitchen sink which knows just about everything else, its constructor is usually scary. So most of the time I can't even instantiate Mechanic, not to mention run any tests on it. The testing game is over before it even started.

Ok, but today we have fancy tools such as JMock and EasyMock, surely i can mock out Context. Yes, you can! BUT: (1) typical setup of a mock is about 5 lines of code. So your test will contain a lot of junk which will mask the real purpose of the test. (2) These tests will be fragile. Every time you refactor something in context, or how context interacts, you are running the risk of breaking your tests. (False negatives) (3) What if you want to test class Shop which needs a reference to Mechanic? Well then you have to mock out Context again. This mocking tax will be spread all over your tests. In the end the mocking setup will drown out your tests and make for one unreadable test base.

class Mechanic {
Engine engine;
Mechanic(Engine engine) {
this.engine = engine;
}
}class Monitor {
SparkPlug sparkPlug;
Monitor(Context context) {
this.sparkPlug = context.
getCar().getEngine().
getPiston().getSparkPlug();
}
}

2 comments :

Michael MrozekJuly 23, 2008 at 6:23 AM
@apexrally Yes, it does, although they wouldn't particularly help in this problem
ReplyDelete
Replies
MahtJuly 23, 2008 at 6:50 AM
FYI The needle referred to in the common phrase is not a sewing needle, it is a haystack needle, used for pinning the haystack together.

:)
ReplyDelete
Replies

Add comment

Testing Blog

Breaking the Law of Demeter is Like Looking for a Needle in the Haystack

2 comments :

Labels

Archive

Feed

Company-wide

Products

Developers