1 / 14

More GRASP Patterns

More GRASP Patterns. Polymorphism Indirection Pure Fabrication Protected Variations (Law of Demeter). Protected Variations. Problem : How do we design systems so that changes in its elements do not have an unfavourable impact on other elements?

Download Presentation

More GRASP Patterns

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. More GRASP Patterns • Polymorphism • Indirection • Pure Fabrication • Protected Variations (Law of Demeter) 92.3913 R. McFadyen

  2. Protected Variations • Problem: How do we design systems so that changes in its elements do not have an unfavourable impact on other elements? • Solution: Identify points of predicted variation/instability and assign responsibilities to create a stable interface around them • Example: • Law of Demeter (LoD) • Special case of this pattern. • 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 92.3913 R. McFadyen

  3. Law of Demeter • Also called Don’t Talk to Strangers • 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.” 92.3913 R. McFadyen

  4. Law of Demeter FRIENDS 92.3913 R. McFadyen

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

  6. 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() • } A little different from the text’s example 92.3913 R. McFadyen

  7. Don’t Talk to Strangers The previous has messages: :Register :Sale • getPayment() Register will have a dependency on Payment This increases the coupling in our system • getTenderedAmount() :Payment 92.3913 R. McFadyen

  8. Don’t Talk to Strangers • 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 • getPayment() :Register :Sale Register will get the payment amount it is after, but it won’t know how it was obtained - see Parnas’ concept of information hiding on • getTenderedAmount() Objects are only sending messages to their friends :Payment 92.3913 R. McFadyen

  9. 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 • www.computer.org/certification/beta/McConnell_Missing.html 92.3913 R. McFadyen

  10. Example: Applying LoD as system changes busStops BusRoute BusStopList buses 0..* BusStop BusList waiting 0..* passengers Bus PersonList Person 0..* 92.3913 R. McFadyen

  11. Find all persons waiting at any bus stop on a bus route Collaborating classes: busStops BusRoute BusStopList buses 0..* BusStop BusList waiting 0..* passengers Bus PersonList Person 0..* 92.3913 R. McFadyen

  12. Applying Law of Demeter - Partial Java Solution class BusRoute { BusStopList busstops; void printWaitingPassengers () { busstops->printWaitingPassengers (); } } class BusStopList { BusStop stops[]; void printWaitingPassengers () { for (int i = 0; i < stops.length; i++) stops[i].printWaitingPassengers (); } } 92.3913 R. McFadyen

  13. Applying Law of Demeter - Partial Java Solution class BusStop { PersonList waiting; void printWaitingPassengers () { waiting.print (); } } class PersonList { Person people[]; void print () { for (int i = 0; i < people.length; i++) people[i].print (); } } class Person { String name; void print () { System.stdout.println (name); } } 92.3913 R. McFadyen

  14. Suppose the class model is modified to incorporate Villages. What software changes are needed and still adhere to LoD? villages BusRoute BusStopList buses VillageList busStops 0..* 0..* BusStop BusList Village waiting 0..* passengers Bus PersonList Person 0..* 92.3913 R. McFadyen

More Related