Cohesion and Coupling - How does one determine the threshold?

Question

I'm taking further intro java classes at the moment and this is how the class briefly defined this:

Cohesion: Aim for high cohesion, in this case cohesion meaning that a single module is tightly focused on its task.

Coupling: Aim for low coupling, in this case coupling meaning the level of extent in how intertwined two or more modules are.

How does one determine the level of cohesiveness as well as coupling?

For instance, some of my methods call other methods that are in the same class. This means that the method that calls other methods are dependent on the other methods in order for the "calling" method to finish its code block. Does this mean that I have low cohesion and high coupling on the methods of the same class? Or do these concepts refer more to different classes and different packages?

Answer 1

There are metrics for cohesion / coupling; see https://softwareengineering.stackexchange.com/questions/151004/are-there-metrics-for-cohesion-and-coupling.

So the way to "determine" the level of cohesion / coupling is to implement a tool that measures the respective metrics. (Or find an existing tool that does this. For example, Sonar.)

How does one determine the threshold for the level of cohesion and/or coupling?

I assume you mean ... how do you decide when you will call values of the respective metrics "unacceptable" in your codebase.

Basically, that is up to you to decide. I would do it by looking at examples where the tool is reporting a "bad" value, and decide how bad I thought it really was. Alternatively, stick with the default thresholds in the tool that you are using.

Answer 2

Cohesion and decoupling are important at all levels: each line of code should have a specific meaning and purpose, each method should have a specific meaning and purpose, each class should have a specific meaning and purpose, each package should have a specific meaning and purpose, each code repository should have a specific meaning and purpose.

This doesn't mean that a method shouldn't call another method, that a class shouldn't use another class, etc.; rather, it means that ideally, you should be able to read and understand a method without reading every other method it calls, to read and understand a class without reading every other class it uses, etc.

That said, we expect greater cohesion and decoupling for larger units: classes need to be much more cohesive and much less tightly coupled than methods do, for example, because assuming your classes are a reasonable size, you can much more easily go back and forth between methods than between classes when you're reading and maintaining the code.

Answer 3

I might be wrong, but here is just my humble input.

Cohesion is often time mentioned along with coupling, but they have an inverse relationship. High cohesion == low coupling.

Let me quote you

Aim for high cohesion, in this case cohesion meaning that a single module is tightly focused on its task.

So it just means like that. Something that only does one thing and does it well. For example, a method to save an entity to the database should only focus on how to save that entity to the database, it should not worry about the correctness of that entity (Do all of that entity instance attributes pass all the database schema validations, in which case this validation should be handled maybe by an interceptor).

Coupling refers to the degree to which 2 modules depend on each other, the least the better because it promotes maintenance, and re-usability, etc. Often time, low coupling is achieved by using events, we have event emitters and event consumers, and they don't have to know anything about each other. Even emitters just fire-and-forget, and the consumers will take of the events when the system delivers the events to them.