Object-Oriented Programming

Cohesion

Michael L. Collard, Ph.D.

Department of Computer Science, The University of Akron

Cohesion

Degree of connectivity among the elements of a single module and in object-oriented design, a single class/object

Internal measure on an individual class/object/module/method

Why is Cohesion Important?

  • A cohesive class is much easier to comprehend because it has a single purpose
  • Increase reuse since the class is usable in multiple ways in many different projects or the same project
  • Reduce (maintenance) costs for fixes and enhancements
  • Simplify testing
  • Allow for replacement

Cohesion Goal

  • Maximize internal interaction (intramural) among subelements (cohesion)
  • For methods:
    • Methods share data members (fields) with other methods
    • Data members are used in combination
  • The more advanced the features of a class, the more this occurs

Cohesion & Declarations

Types of Cohesion

  • Informational (best)
  • Functional (best)
  • Sequential (better)
  • Communicational (better)
  • Procedural
  • Temporal
  • Logical
  • Coincidental (worst)

Applicability

  • system
  • subsystem/directory
  • class/file
  • method/function
  • section of code

Coincidental Cohesion

  • Performs multiple, completely unrelated actions
  • Often based on factors outside of the design: personnel, company organization, history, avoidance of small modules
  • No reusability, very difficult to maintain or enhance

Logical Cohesion

  • Performs a series of related actions, one of which is selected by the calling module
  • Parts have a logical association, but not the primary logical association
  • Primary logical association is based on the highest level of abstraction

Logical Cohesion (cont)

  • Often includes both high and low-level actions (in terms of abstraction) in the same class
  • Often includes unused parameters for certain uses
  • Difficult to understand interface. Many unrelated actions
  • In OO we put methods near the abstract concept that they work on

Temporal Cohesion

  • Perform a series of actions that are related by time occurrence, e.g., startup or shutdown
  • Degrades to Logical Cohesion if time of action changes
  • Addition of subsystems may require additions to multiple modules
  • In OO we build time occurrence actions into the class, and externally control lifetime

Procedural Cohesion

  • Action based on the ordering of steps, related by usage in ordering
  • Changes to the ordering of steps or purpose of steps requires changing the element abstraction
  • Situations where this particular sequence applies, are often limited
  • Each element, including methods/operations, should have one cohesive action

Communicational Cohesion

  • Each works on their own data
  • Action based on the ordering of steps
  • Actions are related but still not completely separated
  • Element cannot be reused
  • May be the highest cohesion possible/desirable

Sequential Cohesion

  • We place actions together because they are performed in order
  • Requires a crisp abstraction that then becomes the name of the method

Functional Cohesion

  • Element (methods) that performs a single action or achieves a single goal
  • Maintenance involves the entire element
  • High reuse because the element is completely independent (in its actions) of other elements
  • Superior, easily replaced for performance, testing, platform changes, etc.

Informational Cohesion

  • Performs a number of actions
  • Each action has its own entry point and independent code
  • All actions are performed on a shared data structure
  • Superior, truly Object-Oriented