1. Fall 2009ACS-3913 R. McFadyen1 Protected Variations Principle: How do you design so that variations in the future do not have an undesirable affect on other elements? Solution Identify points of variation and assign responsibilities to create a stable interface around them

2. Fall 2009ACS-3913 R. McFadyen2 Law of Demeter A special case of Protected Variations Also called Don’t Talk to Strangers … to protect oneself from class diagram changes Each class should only use a limited set of other classes: only units “closely” related to the current unit. “Each class should only talk (send messages) to its friends.” “Don’t talk to strangers.”

3. Fall 2009ACS-3913 R. McFadyen3 Law of Demeter If objects traverse long object structure paths and send messages to distant, indirect (stranger) objects, the system is fragile with respect to changes in the object structures - a common point of instability in systems. LoD helps us avoid creating such designs

4. Fall 2009ACS-3913 R. McFadyen4 Law of Demeter FRIENDS

5. Fall 2009ACS-3913 R. McFadyen5 Don’t Talk to Strangers PaymentRegisterSale getTenderedAmount() paymentAmount() endSale() enterItem() makePayment()... becomeComplete() makeLineItem() makePayment() getTotal() getPayment... The class diagram shows that Register knows about Sale, and Sale knows about Payments that have been made towards it a method to get a payment Suppose Register needs to find out the amount of the payment

6. Fall 2009ACS-3913 R. McFadyen6 Don’t Talk to Strangers Assume: Register has a paymentAmount method which returns the current amount tendered for the payment Sale has a method, getPayment, which returns the Payment instance associated with the Sale Consider: In order to return the payment amount, we could have a paymentAmount method in Register such as: public void paymentAmount() { Payment payment = sale.getPayment() Money amount = payment. getTenderedAmount () }

7. Fall 2009ACS-3913 R. McFadyen7 Don’t Talk to Strangers :Payment :Register:Sale The previous has messages: Register will have a dependency on Payment This increases the coupling in our system getPayment() getTenderedAmount ()

8. Fall 2009ACS-3913 R. McFadyen8 Don’t Talk to Strangers :Payment :Register:Sale If getPayment() in Sale would invoke getTenderedAmount() in Payment, and return the payment amount, then we can de- couple Register from Payment make the solution more robust, less sensitive to changes, less coupling Register will get the payment amount it is after, but it won’t know how it was obtained Objects are only sending messages to their friends getTenderedAmount () getPayment()

9. Fall 2009ACS-3913 R. McFadyen9 Law of Demeter presentation: www.ccs.neu.edu/research/demeter/talks/frameworks/ubs/LoD.ppt Karl J. Lieberherr; Northeastern University other resources www.ccs.neu.edu/research/demeter/ www.ccs.neu.edu/home/lieber/LoD.html Article on Information hiding http://www.stevemcconnell.com/ieeesoftware/bp02.htm Aside – if you have an interest