다음은 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):
~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.
