TITLE: Law of Demeter in a coding example [ Adapted from "How To Design Frameworks", by Ralph Johnson, p. 46 ] [ One of the primary goals of the Law of Demeter is to reduce coupling between code "modules". ] Law of Demeter says don't operate on contents of another object. Instead, move code that operates on its contents into the object. Example x->foo->bar(a, b) // violates L of D We should instead define a bar() function in class of x that performs bar(). x->bar(a, b) // better! Rule: convert expressions that manipulate an object into operations on the object. [ Although I understand what this is trying to do, I have a problem with interfaces that become "fat" for an object like "foo" which acts as a repository for many different objects. Perhaps someone would care to comment? -adc ]