Posts
Hy all,
Remember Law of Demeter? Wel, here is what is it about (transcript from Wikipedia):
“The Law of Demeter (LoD), or Principle of Least Knowledge, is a design guideline for developing software, particularly object-oriented programs. The guideline was invented at Northeastern University towards the end of 1987, and can be succinctly summarized as “Only talk to your immediate friends.” The fundamental notion is that a given object should assume as little as possible about the structure or properties of anything else (including its subcomponents)…..
When applied to object-oriented programs, the Law of Demeter can be more precisely called the “Law of Demeter for Functions/Methods” (LoD-F). In this case, an object A can request a service (call a method) of an object instance B, but object A cannot “reach through” object B to access yet another object, C, to request its services. Doing so would mean that object A implicitly requires greater knowledge of object B’s internal structure. Instead, B’s class should be modified if necessary so that object A can simply make the request directly of object B, and then let object B propagate the request to any relevant subcomponents. Or A should have a direct reference to object C and make the call directly. If the law is followed, only object B knows its own internal structure.
More formally, the Law of Demeter for functions requires that a method M of an object O may only invoke the methods of the following kinds of objects:
- O itself
- M’s parameters
- any objects created/instantiated within M
- O’s direct component objects
In particular, 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.
The advantage of following the Law of Demeter is that the resulting software tends to be more maintainable and adaptable. Since objects are less dependent on the internal structure of other objects, object containers can be changed without reworking their callers…..” (read the whole thing here)
Following this today I rad into an interesting article called Dependency Injection Myth: Reference Passing which lead me to another interesting reading:
Breaking the Law of Demeter is Like Looking for a Needle in the Haystack.
After I have read these it made me thinking about how true the facts are…
These days I am working on a middle ware project which consists in implementation of a communication layer between a third party application and the product developed by my company. Challenging indeed, but there is small problem… I have already implemented almost 80% of what the mw needs to do bu I am facing the problem of how to make a test suite to validate what I have done.
After spending some time to think about it, more and more I have the feeling that I have done something wrong…I made something almost untestable, or at least testable but requiring a whole bunch of work to implement a real test suite…hmm. I think I am kind of near the haystack thing mentioned by Miško Hevery in his post…
I think its time to sit back and revise the thing… to make sure that it complies with the Law of Demeter, and after that rethink the testing startegy.
Have ever been in this kind of situation? Did you managed to make something so hardly testable that the effort of implementing a test suite would be to high?
Well welcome in the club…
Until next time…
Happy coding, and happier testing 
I am glad that you have a realization that what you have created is hard to test. You fall into very elite group, most people think that they code is awesome as it stands and there is nothing which needs to be improved. Kodos to you on self reflection!
Turns out writing un-testable code is easy! We don’t even know how we are so good at it. Writing testable code is had and requires a lot of known how about how to design your code. Ask this to your co-workers: “Suppose you are an evil developer and want to write hard to test code. How do you do it?” You will see that most people will not be able to answer it, even thought their code is hard to test.
I have a link for you which I think will answer some of your questions.
http://misko.hevery.com/2008/11/04/clean-code-talks-unit-testing/
Nice presentation…indeed.
You know, in last job I had the opportunity to get in touch with a whole bunch of quality improvement measures, most of them related to testing strategies, and I have to say that I was kind of against them because back than those were more an overhead than a helpful thing (at least it felt like for me). Now, since nobody is putting pressure on the development team to maintain a quality standard, with unit testing and stuff, I am kind of crying back the old days. From my experience I have to say that if a developer is not “forced” to write unit tests, he will never write unit tests only from his initiative… sad but true… and that can lead to chaos.
So project managers, please concentrate also on quality, even if the developers are fighting against, just ensure that a minimal code quality is maintained. It will pay of later, you’ll see.