This week, for professional development, I chose to read and learn about two of the GRASP principles of software design, High Cohesion and low coupling. One of the best resources I found was this blog post, https://thebojan.ninja/2015/04/08/high-cohesion-loose-coupling/
The post starts by mentioning the need for code to be maintainable and changeable, especially in business, to backdrop how useful these coding principles are. Following, the author explains cohesion and goes through what seemed like an exhaustive list of the types of the common types of cohesion. After giving a few visual examples (class diagrams and code) the same is done for coupling as well, along even more code and diagrams.
Now, all other resources do basically the same thing with the topic, but I felt this resource was the best for explaining both how and why we try to achieve loose coupling and cohesion. Along with his diagrams and code, the examples provided to explain the concepts were easily understandable as well. A good example would be the explanation provided for loose and tight coupling
iPods are a good example of tight coupling: once the battery dies you might as well buy a new iPod because the battery is soldered fixed and won’t come loose, thus making replacing very expensive. A loosely coupled player would allow effortlessly changing the battery. The same, 1:1, goes for software development.
The example’s simple language and nature makes the subject a bit easier and a bit quicker to learn for me. It’s important too that I understand this topic well because nearly everything I write will need to be refactored. If not by me then by someone else, and having to change someone else’s code is already difficult enough. So, it’s in my interest for both simplicity and professionalism that I make sure to value loose coupling and high cohesion in my work.
Now, I can see more clearly how my past object orientated class assignments have all stressed keeping classes independent and ignorant of each other. Loose coupling and high cohesion are instrumental to keeping code manageable and now I’ve got a much better grasp of these concepts.
Beyond the general concepts, I appreciated the overview for the different types of cohesion. They are just different ways of grouping modules, but knowing some of the most common ones will improve my own designing speed and quality.
I know I’ll use the information from this post enough that it should become second nature to me, hopefully subconscious.