A few years ago I was using Sonar (before it was SonarQube) to analyze some Java code, and I remember seeing a useful metric that would come in handy again today. However it does not appear to be part of the SonarQube implementation that I have access to.

The metric described the way by which a class could easily be broken down into separate classes without requiring extensive refactoring.

By way of example, what I mean is: Say we have a class named MyService, which has references to two DAOs, CustomerDAO and ItemDAO. Every method on MyService calls either CustomerDAO or ItemDAO but never both. It seems intuitive that MyService could be broken down into CustomerService and ItemService, and thereby improve the application's overall single-responsibility-principle-ness.

However -- I can't find any references to this metric in a review of static analysis tools, and I can't find a concise way to describe it in a way that a search engine would understand.

Can anyone point me at a good name for / definition of this metric, and/or at a tool that implements it?

  • You appear to be describing ordinary refactoring. Mar 21, 2018 at 17:27
  • 2
    I'm definitely describing ordinary refactoring. What I'm looking for is a specific metric that I know I've seen implemented by a static analysis tool, in order to find good bits of low-hanging fruit for refactoring on a very large project that is new to me.
    – Jim Kiley
    Mar 21, 2018 at 17:28
  • 2
    A Google Search for "sonarqube single responsibility principle" yields this article which suggests that the metric you're looking for is LCOM4. Mar 21, 2018 at 17:40
  • LCOM4 is indeed the thing I remember. Thanks.
    – Jim Kiley
    Mar 21, 2018 at 17:50
  • 2
    @RobertHarvey why not put this in an answer ? I'd upvote: this is definitely something worth to know and which could be of interest to the community (be it for people looking for methods to structure refactoring, or people looking for interesting applications of the graph theory).
    – Christophe
    Mar 21, 2018 at 20:15

2 Answers 2


The metrics you are interested in are called cohesion metrics. There are 30 or so different ones that I know of. This paper discusses quite a few of them, and has references to the original papers. BTW, many of them give counter-intuitive results in certain cases, and measurements from one metric often disagree with others.

Also, be aware that naming of the metrics is inconsistent. For example, LCOM stands for Lack of Cohesion Of Methods. Various people made adjustments to the original LCOM method, which resulted in other people adding numbers to distinguish them - LCOM1, LCOM2, etc. Unfortunately, this means that LCOM4 may be an imprecise designation, unless somebody makes sure to tell you whose LCOM4 they are talking about.

The extract-class refactoring is the one that is useful for separating large non-cohesive classes into smaller, cohesive ones. IntelliJ IDEA has a pretty good extract class refactoring tool.


You can try JArchitect to detect which classes could be divided by using the LCOM/LCOMHS metrics. The classes with poor cohesion are the most candidate for a refactoring.

Not the answer you're looking for? Browse other questions tagged or ask your own question.