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.

Transcript

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

   View Slide

2. Cohesion
   

   View Slide

3. What is Cohesion?
   ▶ “The degree to which the elements inside a module belong
   together.” (1)
   ▶ Single-Responsibility Principle
   

   View Slide

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.
   

   View Slide

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
   

   View Slide

6. Symptoms Of Low Cohesion
   

   View Slide

7. Measuring Cohesion - Qualitative
   ▶ Coincidental cohesion (Worst)
   ▶ Logical cohesion
   ▶ Temporal cohesion
   ▶ Procedural cohesion (Acceptable)
   ▶ Communicational cohesion
   ▶ Sequential cohesion
   ▶ Functional cohesion (Best)
   

   View Slide

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!
   

   View Slide

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.
   

   View Slide

10. Coupling
    

    View Slide

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.
    

    View Slide

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?
    

    View Slide

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.
    

    View Slide

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.
    

    View Slide

15. Measuring Coupling - Quantitative
    ▶ Just start counting. Seriously.
    ▶ Use a static analysis tool!
    

    View Slide

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.
    

    View Slide

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.
    

    View Slide

18. Code Demo!(4)
    

    View Slide

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.
    

    View Slide

20. Thanks for your time!!
    ▶ Blog: http://dandonahue.net
    ▶ GitHub: http://github.com/ddonahue
    ▶ Twitter: @deathmetaldan13
    

    View Slide

21. References
    1. https://en.wikipedia.org/wiki/Cohesion_(computer_science)
    2. https://nrkbeta.no/2016/01/12/decoupling-legacy-code-using-nde
    pend/
    3. https://en.wikipedia.org/wiki/Coupling_(computer_programming)
    4. https://github.com/ddonahue/LooseCouplingDemo
    

    View Slide