Skip to main content

7. Software Design: Responsibilities

28/10/21

Class Responsibilities​

Two kinds of responsibilities:

  • Knowledge maintained by object
  • Actions an object can perform Should represent purpose of object in system Define services provided by object to system:
  • Information object can return to client object
  • An action object can perform for client object Represent only publicity available service
  • Other knowledge and actions may need to be implemented by a class, but definition of these should be delayed

Concentrate on what class does, not how it does it

Guidelines for identifying responsibilities​

  1. Examine verbs in requirements specification
    • Each verb may indicate a responsibility, turn passive voice sentences into active voice and examine
  2. Examine information nouns in requirements specification
    • May become an attribute of a class or a part of a composite class
  3. Perform a system walk through
    • Scenarios should be based on functional view
  4. Re-examine candidate classes
    • Name/statement of class may imply responsibilities. Attributes of the class may need to be managed

Assigning Responsibilities​

Identified responsibilities must be assigned to classes.

Guidelines​

  • Distribute system intelligence evenly
  • State responsibilities as generally as possible
  • Keep behaviour(actions) with related information
  • Keep information about one thing in one place

System and Class Intelligence​

System intelligence​

  • What the system knows
  • What actions the system can perform
  • The impact the system has on other systems
  • Class intelligence is determined by:
    • What services does it provide (server view)
    • What services does it use (client view)

Class Intelligence​

  • Server view: What class knows, what actions it can perform
  • Client view: How many other classes does the class know. How much does it need to know about those server classes.

Centralised Intelligence​

  • Taken to extreme: One object incorporates most/all of system intelligence
  • Centralised control: Top-down design with main program under complete control and other objects serving as simple data structure entities

Advantage​

Easier to get initial understanding of overall control flow and information flow: only need to understand one object

Disadvantages​

  • Hard-wires system behaviour (less adaptable)
  • Integrates multiple design decisions into a single class: makes it less likely that one implementation decision can be changed without affecting others
  • Less code/design sharing
  • Major problem when working in teams

Distributed Intelligence​

Goal - Distribute intelligence as evenly as possible among classes

  • Minimise number of intelligent classes
  • Aim: all classes are equally intelligent ...

IF a class has particularly long list

  1. Responsibilities are expressed at too low level of detail
  2. Might be able to move some to other classes
  3. If still too long, perhaps the class should be subdivided

Responsibility Guidelines​

  • State responsibilities as generally as possible
  • Leads to more shared responsibilities
  • May lead to more general classes
  • Keep behaviour with related information
  • Keep information about one thing in one place
    • Maintenance should not be shared. Leads to duplication of information
    • If more than one object, must know the information:
      1. Assign the info to the object/class with the least amount of responsibilities
      2. Can be collapsed into single object/class if objects require little info
      3. Create a new object to take the responsibility of managing the information
  • Split shared responsibilities
    • Split into more specific components which get distributed

Examining Class Relationships​

  • Application-specific relationships between classes. May be many application-specific relationships between classes, identifying these my indicate new responsibilities.

Is-a-Kind-Of (Inheritance)​

Look for parent/child relationship Shared attributes or behaviour can imply this

Is-Part-Of (Composition)​

No shared behaviour implied Defines an object hierarchy, not a class hierarchy An object is often composed of parts and has responsibilities for those parts, not vice versa.

Unassigned Responsibilities​

Difficulties in assigning responsibilities can occur because:

  • A class is missing - May need to add a class to handle a set of unassigned responsibilities
  • Responsibility could be assigned to more than other class - Sometimes the assignment is not obvious. Make a tentative arbitrary assignment