1. 8-1 By Rick Mercer with help from Object-Oriented Design Heuristics Arthur Riel Addison-Wesley, 1996, ISBN 0-201-6338-X Relationships amongst Objects

2. 8-2  Consider six relationships between objects  Offer some guidelines for better OO design – A few design heuristics – Low coupling and high cohesion Outline

3. 8-3 Relationship Between Objects  Object relationships occur when one object 1.sends messages to an instance variables 2.sends a message to another object 3.is passed as an argument in a message 4.creates another object 5.reference is returned from a message 6.stores a referential attribute A reference to an object needed by other objects –Example: Jukebox stores a reference to a JukeboxAccount stored in a JukeboxAccountCollection

4. 8-4 Object A sends message to Object B  #1 A uses relationship occurs when one object sends a message to another object. Example: – a listener sends an updateUI() message to a JList object private class ButtonListener implements ActionListener { public void actionPerformed(ActionEvent event) { … rollInputField.setText(""); // set text field to blank }  The sender, the new ButtonListener() object, must know the receiver's name: rollInputField

5. 8-5 Example: Cars and Gas Stations  #2 If a Car "contains" a gas station instance variable – send a fillUp message to its own gas station this.fillUp(Exxon126);  If a Car does not "contain" a gas station – how can a Car send a fillUp message?  #3 A Car could be given the name of the gas station ( Exxon126 ) as an argument // aDispatcher object sends this message car[currentCar].fillUp(Exxon126);

6. 8-6 Other uses relationships  #4 Let the car find a gas station on its own – Assume map is a global variable everyone knows myGasStation = map.getNearestGasStation(); myGasStation.fillUp();  #5 Whenever a car needs gas, let the car build it – It will know the name of the object it creates construct a new one in the Cars fillup method – Note: the gas station will be destroyed upon exit

7. 8-7 Who constructs needed objects?  What object creates object X?  Choose an object B to create an X such that: – B contains X – B closely uses X – B has the initializing data for X

8. 8-8 Referential attribute (can be bad)  #6 Store a reference to a gas station that was created elsewhere – Known to some as a referential attribute – This provides access to an entire object that was constructed elsewhere – The car has a reference needed by someone else  Be careful: This can lead to incorrect behavior – Could be better to have just one instance with a global point of reference

9. 8-9 Design Heuristic Riel's Heuristic 4.1 Minimize the number of objects with which another object collaborates Worst case: The design has a collection of simple objects where each one uses all others Could one class contain several smaller objects?

10. 8-10 A Meal Class Wrap 3 Smaller Classes Melon cost() Restaurant Patron Steak cost() Melon cost() Pie cost() Restaurant Patron Steak cost() Pie cost() Meal

11. 8-11 Meal Wrapper Class  Encapsulation makes 4 messages look like one  Containment simplifies things  RestaurantPatron collaborates with one object now, instead of three

12. 8-12 If you have instance variables, use them Containment implies a relationship, mess- ages should be sent to contained objects If no messages are sent to a contained object, it doesn't belong, Put the attribute in the right class  An exception: Container classes – ArrayList, HashMap, TreeMap, and so on, may not send messages to their elements other than equals or compareTo message Their job is to add, find, and remove elements

13. 8-13 Don't use too many instance variables Most of the methods in a class should be using most of the instance variables most of the time If not, perhaps there should be two classes Classes should not contain more objects than a developer can fit in short term memory Maximum should be 7 plus or minus 2 That's about 5 to 9 instance variables

14. 8-14 A class must know what it contains, but the contained class should not know who contains it – It's okay for a bedroom to know it has a clock, but the clock should not be dependent on the bedroom – currentAccount should not send messages to Jukebox – The JukeboxAccountCollection need not know it is contained in an instance of Jukebox All contained objects are loosely coupled –they are not very dependent on each other Contained objects don’t talk to their containers

15. 8-15 Use a Mediator to Coordinate Activities Objects that share lexical scope -- those in the same containment --need not have relationships between them  Consider an ATM that contains a card reader and a display screen – The card reader should not send a message to the display screen better reuse--could use the card reader software for a security entrance without taking the display screen

16. 8-16 Violation Increases Complexity  An ATM may contain – card reader, display screen, and keypad – The ATM should coordinate activities between these three objects Don’t need additional collaborations HaveACard? Card Reader displayPIN() getPIN() Display Keypad ATM

17. 8-17 Coupling  Coupling: A measure of how strongly one class is connected to, has knowledge of, or relies upon other classes – Low coupling: the class is not dependent on many other classes--good – High Coupling: class is dependent on many others--bad A change to one class forces changes in others More difficult to understand a type in isolation Assign responsibilities so that coupling remains low

18. 8-18 Which is the better design?  If a POST object records an instance of Payment, perhaps the POST object constructs Payment  Then POST asks Sale to add the new payment – POST is coupled to Payment in the following design With this design, POST needs to know 2 classes :POSTp : Payment :Sale makePayment()1: create() 2: addPayment(p)

19. 8-19 An alternative design  Try associating Payment with Sale – In both designs, Sale is coupled to Payment – Low coupling favors this 2nd design :POST:Sale :Payment makePayment()1: makePayment() 1.1. create()

20. 8-20 Try to keep coupling low  Common forms of coupling – Class B has an instance of Class X – Class B send a message to an instance of Class X – Class B is a subclass of Class X (inheritance) – Class B implements interface X  So coupling does occur, in any OO program  Dangerous case of high coupling: – Allow one object to use ins. vars. of another type

21. 8-21 Coupling  Hard to say what high coupling is  Will have some coupling: instance variables, one object asks another for help,...

22. 8-22 High Cohesion  Assign responsibilities so that cohesion remains high cohesion: consistency, pulling together  Cohesion: A measure of how strongly related and focused the responsibilities of a class are – High functional cohesion is good – Low cohesion is bad hard to understand hard to reuse hard to maintain fragile; constantly affected by change

23. 8-23 Several types of cohesion  Functional cohesion is when parts of a module are grouped because they all contribute to a single well-defined task of the module  Examples  Tokenizing a string of XML  BankAccount has no blast off method  Any well structured class (String)

24. 8-24 High vs. Low Cohesion  High functional cohesion exists when the elements of a class "all work together to provide some well-bounded behavior" Grady Booch  Examples of low cohesion – One class is responsible for many things in different functional areas Example: Model arranges views, builds menus,... – One class has sole responsibility of one complex task in one functional area Example: Jukebox determines if a song can play, an account may play, play the mp3 by itself, maintain collections with add, find, remove,....

25. 8-25 High Cohesion  A class has moderate responsibilities in one functional area and collaborates with other objects to fulfill tasks: – e.g. PokerDealer coordinates but gets help from a deck of cards that can shuffle and deal cards the player that can figure out what to do next and knows what he or she can bet a view to show poker hands, pot, cards, animations  Small number of methods, highly related functionality, doesn't do too much

26. 8-26 Benefits of High Cohesion  Design is clearer and more easily understood  Maintenance (bug fixes, enhancements, changing business rules) is easier – The fewer classes you touch the better Adele Goldberg  High cohesion can help you attain lower coupling

27. 8-27  The most basic, general principle of assigning responsibilities (behavior/methods) is to – Assign the responsibility to the object that has the information necessary to fulfill it. – “That which has the information, does the work.” – Who decides if the jukebox object can select?  Important skill in OO Design: – Which objects should do what? Find objects Assign responsibilities Information Expert

28. 8-28 Role Play a Scenario Jukebox: Now I need to determine whether or not the current user can play the selected Song. Who is responsible for knowing the playing time of any Song? Song: It seems like I should be responsible for knowing the duration of my Song. For example, it might take 3 minutes and 34 seconds to be completely played. I'll add the responsibility knowPlayTime. Jukebox: Okay, now I should check to make sure the user is able to select this Song before telling the AudioFilePlayer to play it. I seem to remember I cannot simply play a Song without checking on a few things. I know the current JukeboxAccount and the selected Song. What do I do now?

29. 8-29 Alternative #1 JukeBox: So tell me Song, how many minutes and seconds do you require to be played? Song: 3 minutes and 34 seconds. JukeBox: JukeboxAccount, do you have 3 minutes and 34 seconds credit? JukeboxAccount: I'll be responsible for maintaining remaining time credit, so I can answer that, Yes, I have enough credit. JukeBox: JukeboxAccount, have you played fewer than 2 Songs? JukeboxAccount : I have not played 2 songs today. JukeBox: Okay, now we can play the Song. Here it is AudioFilePlayer. AudioFilePlayer : Okay JukeBox, I am willing and able to play this Song. I'll take care of the playTrack(String fileName) responsibility

30. 8-30 Alternative #2 JukeBox: JukeboxAccount, can you play this Song? JukeBoxAccount: It feels as though I should be responsible for maintaining my own time credit, it seems appropriate that I should also know how many Songs I've played today. So I should be able to do some simple calculations to give you the answer you seek. Yes JukeBox, I can play the Song you sent me. I'll add these responsibilities to my CRC card: know how much time credit I have left know how many Songs I've played on this date respond to a message like this: JukeboxAccount.canSelect(currentTrack)

31. 8-31 Which Alternative is better?  Alternative #1 has a higher degree of coupling" – Jukebox needs to know more details about Song and JukeBoxAccount – There were two different message sends in alternative #1 versus a single message send of alternative #2 (canSelect)  Alternative #2 has better cohesion – This means that at least two of the knowledge responsibilities necessary to answer a canSelect message are closely related

32. 8-32 Which is the better design?  Alternative #1 requires Jukebox to know about the internal state of Song and JukeBoxAccount – Violation of "All data should be hidden within its class"  Alternative #2 better delegates responsibility  Alternative #2 has fewer message sends  Here is another OOD guideline to indicate Alternative #2 is a better design: Minimize the number of message sends between a class and its helpers

33. 8-33 Expert Problem: We are trying to determine who should be responsible for some action Solution: Assign the responsibility to the information expert, which is the class with information necessary to fulfill the responsibility

34. 8-34 Collaborative Exercise: Course scheduling  How should we check if a student has the proper prerequisites before adding a course given these three types (Java classes) – Course description, enrollment limit, prerequisites – Student name, address, SS#, courses taken – CourseOffering course number, schedule, room, registrants