Cohesion and Coupling - The Keys To Changing Your Code With Confidence

Cohesion and Coupling - The Keys To Changing Your Code With Confidence

Developers often begrudge how difficult their code is to maintain. They look for new languages, new paradigms and new practices to help them write more maintainable code. But they often gloss over the basics of clean code.

This talks discusses two simple software metrics conceived in the 1960s - cohesion and coupling. These two measurable properties can tell you so much about how readable and maintainable your code really is.

You'll learn how to measure cohesion and coupling, interpret what the measurements mean and how to refactor to improve these metrics and ultimately, the maintainability of your codebase.


Daniel Donahue

May 17, 2018


  1. Cohesion and Coupling THE KEYS TO CHANGING YOUR CODE WITH

  2. Cohesion

  3. What is Cohesion? ▶ “The degree to which the elements

    inside a module belong together.” (1) ▶ Single-Responsibility Principle
  4. Benefits Of Cohesive Modules ▶ Simplicity/Understandability ▶ Modules are easier

    to reason about. ▶ Maintainability ▶ Changes to a cohesive module are isolated. ▶ Reusability ▶ Performs one job well. Easier to find.
  5. Symptoms Of Low Cohesion ▶ “Large shared assemblies with low

    cohesion cause small changes to require disproportionately large parts of the system to be rebuilt, redeployed and re-tested.” (2) ▶ Lots of merge issues ▶ Whack-a-mole / Accidental duplication
  6. Symptoms Of Low Cohesion

  7. Measuring Cohesion - Qualitative ▶ Coincidental cohesion (Worst) ▶ Logical

    cohesion ▶ Temporal cohesion ▶ Procedural cohesion (Acceptable) ▶ Communicational cohesion ▶ Sequential cohesion ▶ Functional cohesion (Best)
  8. Measuring Cohesion - Quantitative ▶ Relational cohesion (H) of an

    assembly ▶ H = (R + 1) / N ▶ R = Number of types in the assembly that do not connect types outside the assembly. ▶ N = Number of types in the assembly ▶ Lack Of Cohesion Of Methods (LCOM) of a class ▶ LCOM = 1 - (sum(MF) / M * F) ▶ M = Number of methods in the class ▶ F = Number of instance fields in the class ▶ MF = Number of methods accessing a given instance field ▶ sum(MF) = The sum of MF over all instance fields of the class. ▶ Use a static analysis tool!
  9. How To Refactor Towards Higher Cohesion ▶ Pay attention to

    the instance variables and methods in your class. ▶ Is each method using most, or all, of the instance fields/data? ▶ Is each method using the other methods? ▶ Trace execution paths – are they all separate? Then separate them! ▶ Make many more assemblies than you (probably) already have. ▶ Look for functionally cohesive pieces and package them up. Keep everything else out.
  10. Coupling

  11. What Is Coupling? ▶ “The degree of interdependence between software

    modules; a measure of how closely connected two routines or modules are.” (3) ▶ What can I break and what can break me.
  12. Common Types of Coupling ▶ Afferent coupling - how many

    things depend on me. ▶ If I change what I do, how many usages will I break? ▶ Efferent coupling - how many things I depend on. ▶ How many things can break me if they were to change?
  13. Symptoms of High Coupling ▶ A change in one module

    usually forces a ripple effect of changes in other modules. ▶ Building of modules might require more effort and/or time due to the increased module dependency. ▶ A module might be harder to reuse and/or test because tightly coupled modules must be brought along for the ride.
  14. Measuring Coupling - Qualitative ▶ Lower coupling is better*. ▶

    A completely decoupled module is essentially useless. ▶ Prefer coupling to things that are more stable than you.
  15. Measuring Coupling - Quantitative ▶ Just start counting. Seriously. ▶

    Use a static analysis tool!
  16. Things That Make Coupling Hard To Spot ▶ A shared

    database hides otherwise obvious coupling. ▶ Type casting and conversion. ▶ Reflection and metaprogramming hides otherwise obvious coupling.
  17. How To Refactor Towards Looser Coupling ▶ Use good abstractions

    instead of relying on concrete classes. ▶ Bonus: Make many SMALL interfaces instead of fewer, larger ones. ▶ Make parameter objects, instead of passing multiple parameters. ▶ Use the mediator or observer pattern (i.e. commands) ▶ Depend on packages that are more stable. ▶ Don’t hesitate to make packages that consist only of abstractions.
  18. Code Demo!(4)

  19. Key Takeaways ▶ Keep cohesion high… all things in a

    class are helping perform the work of that class. ▶ Keep coupling low… allows for change with less consequence!!!! ▶ Measure both… use a static analysis tool! ▶ Learn how to refactor towards more cohesive, less coupled code.
  20. Thanks for your time!! ▶ Blog: ▶ GitHub:

    ▶ Twitter: @deathmetaldan13
  21. References 1. 2. pend/ 3. 4.