Oct 21, R. McFadyen1 Pure Fabrication P Problem: You have a responsibility to assign to a class, but assigning it to a class in the conceptual model causes low coupling and/or high cohesion. Solution: Fabricate a class - create a class that is not found in your conceptual model, one that does not necessarily have a business meaning to the business person. Ch 22: GRASP Patterns Pure Fabrication Protected Variations (Law of Demeter)

Oct 21, R. McFadyen2 UserOrganization PayingOrganization ServiceTechnician ServiceManager FieldServiceProject Note: ServiceManager is highly coupled to other classes Organizes-work-for Install/repair-equipment schedules invoices compute-invoices-for performs pays-for 1..* 0..* * 0..* ServiceTask getPayor(): Patterns in Java, Volume 2 Fig 4.14

Oct 21, R. McFadyen3 Consider the tasks assigned to the ServiceManager: scheduling tasks scheduling projects scheduling technicians generating invoices These are central to the function of the service manager no reasonable class in the domain to assign this to, so using Pure Fabrication, fabricate a new class for this purpose

Oct 21, R. McFadyen4 UserOrganization Paying Organization ServiceTechnician ServiceManager FieldServiceProject Organizes-work-for Install/repair-equipment schedules invoices compute-invoices-for performs pays-for 1..* 0..* * 0..* ServiceTask getPayor(): Invoice Generator generateInvoices(): Note: Pure Fabrication preserves low coupling and high cohesion Patterns in Java, Volume 2 Fig 4.15

Oct 21, R. McFadyen5 Object Design P Behavioural decomposition Pure Fabrication can lead to this Classes are determined by behavioural grouping: managing persistent storage generating invoices Representational decomposition Classes represent real things found in the problem domain - clerks use registers to create sales comprising line items … Reduces the representational gap Objects do things that, in the real- world, are done to them. Design of objects divided into two groups:

Oct 21, R. McFadyen6 Protected Variations P 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. (p ) 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

Oct 21, R. McFadyen7 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.”

Oct 21, R. McFadyen8 Law of Demeter FRIENDS

Oct 21, R. McFadyen9 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 add a method to get a payment Suppose Register needs to find out the amount of the payment

Oct 21, R. McFadyen10 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 ()

Oct 21, R. McFadyen11 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 - see Parnas’ concept of information hiding on page 339 Objects are only sending messages to their friends getTenderedAmount () getPayment()

Oct 21, R. McFadyen12 Law of Demeter presentation: Karl J. Lieberherr; Northeastern University Article on Information hiding

Oct 21, R. McFadyen13 Recall UML Class Diagram BusRoute BusStopList BusStop BusList BusPersonList Person passengers buses busStops waiting 0..*

Oct 21, R. McFadyen14 BusRoute BusStopList BusStop BusList BusPersonList Person passengers buses busStops waiting 0..* Find all persons waiting at any bus stop on a bus route Collaborating classes:

Oct 21, R. McFadyen15 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 (); } Applying Law of Demeter - Partial Java Solution

Oct 21, R. McFadyen16 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); } } Applying Law of Demeter - Partial Java Solution