Principles of software development: High Cohesion

High cohesion refers to designing classes or modules with a focused, well-defined purpose, akin to a specialist in a specific field.

This is particularly important in UI/UX design, where components should be dedicated to specific user experience elements.

Low coupling, on the other hand, emphasizes the independence of classes or modules, akin to a team working independently with minimal dependencies. This principle is crucial in full-stack development, where the backend and frontend should interact through well-defined APIs for flexibility and adaptability.

Martin Fowler emphasizes the importance of high cohesion in building robust and maintainable software systems.

In his book "Refactoring: Improving the Design of Existing Code," Fowler discusses cohesion as one of the key principles for writing clean, understandable, and maintainable code.

According to Fowler, high cohesion refers to the degree to which the elements within a module or component work together towards a common purpose.

A module exhibits high cohesion when its internal components, such as functions or classes, are closely related and focused on achieving a specific, well-defined task.

This contrasts with low cohesion, where the internal components lack a clear, unified purpose and may be unrelated or loosely tied together.

Fowler identifies several types of cohesion, ranging from the strongest, functional cohesion, to the weakest, coincidental cohesion:

1. Functional Cohesion:
   Components within a module are grouped together because they contribute to a single, well-defined task. This is the most desirable form of cohesion.

2. Sequential Cohesion:
   Components are related because they must be executed in a specific order. While not as strong as functional cohesion, it is still reasonable.

3. Communicational Cohesion:
   Components are grouped together because they operate on the same data. This form of cohesion is often acceptable but should be used judiciously.

4. Procedural Cohesion:
   Components are grouped together because they are part of a larger procedure, although they may perform different tasks. This is weaker cohesion.

5. Temporal Cohesion:
   Components are grouped together because they are executed at the same time. This is a weaker form of cohesion and may indicate a lack of organization.

6. Logical Cohesion:
   Components are grouped together arbitrarily, sharing no specific relationship. This is a form of low cohesion and should be avoided.

7. Coincidental Cohesion:
   Components are grouped together arbitrarily with no meaningful relationship. This is the weakest and least desirable form of cohesion.

In summary, Fowler's insights on high cohesion emphasize the importance of organizing code in a way that promotes clarity, maintainability, and a shared purpose among the elements within a module.

By aiming for high cohesion, developers can create modular and understandable systems that are easier to maintain and extend over time.