Skip to main content

[Software metrics] Lack of Cohesion of Methods - LCOM4

In one of my latest post we talk about Mean Time Between Failure software metric (MTBF). We saw that this metrics is very useful when we need to make an idea about what is the quality of our software that is in production.
Today we will talk about LCOM4 (Lack of Cohesion of Methods). The main information that we receive from this metric is the number of responsibilities (functions) that a class has.
When we have a low cohesion means that we have a bad design, with classes that are very complex. This can also indicates that the class are complex, very big and can produce a lot of bugs.
When we have a high cohesion that we have a very good encapsulation, each class do only one thing but it does very good. Normally, this class are not very long, the complexity of them is not very high and are simple to understand and work with. The only problem that can happen with this class is related to testing. Sometimes, this class are pretty hard to test because the coupling level between them is pretty high.
The number 4 from the name comes from the ‘version’ of this metric. This is not the first time when someone try to measure the cohesion of a class. On the internet there are different formulas. The LCOM for is the one that is recommended in this moment – it seems to be the accurate. It was discover by Hitz and Montazeri and measure the number of connected components in a class. A connected component is a set of method that are related at class level (calls one another and so on). In theory we should have only one component in each class – one functionality.
When we have more than one component in class, that we should split the class in smaller classes. From this perspective two method are related when they use the same fields/variables or when one method calls another method.
In the above example we have 3 different responsibilities in the same class. A depend on B and C, D depend on E and F use G and H.
The ideal value of LCOM4 for a class is one. This indicates us that this class has only one functionality – cohesive class. Any value higher that 1 indicates that the class has to many responsibilities and we should split that class.
Be aware when you have classes with LCOM4 value equal to 0. This is happening when we don’t have any method in a class.
There are cases when we will have classes in our application when LCOM4 value will be higher than 1 and we will not be able to do nothing to it. This can happens when we have a controller from MVC, a view model from MVVM or a user controller for a desktop application. In this cases, when you split your controller based on different functionalities, there are times when there is no need to split the controllers in smaller part only for LCOM4 value.
As I already sad in other posts, LCOM4 like other metrics give us information related to code. It gives us hints where we could have some problems, but we need also to analyze code before making a scope in our live to have this value lowest as possible.
In this post we saw why LOCOM4 is so important in our application. This software metric can give us information related to how many responsibilities a class has. I recommend to try to calculate LCOM4 in your project and see what values you will get.

Comments

Popular posts from this blog

How to check in AngularJS if a service was register or not

There are cases when you need to check in a service or a controller was register in AngularJS.
For example a valid use case is when you have the same implementation running on multiple application. In this case, you may want to intercept the HTTP provider and add a custom step there. This step don’t needs to run on all the application, only in the one where the service exist and register.
A solution for this case would be to have a flag in the configuration that specify this. In the core you would have an IF that would check the value of this flag.
Another solution is to check if a specific service was register in AngularJS or not. If the service was register that you would execute your own logic.
To check if a service was register or not in AngularJS container you need to call the ‘has’ method of ‘inhector’. It will return TRUE if the service was register.
if ($injector.has('httpInterceptorService')) { $httpProvider.interceptors.push('httpInterceptorService&#…

ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded

Today blog post will be started with the following error when running DB tests on the CI machine:
threw exception: System.InvalidOperationException: The Entity Framework provider type 'System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer' registered in the application config file for the ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded. Make sure that the assembly-qualified name is used and that the assembly is available to the running application. See http://go.microsoft.com/fwlink/?LinkId=260882 for more information. at System.Data.Entity.Infrastructure.DependencyResolution.ProviderServicesFactory.GetInstance(String providerTypeName, String providerInvariantName) This error happened only on the Continuous Integration machine. On the devs machines, everything has fine. The classic problem – on my machine it’s working. The CI has the following configuration:

TeamCity.NET 4.51EF 6.0.2VS2013
It seems that there …

Run native .NET application in Docker (.NET Framework 4.6.2)

Scope
The main scope of this post is to see how we can run a legacy application written in .NET Framework in Docker.

Context
First of all, let’s define what is a legacy application in our context. By a legacy application we understand an application that runs .NET Framework 3.5 or higher in a production environment where we don’t have any more the people or documentation that would help us to understand what is happening behind the scene.
In this scenarios, you might want to migrate the current solution from a standard environment to Docker. There are many advantages for such a migration, like:

Continuous DeploymentTestingIsolationSecurity at container levelVersioning ControlEnvironment Standardization
Until now, we didn’t had the possibility to run a .NET application in Docker. With .NET Core, there was support for .NET Core in Docker, but migration from a full .NET framework to .NET Core can be costly and even impossible. Not only because of lack of features, but also because once you…