Cohesion and coupling are options that are often discussed in object-oriented design circles. They are two ways to approach a solution. On the one hand, the solution can be a larger, self-contained approach. On the other hand, the solution can be a core that uses several “helpers” to achieve the objective(s). These are important options for us to consider as part of the overall OOD discussion. In this episode, we start with an overview of these common paths.
Cohesion Defined
There are many ways to think about Cohesion. However, I find it best to start with a common form of definition like the one found on Wikipedia.
In computer programming, cohesion refers to the degree to which the elements inside a module belong together. In one sense, it is a measure of the strength of relationship between the methods and data of a class and some unifying purpose or concept served by that class. In another sense, it is a measure of the strength of relationship between the class's methods and data themselves.
While we will not cover it at this point, note that there is an idea of a relationship among properties and methods in a class. This definition provides some foreshadowing in how we decide what method belongs where.
Coupling Defined
The ideas around coupling are much like cohesion. Therefore, let’s start again with a simple definition like the one found on Wikipedia.
In software engineering, coupling is the degree of interdependence between software modules; a measure of how closely connected two routines or modules are; the strength of the relationships between modules.
The key concept here is found in the mention of interdependence between modules. It is a different focus from the inside of the module reference in our definition of cohesion.
Cohesion and Coupling – Finding Their Place
These two approaches are often seen as opposites. Thus you take one approach or the other in your design. However, that is not required. There can be some large objects with little coupling or large objects that are rather cohesive (in general), yet they have a substantial number of helper objects. These patterns of design do bring up the idea of consistency across a solution. On the other hand, they provide ways to handle different problems within a system in the best manner for that problem.
The best way to look at these two options is to understand the strengths and weaknesses of each. Then we can find the best tool for the situation and expand our ways to solve each problem on its own.
