lec00 csu670 f06

Software Development UsingProper Separation of Concerns:Talk only to your friends who share your concerns(Law of Demeter for Concerns): 

Software Development Using Proper Separation of Concerns: Talk only to your friends who share your concerns (Law of Demeter for Concerns) Theme/Introduction

General: 

General Many interpretations for “talk” and “friends”. LOD = Only talk to your friends LoDC = Only talk to your friends who share your concerns LoDC implies LoD LoD: a module should not know about too many other modules.

LoD: OO: 

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

LODC: 

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: 

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: 

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: 

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

Relational Formulation: 

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. from x1 to x2 (from Company to Salary)

Adaptation Dilemma : 

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: 

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

Producing Traversal code: 

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: 

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: 

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: 

Other LoDC Applications Growth plans for class graphs Constructing data structures

Other Applications of LoD: 

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