Talk only to your friends that share the same concerns (Law of Demeter for Concerns)

1. Talk only to your friends that share the same concerns(Law of Demeter for Concerns) Midterm Review February 2004

2. General • Many interpretations for “talk” and “friends”. • LOD = Only talk to your friends • LoDC = Only talk to your friends that share the same concerns • LoDC implies LoD • LoD: a module should not know about too many other modules. • LoD = Principle of Minimal Information

3. LoD: OO • Send messages only to preferred supplier objects. • Preferred suppliers:

4. LODC • Crossing boundaries. • Specify separately what is foreign • ClassGraph, Strategy, Visitor • LoD: organize inside a set of concerns • LoDC: separate outside concerns; concern-based growth phases; modularize each growth phase

5. Summing: LoDC • Find all Salary-objects: Traversal concern = WhereToGo concern: only deals with traversal • Visitor separately expresses: WhenAndWhatToDo. Describes where traversal is extended • Start: c = 0 • Salary: c+=value

6. Weaving • cg.traverse(o, whereToGo, whatAndWhereToDo); • Weaves four concerns: • Structure concern (cg) • Instantiation concern (o) • Traversal concern (whereToGo) • Collaboration concern (whatAndWhereToDo)

7. How do we find all Salary objects • Follow LoD, not good enough • Follow DRY • Abstract from class graph • From Company to Salary • And not: Company.divisions.departments. workGroups.employees.getSalary() (not legal in Java, but legal in UML (OCL))

8. from x1 to x2 (from Company to Salary) Relational Formulation From object o of class x1, to get to x2, follow edges in the set POSS(x1,x2)={e | x1 <=.e.=>.(<=.C.=>)*.<= x2 } Can easily compute these sets for every x1, x2 via transitive-closure algorithms. POSS = abbreviation for: following these edges it is still possible to reach a x2-object for some x1-object rooted at o.

9. Adaptation Dilemma • When a parameterized abstraction P(Q) is given with a broad definition of the domain of the allowed actual parameters, we need to retest and possibly change the abstraction P when we modify the actual parameter, i.e., we move from P(Q1) to P(Q2).

10. Consequence of Adaptation Dilemma • When class graph changes, need to test all strategies

11. Producing Traversal code • For some class graph and strategy combinations we might produce a large number of traversal methods if we are not careful (exponential in worst case). • D*J (DemeterJ, DJ, DAJ) avoid this problem. Have built-in efficient code generation.

12. PaperBoy Example • // customer.wallet.totalMoney; • // customer.apartment.kitchen. kitchenCabinet.totalMoney; • // customer.apartment.bedroom. mattress.totalMoney;  • we widen the interface of the Customer class and add a method • int customer.getPayment(..)

13. Implications of LoD • A general problem of following the LoD is that it leads to wide class interfaces because there are so many ways of traversing through a complex object structure for different purposes. • Use abstraction to organize the wide interfaces using the strategy language

14. Other LoDC Applications • Growth plans for class graphs • Constructing data structures

15. Other Applications of LoD • Object creation • Constructor call: call on a class object • Minimize number of such calls follows the LoD (Principle of Minimal Knowledge) • A.parse(“object description”)