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.

8-1

By Rick Mercer with help fromObject-Oriented Design HeuristicsArthur RielAddison-Wesley, 1996, ISBN 0-201-6338-X

Relationships amongst Objects

8-2

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

Outline

8-3

Relationship Between Objects

Object relationships occur when one object1. sends messages to an instance variables 2. sends a message to another object3. is passed as an argument in a message4. creates another object5. reference is returned from a message6. 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-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

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

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

Design HeuristicRiel'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-10

A Meal Class Wrap 3 Smaller Classes

Meloncost()

RestaurantPatron

Steakcost()

Meloncost()

Piecost()

RestaurantPatron

Steakcost()

Piecost()

cost()

Meal

8-11

Meal Wrapper Class

Encapsulation makes 4 messages look like oneContainment simplifies thingsRestaurantPatron collaborates with one object

now, instead of three

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

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

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

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

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

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

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

:POST p : Payment

:Sale

makePayment() 1: create()

2: addPayment(p)

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

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 programDangerous case of high coupling:

– Allow one object to use ins. vars. of another type

8-21

Coupling

Hard to say what high coupling isWill have some coupling: instance variables,

one object asks another for help, ...

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

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 methodAny well structured class (String)

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

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

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

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

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?

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

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)