Object Behavior Analysis: some guidelines

1
Object Behavior Analysis some guidelines

• Methods should be distributed fairly evenly among
  classes, so that you avoid having a few control
  objects and many data objects
• When possible, assign method to class that knows
  the attributes needed to perform the method
• when no single class knows all the attributes
  needed, assign method to the class that would be
  logically expected to perform the method

2
Guidelines contd

• Methods used to create and break relationships
  should be assigned to the class that controls the
  relationship
• Method that changes the state of an object should
  be assigned to the class.
• When in doubt, act it out!

3
Example
Rental Customer
Authorized User
Rental customer can exist without be associated
with Authorized User, but not vice-versa. So,
method AddAuthorizedUser() should be assigned to
Rental Customer (the controlling class)
Example
Two classes Account and Payment. A method
reportStatus(..) returns values overdue or
paid. Which class should contain this method?
4
Example
Method addAccount() creates a relationship
between a Customer instance and an Account
instance. Each customer can be related to zero or
many Accounts objects, but each Account object
must be related to exactly one Customer
object.Which class should this method be assigned
to?
Example
A method calcExtendedPrice(..) multiplies the
quantity of a line item by the price of the line
item. Quantity is an attribute of LINE-ITEM and
price is an attribute PRODUCT. Should this
method be assigned to LINE-ITEM or PRODUCT?
5
Evaluating Object-behavior design

• Present functionality vs. future adaptability
  (reusability)
• Coupling
• should not have to pass a lot of data between
  objects - no message should need more than three
  parameters
• No messages should be sent from sub-classes to
  access data in a super-class - taken care of by
  inheritance.
• Coupling is a natural side-effect of
  specialization and composition relationships -
  however, collaboration relationships should not
  be so strong that Class-A and useless without
  Class-B.

6
Evaluating Object-behavior design contd.

• Cohesiveness
• single functionality per method
• Eg. completeOrderFooter(..) that also prints the
  order
• - two separate methods better
• overriding of attributes and methods defined in a
  super-class should not be too frequent.
• Clarity
• Complexity vs. reusability
• neither too deep, nor too wide

7
Evaluating Object-behavior design contd.

• Simplicity
• should not have too many methods in a class
• 5 or 6 number of attributes less than twice
  number of methods
• too many methods signify an application specific
  definition of a class, which will be difficult to
  reuse.
• Act-ability
• high quality OO design can be acted out be humans
  playing the role of objects
• can be verified by a structured walk-through
• mappings between real-world objects and system
  objects should be transparent.