Relationships amongst Objects

Transcription

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

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

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 8-3

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 8-4

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); 8-5

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 8-6

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

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 8-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? 8-9

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

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

12 If you have instance variables, use them Containment implies a relationship, messages 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 8-12

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 8-13

14 Contained objects don t talk to their containers 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 8-14

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 8-15

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 ATM HaveACard? Card Reader getpin() Keypad displaypin() Display 8-16

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 8-17

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 makepayment() :POST 1: create() p : Payment 2: addpayment(p) :Sale 8-18

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

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 8-20

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

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 8-22

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) 8-23

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 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 8-25

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 8-26

27 Information Expert 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 8-27

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? 8-28

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 8-29

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) 8-30