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 you see your abilities in one improve, you should see your abilities in the 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 is my first line in understanding whether what I’m building I’m building is cohesive or not.

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.