Highly cohesive and lowly coupled are the usual qualities required of a well design module. But is the same? Can a module be at the same time cohesive, yet coupled?
And if so, would that reflect a good design or not?
It is possible to have a module both highly cohesive and highly coupled. However, that would not be desirable, in general. Generally speaking, the ideal is high cohesion and low coupling.
As mentioned in the previous answer, coupling is more syntactic than cohesion. So it is easier and more straightforward to measure coupling. Ideally, cohesion is more a matter of semantic identification of what a module does. We've been working on empirical studies to show that "concern-based cohesion" has a different dimension of cohesion measurement than "structural cohesion" and also that "concern-based cohesion" is a better indicator of change-proneness in comparison with the traditional and structural way of measure coheison (see attached).
Conference Paper Concern-Based Cohesion: Unveiling a Hidden Dimension of Cohe...
Conference Paper An Empirical Study on How Developers Reason about Module Cohesion
A module can, at the same time, be highly cohesive and highly coupled, as Stefan Gruner has explained before. This situation should not be evaluated as a bad design; in fact, it is a common situation. A highly cohesive module which performs a single, well defined, function can be called from many other modules that need its service.
Take, for instance, a module DisplayErrorMessage that formats and presents to the user all kinds of different messages of error in a standard fashion. It could be invoked from every other module where an error could be originated, thus producing a high level of coupling, which is more desirable than the alternative of replicating the code to display error messages throughout every module in the program/system.
I do think that these two properties are related to each other somehow. Indeed, the high cohesion entails a certain kind of specialization of the module. Higher is this specialization, dependent becomes the module.
We should look at coupling in three perspectives, one way, fan out, fan it, or mutual dependency.
Mutual dependency increases coupling but does not reduce cohesion. Modules become hard to understand (opposite of cohesion, doing a lot of coordination).
In general sense, they are the enemy of each other.