Events

1
CSC 335 Object-Oriented Programming and Design
A few more design considerations
2
Some Object-Oriented Design Guidelines

• Uses Relationships between objects
• Expert
• Low Coupling
• High Cohesion
• Polymorphism
• Dont Talk to Strangers

3
(Information) Expert

• What is most basic, general principle of
  responsibility assignment?
• Assign a responsibility to the object that has
  the information necessary to fulfill it.
• That which has the information, does the work.
• E.g., What software object calculates sales tax?
• What information is needed to do this?
• What object or objects has the majority of this
  information

4
Who constructs the needed object?

• What object creates an X?
• Ignores special-case patterns such as Factory.
• Choose an object B to create an X such that
• B contains X
• B closely uses X
• B has the initializing data for X

5
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 too
  many other classes, this is good
• High Coupling class is dependent on many others
• Change in one class could force changes in others
• Harder to understand in isolation
• Harder to reuse
• Guideline Assign responsibilities so that
  coupling remains low

6
Which is the better design?

• Since a POST records an instance of Payment,
  Creator suggests that POST constructs Payment
• Then POST asks Sale to add the new payment
• POST is coupled to Payment
• With this design, POST needs to know 2 classes

makePayment()
1 create()
POST
p Payment
2 addPayment(p)
Sale
7
An alternative design

• Try associating Payment with Sale
• In both designs, Sale is coupled to Payment
• Low coupling favors this 2nd design

makePayment()
1 makePayment()
POST
Sale
1.1. create()
Payment
8
Discussion

• Keep low coupling in mind when making design
  decisions
• Common forms of coupling
• Class B has an instance of Class X
• Class B has a method that references an instance
  of Class X
• Class B is a subclass of Class X
• Class B implements Interface X
• So coupling does occur, in any OO program

9
Coupling

• Choose inheritance carefully
• This is strong coupling
• Hard to say what high coupling is
• Will have some coupling instance variables, one
  object asks another for help, ...

10
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 can be bad
• hard to understand
• hard to reuse
• hard to maintain
• fragile constantly affected by change

11
Reconsider need to create Payment

• In the first design, POST appears to be doing
  little, so this is okay
• But when POST takes on more tasks, it could get
  bloated and increasingly incohesive
• Imagine POST doing 20 tasks
• The design above is a path towards lower cohesion

12
Design 2

• An alternative assigns the responsibility of
  creating the Payment to Sale, not POST
• This design supports lower coupling and higher
  cohesion
• These guidelines shouldn't be considered in
  isolation

13
High vs. Low Cohesion

• Booch High functional cohesion exists when the
  elements of a class "all work together to provide
  some well-bounded behavior"
• Examples of low cohesion
• One class is responsible for many things in
  different functional areas
• Example PokerGame arranges views, builds
  menus,...
• One class has sole responsibility of one complex
  task in one functional area
• Example Dealer does BettingRound, shuffles
  cards, maintains Player state, tells players what
  to do, ...

14
High Cohesion

• A class has moderate responsibilities in one
  functional are and collaborate with other classes
  to fulfill tasks
• Example Dealer 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.
• the view to show the hands and pot
• Small number of methods, highly related
  functionality, doesn't do too much

15
Benefits of High Cohesion

• Design is clearer and more easily understood
• Maintenance (bug fixes, enhancements, changing
  business rules) is easier
• The fewer classes that you touch the better
• Often allows for lower coupling

16
Polymorphism

• How to design for varying, similar cases?
• Assign a polymorphic operation to the family of
  classes for which the cases vary
• Dont use case logic
• E.g., draw()
• Square, Circle, Triangle

17
Law of Demeter Dont Talk to Strangers

• Try to avoid knowing about the structure of
  indirect objects
• Use the direct object that you need to know about
  and let that object talk to indirect objects
• From a method, messages can be sent to
• this object
• a parameter of the method (Player and Game)
• an instance variable of this object
• an object created within the method