Menu
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.
740
High cohesion correlates with loose coupling. A module having its elements tightly related to each other and serving a single purpose would sparingly interact and depend on other modules. Thus, will have loose coupling with other modules. Similarly, the tight coupling could be a sign of low cohesion.
The gist of the 'cohesive classes reduce coupling' phrase is to say that if you build smaller, focused modules, each of them will likely be less coupled than larger, less focused modules. More cohesion allows for more flexibility when composing your modules.
Abstraction is the Key. To achieve loose coupling, one should use abstract classes or interface while performing inheritance.
Cohesion refers to the degree to which the elements of a module belong together. In a good software design, it is always desirable to have less interaction among modules (Low coupling). Advantages of high cohesion (or “strong cohesion”) are: 1) Reduced module complexity (they are simpler, having fewer operations).
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 :
Definition: There should be never more than one reason for a class to change.
Benefits:
Definition: Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.
Benefits:
Definition: Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.
Benefits:
Definition: many client-specific interfaces are better than one general-purpose interface
Benefits:
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:
More Information
Books
115
answered Sep 21 '22 11:09
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).
20
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
