4

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?

Chetan Kinger
  • 15,069
  • 6
  • 45
  • 82
simmonson
  • 137
  • 1
  • 9
  • It's a class / module issue, not a method issue. – Kayaman Jan 26 '17 at 07:37
  • Thanks! The class notes weren't very clear on that, so I wanted to confirm. Is there anything else important with these concepts that I should know about? – simmonson Jan 26 '17 at 07:40

3 Answers3

6

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.

ruakh
  • 175,680
  • 26
  • 273
  • 307
  • Cheers, just the way I've worded my question you can probably tell I'm very new to Java still...I did read a Reddit AMA for IE Software Engineers and they mentioned that there was a lot of legacy code...my guess is due to the level of cohesion and coupling but again that is my inexperience making guesses more than anything – simmonson Jan 26 '17 at 07:46
2

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.

Community
  • 1
  • 1
Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
1

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.

Trash Can
  • 6,608
  • 5
  • 24
  • 38
  • Thanks, I understood the definitions and based on the things I've seen at work (not as an engineer, I work as an artist), the logic in game engines depend heavily on the fire-and-forget concept. I will study this further... – simmonson Jan 26 '17 at 07:47