The first code quality we’ll discuss is my very favorite: cohesion. Cohesive code is highly focused code that’s straightforward and easy to read. I like cohesion because it’s the easiest one for me to spot, but I recognize that that’s not true for everyone. People have told me that cohesion is actually the hardest for them to spot. If that’s true for you then fear not because you don’t have to be an expert at every one of these code qualities. Focus on just one or a few of them and as one improves, you should see others improve as well.
I’ll give you some tips in this post on how to identify cohesive classes and some tips in the next post on how to identify uncohesive classes.
When developers talk about cohesion, we’re talking about how focused the entity is because we want to make each entity in our system about one thing and only one thing. When something is cohesive, it’s about one thing.
Another way to see cohesive code is as fulfilling the Single Responsibility Principle. In other words, it has one and only one responsibility.
The benefit of this, of course, as Bob Martin points out, is that an entity that has only one reason to exist also has only one reason at most to change. So cohesion in code gives us the ability to limit the amount of change to code, or rather to spread changes out among multiple objects in the system.
Cohesion in code implies a lot. It implies that you will have lots of little entities rather than a few large ones, but each entity will be highly focused and if there is a bug in behavior it’s usually due to the entity with that responsibility—so it’s easy to find.
Cohesive code is also easy to read. Since each entity is about one thing, we can name it for what it does. In fact, this is my litmus test for whether a class or method is cohesive or not. I simply ask myself, “Can I name it in a way that describes precisely what it does?” If I can, that entity is cohesive. If I can’t easily name it or if my name has the word “and” or an under bar in the middle of it then I know that my entity is about more than one thing. So naming for me is my first line of understanding whether or not what I’m building is cohesive.
Quite frankly, I used to be scared of programs that had lots of little classes because it always seemed like the behavior was somewhere else. When I try to trace through this kind of code I find myself jumping around all over the place, thinking there are too many levels of indirection going on. The reason I feel that way is that I don’t understand the value and benefits of this type of programming.
As a structured programmer, I was familiar with tracing through code. I pretended that I was the CPU and I would execute lines of instruction in sequence. This is how I was trained, many years ago, to read and understand sequential programming. But this approach doesn’t work very well for object-oriented programs so I take a different approach.
I think about good object-oriented programs as having layers I can use to understand my program from different perspectives. Understanding a program in this way allows me to compartmentalize behaviors. For example, if I’m writing a program to generate a report and there’s a problem with the report’s header, I know exactly where to look in the code to find the issue, namely in the code responsible for generating the report’s header. I don’t have to look in the footer code or in the pagination code, and so in this way bugs are isolated, making them more straightforward to find and fix.
When the objects in our object model are cohesive, it’s telling us we understand and have represented the domain correctly. Cohesion is the number one defense against complexity, and complexity is the mind killer. When we write complex code, it’s hard to follow and it becomes difficult for others to maintain. Cohesion allows us to manage complexity by putting each thing in its own place thereby limiting how they interact with their defined interfaces. This is the essence of all good architecture and design.
I feel that cohesive code goes right to the core of what good software is all about. Its responsibilities are focused and it’s easy to understand.
{3 Comments }
Previous Post: « Keep it CLEAN
Next Post: Pathologies of Uncohesive Code »
Thank you for this post. I also thought that code with too many classes had too many levels of indirection. But, as you point out, that’s not necessarily a bad thing if limits the number responsibilities of classes.
It’s not easy to find well-designed, cohesive code from which to learn. Do you know of any open source projects that do a great job at cohesion, and, more generally, have SOLID/CLEAN code?
Thanks.
Hi Carlos,
Thank you for the comment. I’ve had a hard time finding examples of high quality open source code as well. Please let me know if you find anything good.
Thank you,
David.
You might want to look at the source code for Uncle Bob’s Fitnesse:
https://github.com/unclebob/fitnesse
He does practice what he teaches.