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
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: http://dandonahue.net ▶ GitHub: http://github.com/ddonahue ▶ Twitter: @deathmetaldan13
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