Building Quality Classes and Objects

1
Lesson 5

• Building Quality Classes and Objects

2
The Relationship between Classes and Objects

• Classes and objects are closely related concepts
• Every object is an instance of some class.
• Every class has zero or more instances.
• Classes are usually static.
• Their definition is fixed prior to program
  execution.

3
Relationship (continued)

• The class of most objects is static.
• Once created, an object doesnt change its class.
• Objects are created and destroyed frequently as a
  program runs.

4
Classes and Objects in Analysis and Design

• During analysis, the developer identifies the
  classes and objects (key abstractions) in the
  problem domain.
• During early design, the developer invents
  structures (mechanisms) so objects can work
  together to satisfy system requirements.

5
Classes (continued)

• Classes and objects are viewed from the outside
  in these two phases.
• The logical framework is built using the class
  and object structure.
• During late design and implementation, the
  developer shifts attention to the inside view.
• The physical representation is built using models
  of modules and processes, and with actual code.

6
Measuring the Quality of Classes and Objects

• The design of classes and objects is incremental
  and iterative.
• The quality of design can be measured with the
  following metrics
• Coupling the degree to which classes are
  interconnected.
• Loose coupling is generally best. However,
• Inheritance tightly couples superclasses and
  their subclasses, to exploit common structure
  behavior.

7
Measuring (continued)

• Cohesion the degree to which all elements of a
  class work together for a unified purpose.
• High, functional cohesion is best.
• Sufficiency does the class provide enough
  functionality to be useful?
• Completeness does the class provide all needed
  operations?
• Is subjective, and can be overdone.

8
Measuring (continued)

• Primitiveness does the class provide only
  low-level operations?
• Most high-level operations can be composed of
  low-level operations.

9
Choosing Class Operations

• Must decide on the size of a classs methods.
• Large, complicated methods leads to a simple
  class interface with few methods.
• Small, simple methods lead to a more complicated
  interface with many methods.
• Need an appropriate balance
• Fragmentation vs. large, unwieldy modules.

10
Choosing (continued)

• Must decide how long a method can take to
  complete.
• Must decide how much storage a method can
  consume.
• If concurrency is used, you must decide how
  objects and methods are synchronized.

11
Choosing Class Relationships

• Must decide how classes will collaborate.
• What part of the class will be accessible to
  others?
• Best if classes are loosely coupled i.e. a
  class should rely on only a few other classes.
• Must decide if the inheritance hierarchy is wide
  and shallow, narrow and deep, or balanced.

12
Choosing (continued)

• Must decide if a class relationship one of
• inheritance
• aggregation
• using
• Must decide how one object is visible to another
• The supplier object is global to the client.

13
Choosing (continued)

• The supplier object is a parameter to some method
  of the client.
• The supplier object is part of the client object.
• The supplier object is locally declared and
  created in a method of the client object.

14
Choosing Class Implementations

• The representation (or internal structure) of a
  class should be an encapsulated secret.
• The representation can change, without affecting
  client classes.
• May have to trade off time and space.
• Must decide whether to compute a value, or store
  it.
• E.g. compute or store area in the Circle class.

15
Choosing (continued)

• Must decide which classes go into particular
  packages.
• Best to group related classes in the same module.

16
This presentation is based on the following book
Object Oriented Analysis and Design by G.Booch
and partially compiled by Leonard Manzara.