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

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

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

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

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

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

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

Relational Formulation From object o of class x1, to get to x2, follow edges in the set POSS(x1,x2)={e | x1.( )*.<= 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. from x1 to x2 (from Company to Salary)

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

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

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.

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

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

Other LoDC Applications Growth plans for class graphs Constructing data structures

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