imported>Unknown at 05:23, 7 February 2021

2021-02-07T05:23:37Z

New page

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

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

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]).

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:

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);

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:

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);

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.

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.

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.

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

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?

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.

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).

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

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.

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.

LawOfDemeter - Revision history

imported>Unknown at 05:23, 7 February 2021