Functional Cohesion
The strongest form of cohesion, in which every element of a module contributes to a single well-defined task.
Cohesion has a well-known ordering, and knowing where a module sits on it tells you what is wrong with it.
Functional (strongest) — everything contributes to one task. Sequential — output of one element
is input to the next. Communicational — elements operate on the same data. Procedural — elements
follow a required order. Temporal — elements happen at the same time, such as an initialisation
routine. Logical — elements are the same kind of thing, such as a Utils class. Coincidental
(weakest) — no meaningful relationship.
The diagnostic value is practical: a module you cannot name without using "and", or "manager", "utility" or "helper", is usually logical or coincidental, and the name is the symptom.
The relationship with coupling is what makes both worth measuring. Splitting a module to increase cohesion typically increases coupling between the parts, so the goal is not maximum cohesion but the boundary where the coupling that remains is the least costly.
In service design this is the same judgement at a larger scale: a service with low cohesion changes for many unrelated reasons, so every team touches it — which is what produces a distributed monolith.