Cohesion (software / module-level)¶

Grade how tightly the responsibilities inside one code module turn around a single articulable purpose — from coincidental to functional — reading nameability, isolation-testability, and low-risk replaceability straight off the level.

Core Idea¶

In software engineering, cohesion is a graded measure of how closely the responsibilities placed inside one module belong together — how strongly its functions, data, and types all turn around a single, well-defined purpose rather than accumulating unrelated concerns by accident of location. High cohesion means the module is about something articulable in one sentence; low cohesion means it is merely full of things, the contents sharing only their file or package boundary. Cohesion pairs with coupling (the strength of dependencies across module boundaries) as the two primary diagnostic axes of modular structure, with the canonical design target being high cohesion within each module and low coupling between them. Constantine and Yourdon's 1970s taxonomy formalises cohesion as a ranked scale from worst to best: coincidental (contents share no relation), logical (grouped by category but not by data flow), temporal (grouped because executed at the same time, such as an initialisation routine), procedural (sequential steps of a process), communicational (all operating on the same data), sequential (each step's output is the next step's input), and functional (all contents contribute to exactly one single task). The ranking reflects a concrete consequence: as cohesion increases toward the functional end, the module becomes easier to name, easier to test in isolation, easier to replace with an alternative implementation, and easier to reason about without holding unrelated context in mind. The replaceability consequence is load-bearing — a functionally cohesive module can be substituted for another with the same purpose with low risk because the boundary captures something real; a coincidentally cohesive module cannot be substituted because no one can state what a valid substitute would have to do. LCOM (Lack of Cohesion in Methods) and its variants formalise the measurement for automated tooling by counting how many method pairs in a class share no instance variables — a proxy for whether the class is really about one thing or is several unrelated things colocated.

Structural Signature¶

Sig role-phrases:

the module boundary — the demarcated unit (class, package, service, API) whose cohesion is being judged
the responsibility set — the functions, data, and types the boundary collects; what the module's contents collectively do
the single-purpose relatedness reading — the graded measure of how tightly those responsibilities turn around one articulable purpose rather than sharing only their file or package
the Constantine-Yourdon scale — the seven-level ranking (coincidental → logical → temporal → procedural → communicational → sequential → functional) that names which accidental principle did any low-cohesion grouping
the articulability test — the cheap probe: can the module be described in one sentence without reaching for "and"? a list of unrelated jobs signals low cohesion
the LCOM measurement proxy — the metric (counting method pairs sharing no instance variable) that mechanizes "is this really one thing" for automated tooling
the replaceability consequence (load-bearing) — high cohesion makes a module substitutable at low risk because the boundary captures something real and a valid substitute's contract is statable; low cohesion blocks substitution because no one can state what a substitute must do
the local-reasoning / change-impact bound — as cohesion climbs toward functional, nameability, isolation-testability, and "what must I understand to change this safely" all improve together, collapsing a global question into a local one
the orthogonal coupling pairing — cohesion (relatedness within) is a separate dial from coupling (dependency between), and the two can be traded against each other, so a structural complaint must be attributed to the correct axis

What It Is Not¶

Not coupling. Cohesion is relatedness within a module; coupling is dependency between modules. They are orthogonal dials that can be traded against each other — code smeared across many files to break dependencies sacrifices cohesion to lower coupling, and the reverse stuffs unrelated code into one file. A structural complaint must be attributed to the correct axis, because a fix aimed at one cannot repair a defect in the other.
Not modularity or decomposition. Modularity is the partition into modules and decomposition is the act of splitting; cohesion judges the quality of each resulting module — whether the split was well-aimed at a single purpose. A system can be heavily modularized into many low-cohesion grab-bags, so the count of modules says nothing about whether each is about one thing.
Not the single-responsibility principle. SRP is a prescriptive rule; cohesion is the structural property the rule asks engineers to optimize. The principle is the instruction; cohesion (and its Constantine-Yourdon scale) is the measurable property being instructed toward — naming the rule as the property confuses the directive with the thing it directs at.
Not a binary good/bad verdict. Cohesion is graded on a seven-level ranking (coincidental → logical → temporal → procedural → communicational → sequential → functional). A reviewer reads not just "incoherent" but which kind of accidental grouping is present — temporal, logical, coincidental — and that level points directly at the decomposition that would fix it.
Not the same as low coupling delivering a good design. "High cohesion" and "low coupling" are two separate targets; achieving one does not grant the other. A tightly cohesive module can still be over-coupled to its neighbors, and a decoupled module can still be an internally incoherent grab-bag — both dials must be tuned, not just whichever is easier.
Not a software-only concept, nor a new pattern beside material or group cohesion. Software cohesion is one substrate of the catalog's group_cohesion parent — an internal binding force governing a unit's resistance to fragmentation — with responsibilities as the "members" and shared purpose as the "binding." The cross-domain pattern (paragraph, argument, narrative, team, droplet) runs through that parent; what is software-specific is the Constantine-Yourdon scale, LCOM, and the module-replaceability read-off, which have no referent for a water droplet or a social group.

Scope of Application¶

Software cohesion lives across the scales of modular structure within the software-engineering subfield of computer science, wherever a bounded code unit's contents are judged for how tightly they turn around one purpose; its reach is within that domain. The cross-domain cohesion of paragraphs, arguments, narratives, teams, and droplets runs through the catalog's group_cohesion parent — software being one more of its substrates — not through this construct, whose Constantine-Yourdon scale and LCOM metric have no referent outside code.

Module, package, and class design — the home: the first diagnostic a code reviewer applies ("what is this class actually about?"), with a "Utils" or "Manager" grab-bag indicting itself the moment its docstring is attempted.
Microservice boundaries — the bounded-context of domain-driven design is cohesion at the service level, each service encapsulating one well-defined business capability.
API design — a coherent API exposing operations that all turn around the resource it names, where unrelated endpoints bundled under one prefix are low-cohesion and hard to teach.
Architecture metrics and tooling — LCOM and its variants mechanizing the measurement so automated tools flag low-cohesion classes for review.
Codebase navigation and onboarding — cohesive structure letting a newcomer predict where a feature lives, where incoherent structure forces global search.
Design-principle discipline — information hiding (Parnas), the single-responsibility principle, and the Unix "do one thing well," each the same cohesion discipline restated as a rule.

Clarity¶

Naming cohesion converts a fuzzy quality judgment into a checkable test: it forces a designer to state the one purpose a module serves and to reject contents that do not contribute to it. The operative diagnostic becomes an articulability check — can the module be described in a single sentence without reaching for "and"? The moment the honest answer is a list of unrelated jobs, the cohesion is low, and a class named "Utils" or "Manager" indicts itself the instant someone tries to write its docstring. The Constantine-Yourdon scale further sharpens this from a yes/no into a graded reading: a reviewer can say not merely "this is incoherent" but "this is temporally cohesive, grouped because these steps run at startup, not because they share a purpose" — a precise label that points at what a better decomposition would look like.

Cohesion also dissolves a recurring confusion by separating two things the word "well-structured" runs together: relatedness within a module versus dependency between modules. Coupling and cohesion are orthogonal axes, and naming them apart exposes that they can be traded against each other — a team can lower coupling by smearing related code across many modules (wrecking cohesion to break dependencies), or raise cohesion's opposite by stuffing unrelated code into one file to avoid cross-module imports. Once a practitioner sees them as two separate dials rather than one vague notion of cleanliness, "is this a good decomposition?" becomes the answerable pair of questions — is each module about one thing, and do the modules depend on each other as little as possible — rather than an aesthetic gut call.

Manages Complexity¶

A large codebase is, in the raw, an intractable object: hundreds of modules, thousands of functions, an web of dependencies, no obvious place where any given concern lives and no way to reason about a part without, in principle, understanding the whole. Cohesion compresses the structural-quality side of that object onto a single graded reading per module — how tightly its contents turn around one purpose — and pairs with coupling, its orthogonal twin, so that the otherwise-amorphous question "is this a good decomposition?" collapses to two scalars per boundary: is each module about one thing, and do modules depend on each other as little as possible. The reviewer no longer holds the entire system in mind to judge structure; for each module they read off a cohesion level and a coupling degree, and the qualitative consequences follow from those two numbers — nameability, testability-in-isolation, replaceability, and local reasoning all rise together as cohesion climbs toward the functional end. The Constantine-Yourdon scale sharpens the cohesion axis from a yes/no into a seven-point ranking (coincidental through functional), so the reviewer reads not just "good or bad" but a specific level that names exactly what kind of accidental grouping is present and points at the decomposition that would fix it.

The deeper compression is what high cohesion buys for reasoning about the whole. When every module is functionally cohesive, the system can be understood one purpose at a time — to work on a feature, the engineer loads the one module that is about that purpose and need not hold unrelated concerns in mind, because the boundary guarantees nothing unrelated lives inside. The sprawl of "what do I need to understand to safely change this?" collapses from a global question into a local one bounded by a single module's stated purpose. This is also exactly what makes the replaceability read-off work: a functionally cohesive module can be swapped for another with the same one-sentence purpose at low risk, because the boundary captures something real, whereas a coincidentally cohesive one cannot, because no one can even state what a valid substitute must do — so the engineer reads substitution risk straight off the cohesion level rather than tracing every dependency by hand. The articulability test (can the module be described in one sentence without "and"?) is the cheap proxy that lets this whole judgment be made by inspection, and LCOM mechanises it for tooling by counting method pairs that share no instance variable — turning "is this really one thing?" into a number a machine can flag. Information hiding, single-responsibility, and "do one thing well" are the same compression restated: each is the instruction to keep cohesion high so the system stays reasoning-about-one-purpose-at-a-time rather than all-at-once.

Abstract Reasoning¶

Cohesion licenses a compact set of reasoning moves over modular structure, all keyed to one graded reading per module — how tightly its contents turn around a single purpose — and to its orthogonal pairing with coupling.

Diagnostic — infer the kind of bad grouping from the articulability signature. The defining move is the one-sentence test run as a probe: try to describe the module's purpose without reaching for "and." When the honest description is a list of unrelated jobs, the analyst infers low cohesion and, using the Constantine-Yourdon scale, reads which kind: contents that share nothing but their file are coincidental; grouped by category but not data flow, logical; grouped because they run at the same moment (an init routine), temporal; sequential steps, procedural; sharing data, communicational; output-feeding-input, sequential; all serving one task, functional. The diagnosis is not a binary verdict but a level that names exactly what accidental principle did the grouping — so a class named "Utils" or "Manager" indicts itself the instant someone tries to write its docstring, and the inferred level points directly at the remedy. LCOM mechanises the same inference for tooling: counting method pairs that share no instance variable is a proxy for "is this really one thing," letting a machine flag the low-cohesion classes the human would.

Boundary-drawing — separate the two axes and locate the concern on the right one. Before judging a decomposition, the analyst splits what "well-structured" fuses: relatedness within a module (cohesion) versus dependency between modules (coupling). These are orthogonal dials, so "is this a good decomposition?" is reasoned about as a pair of independent questions — is each module about one thing, and do modules depend on each other as little as possible — rather than a single aesthetic gut call. Drawing this boundary exposes that the two can be traded against each other, which is itself a diagnostic: code smeared across many modules to break dependencies has sacrificed cohesion to lower coupling; unrelated code stuffed into one file to dodge cross-module imports has sacrificed cohesion to lower coupling the other way. The analyst attributes a structural complaint to the correct axis before prescribing, because a fix aimed at coupling cannot repair a cohesion defect and vice versa.

Interventionist — raise cohesion to buy nameability, isolation-testability, and replaceability, and predict the gain. The characteristic intervention is to re-decompose toward the functional end, predicting a bundle of consequences that rise together as cohesion climbs: the module becomes easier to name (the one-sentence purpose now exists), easier to test in isolation (nothing unrelated is inside to drag in), easier to reason about locally, and — load-bearing — easier to replace. The replaceability prediction is the sharpest: the analyst reads substitution risk straight off the cohesion level, because a functionally cohesive module can be swapped for another with the same one-sentence purpose at low risk (the boundary captures something real, so a valid substitute's contract is statable), whereas a coincidentally cohesive one cannot be safely swapped at all (no one can even state what a substitute must do). So when a module resists substitution, the analyst predicts low cohesion as the cause and a purpose-aligned split as the fix.

Predictive — bound the change-impact and the load to understand from the cohesion reading. From a module's cohesion level the analyst predicts how much of the system must be held in mind to change it safely: when cohesion is functional, the question "what do I need to understand to modify this?" collapses from a global one to a local one bounded by the module's stated purpose, because the boundary guarantees nothing unrelated lives inside; when cohesion is low, the analyst predicts that a safe change requires loading unrelated concerns and that a newcomer cannot predict where a feature lives without global search. This lets the reviewer forecast maintainability and onboarding cost per module from the cohesion reading alone — information hiding, single-responsibility, and "do one thing well" are the same prediction restated as a discipline: keep cohesion high so the system stays reasoning-about-one-purpose-at-a-time rather than all-at-once.

Knowledge Transfer¶

Within software engineering cohesion transfers as mechanism, intact, across every scale of modular structure. From its module/class home it carries unchanged into microservice boundaries (the bounded-context of domain-driven design is cohesion at the service level — one well-defined business capability per service), into API design (a coherent API exposes operations all turning around the resource it names; unrelated endpoints bundled under one prefix are low-cohesion and hard to teach), into architecture metrics (LCOM and its variants mechanizing the measurement for automated flagging), and into codebase navigation and onboarding (cohesive structure lets a newcomer predict where a feature lives). Across all of these the full apparatus moves without translation: the one-sentence articulability test, the Constantine-Yourdon seven-level ranking (coincidental through functional), the orthogonal pairing with coupling, the replaceability consequence, and the change-impact prediction. Information hiding (Parnas), the single-responsibility principle, and the Unix "do one thing well" are the same cohesion discipline under other names. This is genuine within-domain mechanism transfer.

Beyond software the situation is the cleanest possible shared abstract mechanism: software cohesion is one substrate of a pattern the catalog already holds as a prime, so the cross-domain lesson should be carried by that parent rather than by the software construct. The portable core is group_cohesion — an internal binding force whose strength governs a unit's resistance to fragmentation — which already spans, as the prime's own broad use attests, materials science (intermolecular cohesion of matter), ecology, sociology, and organizational behavior. Software cohesion is that same node-and-edge binding pattern with one substitution: the "members" are responsibilities and the "binding" is shared purpose. The two are structurally identical — internal relatedness holding a unit together against the pull toward an incoherent grab-bag — which is exactly why the same shape recurs for the cohesion of a paragraph, an argument, a narrative, or a team, all co-instances of the one parent. So the genuine cross-domain transfer runs through group_cohesion (and the curation note that the prime might be renamed to a substrate-neutral cohesion / internal_binding to stop privileging its social-psychology origin), not through "software cohesion" as named. What stays home is the software-specific machinery: the Constantine-Yourdon scale, the LCOM metric, the coupling/cohesion design dial, the articulability-without-"and" probe, and the replaceability-of-a-module read-off all presuppose code modules with functions, data, and dependencies, and have no referent for a droplet of water or a cohesive social group. The honest move is to let the group_cohesion parent carry the cross-domain weight — software being one more of its substrates — and keep the Constantine-Yourdon-and-LCOM apparatus where modules give it content. Where that line falls is the subject of Structural Core vs. Domain Accent below.

Examples¶

Canonical¶

Contrast two modules against Constantine and Yourdon's scale. A TemperatureConverter module holds celsiusToFahrenheit, fahrenheitToCelsius, celsiusToKelvin, and their inverses: every function contributes to the one task of temperature-unit conversion, each step's inputs and outputs are the same domain, and the module answers the one-sentence test — "it converts temperatures between units" — with no "and." This is functional cohesion, the top of the scale. Now a Utils class holds formatDate, trimWhitespace, computeSalesTax, and parseConfigFile: the four share nothing but the file they sit in. Its honest description is a list — "it formats dates and trims strings and computes tax and parses config" — so it is coincidental cohesion, the bottom. The converter can be swapped for another temperature library at low risk; no one can even state what a valid replacement for Utils would have to do.

Mapped back: Each class is a module boundary enclosing a responsibility set; the single-purpose relatedness reading is high for the converter, near zero for Utils. The Constantine-Yourdon scale names them functional versus coincidental, and the articulability test (one sentence, no "and") is what separates them. The converter's easy substitution versus Utils's un-substitutability is the replaceability consequence read straight off the level.

Applied / In Practice¶

When teams decompose a monolith into microservices, cohesion is the operative criterion under the name of domain-driven design's bounded context. A common failure is slicing services by technical layer — a "database service," a "validation service," a "notification service" — which produces low-cohesion services whose contents share only a technical category (logical cohesion) and which must all change together whenever one business capability evolves. The corrected decomposition draws each service around a single business capability — Ordering, Payments, Inventory — so that each service is about one articulable purpose, can be developed and deployed by one team, and can be replaced or re-implemented behind a stable interface at low risk. Practitioners explicitly cite "a service should do one thing" as the test, which is module-level cohesion lifted to the service scale.

Mapped back: Each service is a module boundary; drawing it around one business capability maximizes the single-purpose relatedness reading. A layer-sliced "validation service" fails the articulability test the way a Utils class does. That a capability-aligned service can be re-implemented behind its interface at low risk, while a layer-sliced one cannot, is the replaceability consequence at the service scale.

Structural Tensions¶

T1: Cohesion versus coupling (two orthogonal dials that can be traded against each other). The canonical target is high cohesion within, low coupling between — but the two axes, though orthogonal, are tradable in practice, and optimizing one blindly damages the other. A team can lower coupling by smearing related code across many modules so no single file imports much, wrecking cohesion to break dependencies; or it can dodge cross-module imports by stuffing unrelated code into one file, sacrificing cohesion to lower coupling the other way. The tension is that "clean structure" is not one goal but two that pull apart under naive local optimization, so a structural complaint must be attributed to the correct axis before it is fixed — a coupling-motivated move can silently degrade cohesion, and a cohesion-motivated split can raise coupling. Diagnostic: Is a proposed restructuring improving one axis at the hidden expense of the other, and has the actual complaint been attributed to cohesion or to coupling before prescribing?

T2: The graded ranking versus context-dependent quality (the seven-level order is a heuristic, not a law). The Constantine-Yourdon scale's power is that it converts a yes/no verdict into a specific level that names the accidental principle behind a grouping and points at the fix. But the ranking asserts a universal quality order — temporal below communicational below sequential below functional — that real design sometimes inverts: a temporally cohesive initialization routine or a deliberately logical-cohesion facade can be exactly the right structure for its context, and a maximally functional split can be premature or over-fine. The tension is that the scale's crispness (a definite level with a definite better-than relation) buys diagnostic precision at the risk of treating a heuristic ordering as an absolute mandate to climb, when the appropriate level depends on what the module is for. Diagnostic: Is the module being pushed up the scale because its current level genuinely costs maintainability here, or because the ranking is being applied as a universal imperative regardless of context?

T3: The one-sentence articulability test versus gerrymandered or genuinely clustered purpose (a cheap probe that can be gamed or over-fire). "Describe it without reaching for 'and'" is the load-bearing cheap proxy that lets cohesion be judged by inspection and turns a Utils class into a self-indictment. But the probe is manipulable in both directions: a low-cohesion grab-bag can be relabeled with a vague umbrella noun ("it manages orders") that passes the one-sentence test while hiding ten unrelated jobs, and a legitimately cohesive module serving a tight cluster of related responsibilities can fail the literal no-"and" test even though its contents genuinely belong together. The tension is that the test's cheapness comes from operating on the description, which is a lossy stand-in for the actual purpose-relatedness it means to measure. Diagnostic: Does the module's one-sentence description name a real single purpose, or has an umbrella abstraction been chosen precisely to smuggle an unrelated grab-bag past the "and" test?

T4: Maximizing per-module cohesion versus system-level fragmentation (the functional end can shatter the whole). Every consequence the scale promises — nameability, isolation-testability, replaceability, local reasoning — rises toward the functional end, which pressures a designer to split until each module does exactly one task. But pushed to its limit that discipline multiplies modules, and a system of very many tiny maximally-cohesive units raises the module count, the number of boundaries, and often the inter-module coupling and navigational overhead. The tension is that cohesion is a per-unit virtue whose unbounded local maximization can degrade a global property (comprehensibility of the whole, total coupling) that the same design values. Perfect cohesion of each part is not the same as the best decomposition of the system. Diagnostic: Would splitting this module further genuinely lower the cost of understanding and changing it, or would it fragment a coherent concern into pieces whose recombination cost exceeds the cohesion gained?

T5: The LCOM metric versus the semantic property it proxies (a countable stand-in for a judgment about meaning). LCOM mechanizes cohesion for tooling by counting method pairs that share no instance variable — turning "is this really one thing?" into a number a machine can flag. That mechanization is what lets automated review scale. But shared-instance-variable overlap is a syntactic proxy for a semantic property (shared purpose): methods can serve one articulable purpose while touching disjoint fields (so LCOM cries low cohesion falsely), or share fields while doing unrelated jobs (so LCOM passes a real grab-bag). The tension is that the only cohesion signal a tool can count is not the cohesion that matters, so the metric is indispensable for surfacing candidates and unreliable as a verdict. Diagnostic: Does the LCOM flag correspond to a genuine split in purpose, or is it a false signal from fields that happen to be shared or disjoint while the actual single-purpose relatedness runs the other way?

T6: Autonomy versus reduction (a software design property or one substrate of the group-cohesion prime). Software cohesion is a named, richly operationalized construct — the Constantine-Yourdon scale, LCOM, the coupling pairing, the articulability probe, the module-replaceability read-off — and within software it transfers intact across classes, services, and APIs. But its portable core is not proprietary: it is one substrate of the catalog's group_cohesion parent — an internal binding force governing a unit's resistance to fragmentation — with responsibilities as the "members" and shared purpose as the "binding," structurally identical to the cohesion of a paragraph, an argument, a narrative, a team, or a droplet. The tension is between a fully-equipped software discipline that earns its own tooling and the recognition that the cross-domain pattern belongs to the parent, of which software is merely one more substrate. Diagnostic: Resolve toward group_cohesion when carrying the internal-binding lesson to paragraphs, teams, or materials; toward software cohesion (with its Constantine-Yourdon scale and LCOM) when judging whether a code module turns around one purpose.

Structural–Framed Character¶

Cohesion (software) sits in the mixed band of the spectrum — its structural core is one of the cleaner prime-instantiations in this corpus, but the named construct carries an engineering-quality valence and discipline-specific measurement apparatus that pin it to code. On evaluative_weight it is intermediate: cohesion measures a real structural property (how tightly a module's contents turn around one purpose), but the Constantine-Yourdon scale is explicitly ranked worst-to-best and high cohesion is the design target, so a quality direction is baked into the named construct even though it is graded, not a binary verdict. On human-practice-bound the named construct points framed: it is about code modules — engineered artifacts with functions, data, and dependencies — and its apparatus has no purchase outside software; but the underlying binding it measures is substrate-general, so the instance is practice-bound while the pattern is not. Institutional_origin is likewise split: the Constantine-Yourdon seven-level taxonomy and the LCOM metric are 1970s software-engineering artifacts, while the property they operationalize (internal relatedness) is real. On vocab_travels the software-specific vocabulary (the seven-level scale, LCOM, the coupling dial, the articulability-without-"and" probe, module replaceability) is pinned to code and has no referent for a droplet or a social group — within software it carries intact across classes, services, and APIs. Import_vs_recognize is where its structural credentials are strongest: cross-domain the pattern is recognized, not imported, because software cohesion is literally one substrate of a prime whose other substrates (paragraphs, arguments, narratives, teams, water droplets) are genuine co-instances.

The portable structural skeleton is exactly the catalog prime group_cohesion — an internal binding force whose strength governs a unit's resistance to fragmentation — with responsibilities as the "members" and shared purpose as the "binding" (the entry flags that the prime might be renamed to a substrate-neutral cohesion/internal_binding to stop privileging its social-psychology origin). That skeleton is what software cohesion instantiates, and it is what carries across materials science, sociology, and rhetoric, while the Constantine-Yourdon scale, LCOM, and the coupling/cohesion design dial stay home where code modules give them content. Its character: a graded structural property that is a clean substrate-instance of the group-cohesion prime, wearing an engineering-quality ranking and a module-measurement apparatus (Constantine-Yourdon, LCOM) that keep the named construct mixed rather than the prime itself.

Structural Core vs. Domain Accent¶

This section decides why software cohesion is a domain-specific abstraction and not a prime, and it carries the case for its domain-specificity too — and here the case is unusually clean, because the entry is one substrate of a prime the catalog already holds.

What is skeletal (could lift toward a cross-domain prime). Strip the code away and a thin relational structure survives: a bounded unit collects a set of members, and an internal binding force — how tightly those members turn around one shared organizing purpose rather than sharing only their enclosure — governs the unit's resistance to fragmentation into an incoherent grab-bag. The portable pieces are abstract — a boundary, a member set, a graded internal-relatedness reading, and the consequence that a well-bound unit is nameable, stateable, and substitutable as a whole. That skeleton is genuinely substrate-portable, which is exactly why it is the catalog prime group_cohesion — an internal binding force whose strength governs a unit's resistance to fragmentation — with software cohesion arising by one substitution: the "members" are responsibilities and the "binding" is shared purpose. The same shape holds a paragraph, an argument, a narrative, a team, or a water droplet together, all co-instances of the one parent. But this binding structure is the core software cohesion shares with every other substrate, not what makes it software cohesion.

What is domain-bound. Everything that makes the concept software cohesion in particular is engineering machinery that presupposes code modules with functions, data, and dependencies. The Constantine-Yourdon seven-level scale (coincidental → logical → temporal → procedural → communicational → sequential → functional); the LCOM metric counting method pairs that share no instance variable; the orthogonal pairing with coupling as a design dial to be traded against; the articulability-without-"and" probe run on a docstring; and the module-replaceability read-off — swap a functionally cohesive module for another with the same one-sentence purpose at low risk. The decisive test: remove the code module — the functions, the shared instance variables, the deployable boundary — and none of this apparatus has a referent. A water droplet has no LCOM count, a social group no Constantine-Yourdon level, a paragraph no coupling dial. What survives is the bare internal-binding reading, no longer software cohesion but the parent prime it instantiates. The measurement apparatus that makes it "software cohesion" specifically is exactly the domain baggage the prime bar asks it to shed.

Why this does not clear the prime bar. A prime is a relational structure whose vocabulary travels and whose cross-domain transfer is recognition of the same mechanism, not analogy. Software cohesion's transfer is bimodal. Within software it travels intact as full mechanism across every scale of modular structure — classes, packages, microservice bounded-contexts, APIs, architecture metrics — carrying the whole apparatus (the scale, LCOM, the coupling pairing, the replaceability consequence) without translation. Beyond software it does not travel by metaphor but by recognition through the parent: the cohesion of a paragraph, a team, or a droplet is the same internal-binding pattern, genuinely recognized, but what is recognized there is group_cohesion, not the Constantine-Yourdon-and-LCOM machinery. Crucially, when the bare lesson — "an internal binding force governs whether a unit holds together or fragments" — is needed cross-domain, it is already carried, in more general form, by that parent (which the entry flags might be renamed to a substrate-neutral cohesion / internal_binding to stop privileging its social-psychology origin). The cross-domain reach belongs to group_cohesion, of which software is simply one more substrate; "software cohesion," as named, carries the module-measurement apparatus that should stay home where code gives it content.

Relationships to Other Abstractions¶

Current abstraction Cohesion (software / module-level) Domain-specific

Parents (1) — more general patterns this builds on

Cohesion (software / module-level) is a decomposition of Group Cohesion Prime

Software cohesion applies internal binding to responsibilities collected inside a module, with shared purpose supplying the binding force.

Hierarchy path (1) — routes to 1 parentless root

Cohesion (software / module-level) → Group Cohesion → Boundary

Not to Be Confused With¶

Coupling. The strength of dependencies between modules, cohesion's orthogonal twin (relatedness within). The canonical target is high cohesion and low coupling, but the two are separate dials that trade against each other: smearing related code across files to break dependencies lowers coupling while wrecking cohesion, and stuffing unrelated code into one file lowers coupling while wrecking cohesion the other way. A fix aimed at one cannot repair a defect in the other. Tell: is the complaint that a module is an internally unrelated grab-bag (cohesion), or that it depends too tightly on its neighbors (coupling)?
Modularity / decomposition. Modularity is the partition of a system into modules; decomposition is the act of splitting. These concern whether and how boundaries are drawn; cohesion judges the quality of each resulting module — whether the split was well-aimed at one purpose. A system can be heavily modularized into many low-cohesion grab-bags, so the module count says nothing about cohesion. Tell: is the question how many modules there are or how the system was carved (modularity/decomposition), or whether each carved-out module is actually about one thing (cohesion)?
Single-responsibility principle (SRP). The prescriptive design rule that a module should have one reason to change. SRP is the instruction; cohesion (and the Constantine-Yourdon scale) is the structural property the instruction directs toward. Naming the rule as the property confuses the directive with the thing it directs at — SRP tells you what to do, cohesion is what you measure to see if you did it. Tell: is it a rule an engineer is told to follow (SRP), or a graded property of a module you can read off and rank (cohesion)?
LCOM (Lack of Cohesion in Methods). The automated metric that counts method pairs in a class sharing no instance variable — a machine-countable proxy for cohesion, not cohesion itself. LCOM measures syntactic field-overlap, which can diverge from the semantic single-purpose relatedness it stands in for (methods can serve one purpose while touching disjoint fields, or share fields while doing unrelated jobs). It surfaces candidates; it does not deliver the verdict. Tell: is the object a countable field-sharing statistic a tool emits (LCOM), or the underlying is-this-really-one-thing judgment about purpose it approximates (cohesion)?
Separation of concerns / information hiding (Parnas). Design principles about which responsibilities to isolate behind a boundary and what to conceal within it. Like SRP, these are disciplines that produce high cohesion, not the property itself — information hiding is the strategy, cohesion the resulting internal relatedness. They are restatements of the same discipline as rules, not the measurable structural property. Tell: is it a principle prescribing how to draw and hide behind boundaries (separation of concerns / information hiding), or the graded structural quality of what ended up inside one boundary (cohesion)?
group_cohesion (the parent / umbrella). The substrate-neutral prime software cohesion instantiates — an internal binding force whose strength governs a unit's resistance to fragmentation — whose other substrates (a paragraph, an argument, a narrative, a team, a water droplet) are genuine co-instances, not analogies. This umbrella carries the cross-domain reach; software cohesion adds only the Constantine-Yourdon scale, LCOM, and the module-replaceability read-off, which have no referent for a droplet or a social group. Tell: is the binding being judged that of code responsibilities around a purpose (software cohesion), or that of any members around any organizing principle (the group_cohesion parent)?

Neighborhood in Abstraction Space¶

Cohesion (software / module-level) sits in a moderately populated region (45^th percentile for distinctiveness): it has near-neighbors but no dense thicket of look-alikes.

Family — Software Evolution & Systemic Laws (16 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-07-12