Lack of cohesion of methods (sometimes abbreviated LCOM) is one of those things that occurs fairly high up on the software hierarchy of needs. What’s the “software hierarchy of needs?” It’s a thing that I just made up, shamelessly copying Maslow’s Hierarchy of Needs. (Though in a quick search to see how effectively I’ve planted this flag, I see that Scott Hanselman had the idea before me. But mine looks a little different than his because I’m talking about the software, rather than the humans writing it.)
Anyway, here’s the hierarchy.
- The cost of change stays relatively flat because the software is highly maintainable.
- You can change it over time in response to evolving requirements and market realities.
- It performs and behaves acceptably in production.
- Technically, it fulfills the functional requirements and user value proposition.
- It simply exists in production.
When it comes to something like lack of cohesion of methods, you’re talking about the top two categories. Early in your career, you’ll tend to have worries like just wheezing past the finish line with a feature and like getting your code to do what you want it to. With practice and time, you then start worrying about non-functional concerns and maintainability. And when you start worrying about that, you should start paying attention to lack of cohesion of methods (among other things).
So for the rest of this post, I’ll focus on this one idea: lack of cohesion of methods. What is it, how do you measure it, and why should you care?