When I first started learning about object oriented programming, and really digging into the best practices, loose coupling and high cohesion kept cropping up. I had a hard time trying to keep them straight and remember which one I wanted more of and which one I wanted to reduce. My biggest difficulty was I couldn’t keep the definitions of coupling vs cohesion straight!
Coupling refers to how much a set of classes rely on one another. If we have two classes, A and B that each use methods from the other, these classes would be tightly coupled. If we have those same two classes and only one needs methods from the other, then those are more loosely coupled.
The little metal ends on a garden hose that you can twist together are called couplings. You use them to join two pieces of hose together. I like to use this to help me remember that coupling is about how two (or more) classes interact with one another.
Cohesion refers to how much the methods in a particular class belong together. For example, let’s say we have a class representing a soup can. The soup can should know about how big it is, what it is made out of, what shape it is and what color it is. If we start adding information about the soup that is stored inside the can, then we are breaking the cohesion. Information about the soup is not important to the actual can. The information about the soup should be contained in a separate class that the can could know about.
Thinking about a cohesive group of people helps me remember what this means. A cohesive group of people are people that work very well together and really seem to belong together, much the same way as a cohesive class design has methods that really belong together.
I have another post about coupling here.
When we talk about cohesion, we are really talking about how well the ideas in a class or a data structure belong together. I mention data structure here because this principle can and should be used when designing database tables, or any data storage scheme, as well as when you are designing a class. We are gong to focus on cohesion in code in this article.
Now that we have a better understanding of what cohesion means, why is it important? Why should we worry about creating things that are really cohesive? The program will work even if we throw a bunch of different concepts into one pile, right?
Technically, yes. It is possible to write an entire application in one file. And…you might even be able to hold all of the context of the application in your head at once while you are writing it. Just because you can , doesn’t mean you should.
Why not put it all into one class?
There is a term for a class that ends up knowing too much about too many things…”god class”. This is not the good kind of god, it is the spiteful, vengeful type of god, and you really don’t want to go creating them.
When you have a class that knows too much about too many things, it makes changing that class REALLY dangerous.
When a class knows too much, and does too many things, making a small change can impact many parts of the application, since it is likely used there too! When we break things out into small classes, those classes are often used in fewer places, and their methods are very well defined.
Also, when everything is in one class, there is often a fear of touching that class. We cannot understand everything that it is trying to do, so we don’t want to make a change that will cause unknown issues. When we are afraid to touch classes, we don’t try to improve them, we just try to patch the hole and get out as quickly as possible. This is not good for the overall health of our application, and is not good for our overall mental health.
High cohesion and the SRP (Single Responsibility Principle) go hand in hand. When you design your classes, they should have one main purpose, one main reason to change.
Breaking your classes down this way not only means that each individual class will be changed less often, but it also helps us humans reason about the system as a whole. Often systems are very complex, and contain a lot of concepts. If we can break down the ideas into smaller and smaller parts, we can more easily understand these tiny parts, and can then build up our mental model much more easily.