* http://www.ccs.neu.edu/home/lieber/LoD.html

다음은 http://www.pragmaticprogrammer.com/ppllc/papers/1998_05.html 중 'Law Of Demeter' 에 대한 글.

{{{~cpp 
So we've decided to expose as little state as we need to in order to accomplish our goals. Great! Now 
within our class can we just starting sending commands and queries to any other object in the system will-
nilly? Well, you could, but that would be a bad idea, according to the Law of Demeter. The Law of Demeter 
tries to restrict class interaction in order to minimize coupling among classes. (For a good discussion on 
this topic, see [APPLETON]). 
}}}

{{{~cpp 
What that means is that the more objects you talk to, the more you run the risk of getting broken when one 
of them changes. So not only do you want to say as little as possible, you don't want to talk to more 
objects than you need to either. In fact, according to the Law of Demeter for Methods, any method of an 
object should only call methods belonging to: 
}}}

{{{~cpp 
itself. 
any parameters that were passed in to the method. 
any objects it created. 
any composite objects. 
Specifically missing from this list is methods belonging to objects that were returned from some other 
call. For example (we'll use Java syntax here): 
}}}

        SortedList thingy = someObject.getEmployeeList();
        thingy.addElementWithKey(foo.getKey(), foo);

{{{~cpp 
This is what we are trying to prevent. (We also have an example of Asking instead of Telling in foo.getKey
()). Direct access of a child like this extends coupling from the caller farther than it needs to be. The 
caller is depending on these facts: 
}}}

{{{~cpp 
someObject holds employees in a SortedList. 
SortedList's add method is addElementWithKey() 
foo's method to query its key is getKey() 
Instead, this should be: 
}}}

        someObject.addToThingy(foo);

{{{~cpp 
Now the caller is only depending on the fact that it can add a foo to thingy, which sounds high level 
enough to have been a responsibility, not too dependent on implementation. 
}}}

{{{~cpp 
The disadvantage, of course, is that you end up writing many small wrapper methods that do very little but 
delegate container traversal and such. The cost tradeoff is between that inefficiency and higher class 
coupling. 
}}}

{{{~cpp 
The higher the degree of coupling between classes, the higher the odds that any change you make will break 
something somewhere else. This tends to create fragile, brittle code. 
}}}

{{{~cpp 
Depending on your application, the development and maintenance costs of high class coupling may easily 
swamp run-time inefficiencies in most cases. 
}}}

{{{~cpp 
Command/Query Separation
Now back to to the ask vs. tell thing. To ask is a query, to tell is a command. I subscribe to the notion 
of maintaining these as separate methods. Why bother? 
}}}

{{{~cpp 
It helps to maintain the "Tell, Don't Ask" principle if you think in terms of commands that perform a very 
specific, well defined action. 
}}}

{{{~cpp 
It helps you to think about class invariants if you class is primarily command based. (If you are just 
tossing data out, you probably aren't thinking much in the way of invariants). 
}}}

{{{~cpp 
If you can assume that evaluation of a query is free of any side effects, then you can: 
}}}

{{{~cpp 
use queries from within a debugger without affecting the process under test. 
create built-in, automatic regression tests. 
evaluate class invariants, pre- and post-conditions. 
}}}

{{{~cpp 
The last, of course, is why Eiffel requires only side-effect free methods to be called from within an 
Assertion. But even in C++ or Java, if you want to manually check the state of an object at some point in 
the code, you can do so with confidence if you know the queries you are calling will not cause anything 
else to change. 
}}}