optimization of high cohesion and loose coupling

Question

I was questioned in a technical interview about cohesion and coupling of a project. I extensively explained their definitions, although I did not answer the second part of the question properly, as he said.

"How could we achieve a highly cohesive and loosely coupled design in a project simultaneously and please explain how should this approach be implemented in a monolithic project ?"

I answered that these two objectives are contradictory, so we need to find out the best bet for each project or module, but I could not provide a comprehensive answer.

I would appreciate if anyone helps me out.

Mattheus

Possible duplicate of What does 'low in coupling and high in cohesion' mean – Clack

Thanks for your comment. The link you provided answers the first part of my question fully, however it does not represent that if there is a common approach to maintain loose coupling and high cohesion or it depends on the case. – Mattheus

Answer 1

I want to begin answering by saying that it is exactly opposite of what you said as “the two definition are contradictory”. I'm going describe by bringing a quote from John W. Satzinger System Analysis and Design in a Changing World, Key Facts book

Low coupling often correlates with high cohesion, and vice versa

---

By saying in a Monolithic they were signaling you to ask about the SOLID principals that if you apply them, result in a High Cohesion and loose coupling project.

Here is the definitions :

1.Single-responsibility principle (SRP)

Definition: There should be never more than one reason for a class to change.

Benefits:

• stronger cohesion in the class
• looser coupling between dependency classes,
• better readability
• code with lower complexity
• Code easier to understand and maintain.

---

2. Open-closed principle (OCP)

Definition: Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.

Benefits:

• loose coupling,
• improving readability
• reducing the risk of breaking existing functionality
• Code maintainable and reusable.
• Code more robust.

---

3. Liskov substitution principle (LSP)

Definition: Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.

Benefits:

• loose coupling
• Code more reusable.
• Class hierarchies easy to understand.

---

4. Interface segregation principle (ISP)

Definition: many client-specific interfaces are better than one general-purpose interface

Benefits:

• Decoupled system.
• Code easy to refactor.

---

5. Dependency Inversion Principle (DIP)

Definition: High-level modules should not depend on low level modules, rather both should depend on abstraction. Abstraction should not depend on details; rather detail should depend on abstraction.

Benefits:

• high cohesion.
• Reduce the coupling.
• Code more reusable.

---

More Information

• https://android.jlelse.eu/solid-principles-the-definitive-guide-75e30a284dea
• https://apiumhub.com/tech-blog-barcelona/solid-principles/
• What is high cohesion and how to use it / make it?
• https://hackernoon.com/microservices-bounded-context-cohesion-what-do-they-have-in-common-1107b70342b3

---

Books

• Steve McConnell's Code Complete
• Uncle Bob's Clean Code

Sacrament

Thanks for your extensive answer, it helps a lot. To clarify, by saying that these two objectives are contradictory I meant "achieving" a project with highly cohesive and loosely coupled design is a contradictory-objective problem, meaning that if maximum cohesion is met, coupling would be maximum too and vice versa. So our aim is to balance them properly. My question is whether there is an approach to do so. Also, is there any criteria to keep this balance between cohesion and coupling ? Or only meeting SOLID principles guarantees that ? Thanks for your time MohammadReza. – Mattheus

there no tangible method to measure this balance but applying these principles guarantees that your system is being built with high degree of cohesion and loose coupling. there are also many other principles mentioned in the books I have referenced to, but the top 5 are SOLID principles. – Sacrament

Answer 2

According to Wikipedia (https://en.wikipedia.org/wiki/Cohesion_(computer_science))

High cohesion often correlates with loose coupling, and vice versa

So the target is to achieve high cohesion and loose coupling. To achieve it you need to develop classes that do only one thing, split monolithic project into several modules (DAO, UI, business logic) and program to an interface so that other classes (or other modules) do not know anything about internals of other classes/modules and know only external contracts (interfaces/API).

Exsect

Answer 3

I wasn't familiar with the concept of cohesion before reading your question. From Wikipedia (here):

Modules with high cohesion tend to be preferable, because high cohesion is associated with several desirable traits of software including robustness, reliability, reusability, and understandability. In contrast, low cohesion is associated with undesirable traits such as being difficult to maintain, test, reuse, or even understand.

Cohesion is often contrasted with coupling, a different concept. High cohesion often correlates with loose coupling, and vice versa.

I think you want high cohesion within each module and loose coupling between them, which can be achieved by having modules to only communicate through simple abstract interfaces. To define these interfaces, you will need to design a clean separation of concerns, where all tightly coupled tasks are done in the same class while tasks with a different granularity (e.g. high-level algorithm versus low-level implementation detail) are separated out and abstracted away by interfaces.

Idolize

Thanks for your answer. That is informative. I am still wondering if there is any set of rules to reach an optimal balance between cohesion and coherence. Or as @MohammadReza commented, there is no panacea to do so ? – Mattheus

I'm not sure, I don't apply a lot of theory in my coding style, or at least not consciously. It's more a matter of feeling for me, a sense of order and coherence, but I don't rationalize it enough to have strong opinions on topics like cohesion vs coupling :p – Idolize