Class Design “Algorithm”

• You’ll find many variations online and in textbooks… Here is one example:
• ooDesignHowTo
• Summary:
  • IDENTIFY CLASSES - Underline nouns and noun phrases in the problem description. These are candidate classes.
    • Combine duplicates and prune down to the key players.
  • IDENTIFY ATTRIBUTES/INSTANCE VARIABLES - These may be nouns that were pruned above. They capture the state of object. These are likely to be built-in types like int or String.
  • IDENTIFY RESPONSIBILITIES - These may appear as verbs in your problem description. What does it make sense for each Class to do.
• Useful for tackling “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.

MIMP Design

	Filled diamonds represent composition. An Image is composed of at least one pixel and those pixels generally cease to exist with the Image.
	Open diamonds represent aggregation. A MimpApp object may contain zero or one Image objects, but either could exist without the other.
	Dotted arrow represents dependency. ImageTransforms must interact with instances of Image and Pixel. Changing the public interfaces of Image or Pixel might require us to make changes to ImageTransforms.

Possible Design Change 1

vs.

• Notice that the ImageTransform methods are only used by MimpApp. Let’s get rid of ImageTransform and move those methods into MimpApp.
• How would this impact coupling and cohesion? Is it a good idea?
  • Reduces coupling (in a sense) by getting rid of one class altogether.
  • Impact on cohesion is disastrous! Makes code reuse impossible.
  • Not a good idea.

Possible Design Change 2

vs.

• Let’s move ImageTransform methods into Image class and make them non-static:
  • Image gray = colorImage.convertToGrayscale();
  • More “Object Oriented”.
• How would this impact coupling and cohesion? Is it a good idea?
  • Reduces coupling.
  • Negative impact on cohesion.
  • Not as bad as the last change, but still not a good idea.

Possible Design Change 3

vs.

• Create a separate Channel class to handle range limiting color values to 0-255.
• How would this impact coupling and cohesion? Is it a good idea?
  • Increases coupling and reduces cohesion.
  • Definitely not a good idea.

Design Change 4 (Arguably better!)

vs.

• Modify the Image class by removing getPixel/setPixel and replacing them with methods like:
  • getRed(int x, int y)
  • getGreen(int x, int y)
  • getBlue(int x, int y)
  • setPixelColor(int x, int y, int red, int green, int blue)
• (The Image class will still use Pixel objects internally)
• How would this impact coupling and cohesion? Is it a good idea?
  • Eliminates coupling between Pixel and ImageTransforms
  • Increases coupling between Image and Pixel
  • Maybe reduces the cohesion of Image
  • Good idea? Maybe!

Design Change 5 (Arguably better!)

vs.

• Get rid of the Pixel class entirely. Instead, Images contain two-dimensional arrays of length-three arrays containing the three color values.
• How would this impact coupling and cohesion? Is it a good idea?
  • Image class is still cohesive
  • Reduces coupling by removing an unneeded(?) class.
  • Good idea? Maybe!