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.
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