Big, messy classes slow projects down and scare developers away.
In this post I’ll show you how to use LCOM to spot those "god classes" in your PHP...
For further actions, you may consider blocking this person and/or reporting abuse
I think it a metric you shouldn't use. It can be skewed too easily to create an outlier.
A few examples of the top of my head;
For the example I think the
sendNewslettermethod is ambiguous.If it is implemented the way you describe, it shouldn't be in the class. I think this will happen more in the case of a
Utilsclass than a more defined class likeUserManagerI think it is more likely scenario is the use of a current user property inside of the function and something is done with that property to send the newsletter.
But again it shows that LCOM formulas are skewed too easily, just by using protected or private properties in this case.
As a side note, I think we should stop using the god class term. The term itself is a god object, because it refers to too many dependencies or too many unrelated methods or both. It should be separated into heavy dependency object and inconsistent methods object. The LCOM metric only relates to the inconsistent methods object. The heavy dependency object can be checked by other metrics.
Thanks! LCOM’s not perfect, but it’s a handy signal that something might be off. And PhpMetrics even skips getters/setters, so they don’t mess with the score. The sendNewsletter was just an example, not my dream implementation 😉 And yeah, "god class" isn’t the cleanest term, but devs know what it means.
If you have to add suggestions to the metric like don't obsess over the numbers and look for the outliers. I think it is not a good signal.
It is like riding your car with the blinker on all the time. It could cause more harm than good.
That is a good thing.
I understand, I just wanted to add more nuance to the example in the context of the metric.
Thanks for sharing your perspective, I really appreciate the nuance you bring 🙏 Out of curiosity, what kind of metrics do you usually rely on, and what tools do you use to measure them? Would be great to learn from a different point of view
I'm not big on metrics to judge code quality. I prefer a more manual process.
I read the code and access the mental model behind the code. If it is easy to find the code is good.
I think the problem with every metric is that you only can measure the code.
And because there is a lot of hidden meaning in code, I think most code metrics are very low on the rating scale.
Best practices done indiscriminately lead to bad code. For instance loose coupling can become a major problem in certain scenarios.
I get your point about reading the code directly - that’s a good way to really understand it. I think scale makes a big difference. In a small app you can do that easily, but when you’ve got thousands of classes it gets a lot harder to see where the trouble spots might be. That’s where I find metrics useful - to point me in the right direction so I know where to look closer
The way I evaluate a big project is by reading the documentation if there is any, reading the tests, identifying the core functionality and reading that code. Most of the time the core has not that many classes that connect everything. It that is maintainable I give it a green flag.
I think you don't need to check the whole project if it works as is. I think you have to make the code your problem if it gets you into troubles.
A
Utilsclass can be a dump of random methods, but as long as those methods don't cause a problem they are not a high priority. They could get higher on the priority scale if you need to add or change a method. Then you can access if moving it to a different class is beneficial and maybe take a few related methods along in the move.I think it is better thinking about maintainability and time management than using metrics as a way evaluate a project.
I get your point: metrics like LCOM can be skewed. Getters, factories, fluent APIs… you can make any number look bad. But to me, the question isn’t whether the math is perfect, it’s whether the system works with us or starts working against us.
At small scale, you can just read the code and trust your mental model. At large scale, no one has time to eyeball thousands of classes. That’s where metrics are still useful... not as truth, but as headlights in the fog. They tell you where to look, not what to think.
What really drives change, though, is developer experience. If the new way is simpler, clearer, and feels right, people will adopt it naturally. Step by step, the old cruft... the Utils dumps, the ambiguous hybrids - fades (80%) away... the remaining 20% is often work that never gets done. Let's call it the trade-off. 🙈🙉🙊
“Simple things should be simple, complex things should be possible.” – Alan Kay
I'm assuming when you talk about a project with thousand of classes, they are all custom code. When a project reaches that amount of classes that is not going to happen without following loose coupling and single responsibility practices.
So that is why I look for god objects in the core of the application.
I agree that a
Datahelperor aUtilsclass are not the best names to collect the methods. But those classes can be refactored over a longer period, instead of needing to be refactored as soon as possible.I like the analogy, but I think it is not the right one. I think the better analogy is a searchlight. It makes a specific place visible in the dark.
The point I want to make it that when metrics can't prove an absolute they are not high value metrics.
Is someone productive because they do a lot of issue tickets, or when they write a lot of code? For me none of them are good metrics because it is possible to rig them or don't expose the unmeasured work.
I think the more important metrics are how fast can the code process the request, and what part of the code requires the most time.
Great explanation! LCOM is a simple yet powerful way to spot “god classes” that try to do too much. A high LCOM score usually means the class is mixing different responsibilities, which makes it harder to test and maintain. The fix is straightforward: split big classes into smaller, focused ones. This keeps responsibilities clear, improves cohesion, and makes your PHP codebase easier to scale and work with.
Thanks