What are the concepts of cohesion and coupling?

Question

What are the characteristics of a code with cohesion or coupling? To what extent can this generate future problems?

Answer 1

The two concepts, although different, are related. And they are very important. A lot of the stuff you see out there about what to do with the code is detailing about these two concepts.

Cohesiveness

It refers to the relationship that the members of a module have, no matter what module it means. Indicates whether members have a more direct and important relationship. Cohesive codes are those of strong relationship, where its members are closely connected and are there for a common purpose. Members that are not absolutely necessary for that module should not be present in cohesive codes.

Cohesive modules are those that have few responsibilities. This way maintenance is simpler and avoids side effects. It is easier to change one part of the application without affecting other parts. This is why it is confused with the principle of single responsibility. And so some paradigms that isolate things can be more cohesive than others that encourage everything together, contrary to popular belief.

It is important to take superfluous functionality from one module and transfer to another module.

It kind of reminds me of normalization of the database which ultimately determines that each table has only one data column and one connection with the others.

There is even greater ease to remember what modules do when they do little. What is not cohesive, is confusing, incoherent.

Obvious examples of low cohesion are modules that take care of business rules, data persistence and user interaction at the same time. But there are less obvious cases when you establish that a customer can decide when he is defaulting or which vendors serve him. It is common to think that this belongs to the client but the clients exist independent of this, and that clients are roles of people in an organization.

It’s extremely common to see designs with low cohesion, some in exaggeration, others in the right mediated. Of course trying high cohesion at all costs will also become a problem of design. Everything has a downside. There are cases of high cohesion in exaggeration. It rarely makes sense to have a module with a single member.

Forms of cohesion (from worst to best):

• By coincidence - It happens without planning, may be right or not. In general it is considered as the worst cohesion.
• Logic - Members of the same logical category, same activity, are together.
• Temporal - Relate by the moment they are executed.
• Procedural - Form a sequence to perform a larger task.
• Communicational - When this sequence of executions occurs on the same data.
• Sequential - When a member’s departure serves as input for another member.
• Functional - Grouping occurs only because they really need to be together to contribute something very well defined.

Coupling

Refers to the relationship between modules. Indicates how much one module depends on another to function. Decoupled codes are those of weak relation, and do not rely on others to make their basic functionality. A low level of coupling is always desirable.

When there is low coupling, the application becomes more flexible, reusable and more organized. It is possible to exchange parts that have proved problematic, outdated or require new functionalities.

When seeking cohesion it is common to have new modules created with high coupling and a new evaluation is necessary to reduce this difficulty.

In general the high coupling maintains the problem of low cohesion, and in an even more complicated way. When there is a change in a highly coupled module, it generates the need for changes in other modules, which can be more complicated to do and generates more risks than a module with low cohesion.

An example of poor coupling is a tax bill that takes data from a tax to make the calculation. The ideal is that the tax calculation strategy is completely independent and unknown to the invoice, so it can be easily exchanged.

Applications that use low coupling properly are rare. And when they do, it is usually following an established design standard. Even so in an irregular way. What would not be a bad thing if it were always done with conscience. The low coupling ends up making sometimes the most complex applications.

Coupling forms (from worst to best):

• Content - When a module can access, modify or refer directly to contents of another module.
• Global - When modules can read and write global module data.
• Control - When one module will decide how another will work.
• Data structure - When data from a module is passed in a data structure passed as parameter.
• Data - When only the data really needed for another module are passed as parameters

It is not possible to eliminate the coupling altogether, we can only keep it as low as possible.

Making modules (classes) specifically dependent on another module, which require a specific implementation, which cannot change specific behavior, or even which requires another module when it can solve cohesively, are examples of excessive coupling.

In OOP to reduce the coupling we must program to the interface and not to the implementation.

Concepts and paradigms

These concepts have existed at least since the 1960s. And contrary to what many believe, it is not an intrinsic concept of object orientation. Unfortunately some people think that there is only this paradigm and end up writing wrong things on the internet attributing incorrect information to what they know and like.

It was already well documented in books of the 70’s and were being disseminated in the most current books that privilege a paradigm over others.

So little is related to languages. In fact the concept transcends computing.

Software engineering tools are very old and can be applied in general to all programming paradigms. When this is done, some of the paradigms that seem outdated become relevant.

It is true that paradigms like OOP can help organize the code better, but when one does not know what to do, it will do wrong in all paradigms. And indeed OOP helps at some points, but complicates at others. It is rare to find someone who can define well cohesive and uncoupled classes. So these concepts became important in this paradigm. In simpler and freer paradigms, when used in the right way, it is easier to maintain cohesion and low coupling. Although it brings some other maintenance difficulties.

OOP encourages subclass (inheritance) which is one of the worst forms of coupling existing. OOP encourages grouping all behaviors into one class, which is often abused. To solve this a series of design patterns are created, which would not be necessary in another paradigm.

I’m not saying that other paradigms are better and free of defect. I’m just saying that if software engineering is applied correctly, the paradigm isn’t that important.

Answer 2

These two concepts are fundamental to the Orientação a Objetos.

Cohesiveness:

Cohesion is indeed linked to the principle of responsibility single, which was introduced by Robert C. Martin in the early years 2000 and says that a class should have only one responsibility and perform it satisfactorily, that is, a class should not assume responsibilities that are not yours.

A cohesive code is a code where classes and/or methods have a single responsibility. That is, a method with the name imprimeSoma() must PRINT THE SUM and not CALCULATE THE SUM AND PRINT IT. Why ??

1. We want to change the way we print the sum: we change the method of printing the sum...
2. We want to change the way we calculate the sum: we change the method that calculates the sum

However, if the same method calculates and prints, we may have problems changing it, since we will be moving parts of the code that would not need to be under your responsibility, in case the concept of coesão, or responsabilidade única, had been implemented correctly.

So we see that cohesion is important for manutenção and evolução software.

Similarly, we can observe the coupling:

Coupling means how much one class depends on the other to function. And the greater this dependence between the two, we say that these classes they are strongly coupled.

When a class is fortemente acoplada to other classes, it is difficult to manage the system, because when we need to make a change in one of the classes, we have to change the code in other classes as well.

Source: Devmedia

Answer 3

I know the topic is a little old, and it’s been answered, but my teacher spent an exercise asking difference between cohesion and coupling, and then gave the following answer. As I found well summarized, I decided to share it here.

Both concern modules of a system, although are usually concepts associated with classes in orientation to objects. Cohesion is the degree to which a module has a unique and well defined responsibility. Coupling is the degree with the which one module depends on other modules for its operation. The ideal, so that a system is flexible and understandable, are modules with high cohesion and low coupling.