Object-Oriented Programming


Michael L. Collard, Ph.D.

Department of Computer Science, The University of Akron


degree of interdependence between software modules; a measure of how closely connected two routines or modules are; the strength of the relationships between modules.

  • External measure of the relationships of a class to other classes


  • Dependency between elements
  • Degree or reliance between elements
  • Increasing cohesion may lead to more coupling (Why?)
  • Entropy of systems and designs increases coupling
  • Coupling needs to be limited and controlled

Why is Coupling Important?

  • Perhaps the most important characteristics of a system
  • Affects development path
  • Affects how we partition the system for testing
  • Affects how much reuse is possible
  • Significant effect on the complexity of a system

Coupling Goal

  • Minimize external interaction (extramural) with other elements (coupling)
  • For classes: Minimize and reduce relationships with other classes

States of Coupling

  • tightly coupled High degree of coupling
    • Very difficult to develop/test/maintain/use
  • loosely coupled Low degree of coupling
    • Much easier to develop/test/maintain/use
  • decoupled Classes with zero to minimal coupling
    • Very easy to develop/test/maintain/use
    • Common refactoring activity

Types of Coupling

  • Message Coupling (very best)
  • Data Coupling (best)
  • Stamp Coupling
  • Control Coupling
  • Common Coupling
  • Content Coupling (worst)

Content Coupling

  • A module directly references the content of another module:
    • One module p modifies a statement of another module q
    • One module p references or alters the local data of another module q
    • One module p branches into another module q
  • Content-coupled modules are inextricably interlinked
    • Change to module q requires a change to module p, including recompilation
    • Reusing module p requires using module q
  • Exposing data members via public access is a form of this

Common Coupling

  • Using global variables, i.e., global coupling
  • All modules have read/write access to a piece of global data
  • Functions exchange data using global data instead of arguments

Common Coupling Example

Common Coupling (cont)

  • Single function with write access where all other functions only have read access is not common coupling
  • To determine why a variable has a particular state, you have to examine all functions
  • Side effects, so all the code in a function needs to be examined
  • Function is exposed to more data than is needed

Control Coupling

  • Client passes a flag or command that explicitly controls what the called code is doing
  • Independent reuse is not possible
  • Client should pass data and leave control path decisions private to a module

Stamp Coupling

  • One module passes more data than needed to another module
  • Often involves records (structs) with lots of fields
  • Entire record passed, but only a few fields are used
  • Efficiency considerations?

Data Coupling

  • One module only passed the data needed by the other module
  • Only required data passed from one module to another
  • All arguments are homogenous data items
    • simple data type
    • complex data type, but the client code uses all parts
  • Allows for comprehension, reuse, maintenance, security, etc.

Message Coupling

  • Client code passes parameters via a non-private data format
  • Most flexible, since any language or tool can generate the data
  • Possible to store or cache requests
  • All arguments are homogenous data items
    • simple data type
    • complex data type, with all parts used
  • Allows for comprehension, reuse, maintenance, security, …
  • Potential performance overhead (?)


  Tightly Coupled Loosely Coupled
Changes Change in one module leads to changes in other modules Allows independent changes to modules
Assembly Difficult to assemble separately Easier to assemble separately
Test Difficult to test individual parts Easily test individual parts
Reuse Difficult to reuse individual parts Easily reuse individual parts
Additional Features Difficult to add feature/use of the system Easier to add feature/use of the system

Coupling Observations

  • If there is no way to separate modules so that they are loosely coupled, consider combining or packaging them together
  • Subclass Coupling - Between derived and base class

Advantages of Tightly-Coupled Modules

  • Obtain only the data that is needed. E.g., parsing source code for a specific query
  • Directly use the data with no need to translate to/from a data format
  • Layers can be skipped that are not needed. E.g., ISO 7-level network model vs. TCP/IP
  • All the features of a specific API can be used. E.g., writing code for MySQL instead of a generic database format (ODBC)
  • Decoupling leads to abstractions, which can make the programming task more difficult than direct use
  • In general, tightly-coupled modules can be more efficient but at a high cost of flexibility