Class Design "Algorithm"

• Useful for tacking "designer's block"

Some Criteria for Evaluating Designs

• Coupling
  • The degree to which two classes (or methods) are "tied together." How likely is it that changing the internals of one will require modification of the other.
  • We aim for LOW coupling.
• Cohesion
  • The degree to which the components of a class "hang together".
  • Each class class should represent a single well-defined idea.
  • We aim for HIGH cohesion.

SitRite3K Design

Dotted arrows represent a dependency.

Diamond represents aggregation.

Possible Design Change 1

• Let's combine the SeatingChart with SitRite3K.
  • Any call to step or solve can automatically update the display.
• How would this impact coupling and cohesion? Is it a good idea?
  • Trivially eliminates coupling between SeatingChart and SitRite3K
  • A major blow to cohesion. What happens when we want to port this to a phone app?
  • Poor cohesion can make it awkward to reuse a class in a different context.

Possible Design Change 2

• Give Student objects a reference to the SeatingChart they are in, and give the responsibility for moving themselves:
  • bob.moveTo(3,5)
  • Logic is similar to placeStudent.
  • No need for setRow and setColumn.
• How would this impact coupling and cohesion? Is it a good idea?
  • Increases coupling between Student and SeatingChart.
  • No real impact on cohesion.
  • Not necessarily a bad idea.

Possible Design Change 3

• Get rid of the Posse class. Instead Student objects maintain an ArrayList of friends.
• How would this impact coupling and cohesion? Is it a good idea?
  • Slightly reduces the cohesion of Student.
  • We lose the opportunity for the Posse class to provide Posse-specific functionality. E.g. PA3 introduces a Posse toString method.
  • On the whole, this is probably a good idea because it simplifies the overall implementation.

Possible Design Change 4

• Add code to the Student class for abbreviating names:
  • nathan.getName() -> "Nathan Sprague"
  • nathan.getAbbreviatedName() -> "N. Sprague"
  • Perhaps users have requested this option...
• How would this impact coupling and cohesion? Is it a good idea?
  • Reduces cohesion for the Student class. Better to create a Name class or a utility class that can perform these conversions.
  • Otherwise, creating a Teacher class will require us to copy-paste this functionality.