Connascence is evaluated along three dimensions — strength, locality, and degree. Define each, and state the refactoring rules that follow from them.

### Why three dimensions, not one Saying "this is connascence of position" is only half a judgement. Positional arguments in a two-parameter private helper used once are irrelevant; the same positional coupling in a public wire format used by forty consumers is a migration project. The three dimensions turn the taxonomy into a **priority function**. ### 1. Strength Strength = how difficult the connascence is to **discover** and how risky it is to **change**. The conventional ordering, weakest first: **Static (readable in the code):** Name → Type → Meaning/Convention → Position → Algorithm **Dynamic (only at run time):** Execution Order → Timing → Value → Identity Every static form is weaker than every dynamic form, because static forms are visible to compilers, linters, greps, and IDE refactorings, whereas dynamic forms require running the system — often under specific concurrency or load — to expose. The operational meaning of "weaker": if I change one side, how likely am I to be *told* about the other side, and how mechanical is the fix? Renaming a method: the IDE finds every site. Changing a hash algorithm on one side of a wire protocol: nothing tells you, and production breaks. **Demotion refactorings** (the practical payoff): - meaning → name: magic value → named constant or enum. - position → name: positional parameters → named parameters / parameter object / keyed map. - algorithm → name+type: extract the algorithm into a single shared, versioned library or service call. - execution order → type: return the next-stage object from the previous step, so illegal sequences don't type-check (builder / typestate / fluent stage interfaces). - timing → execution order or type: replace sleeps with explicit signals, handshakes, or idempotent retries. - value → single owner: put co-varying values inside one object/aggregate that enforces the invariant atomically, or derive instead of duplicating. - identity → explicit injection: pass the one shared instance in rather than having each side look it up. ### 2. Locality Locality = the **distance** between the connascent elements, measured in encapsulation boundaries crossed: same expression/block → same method → same class → same package/module → same component → same deployable → separate deployables/teams/organizations. The key claim: **as locality decreases (distance grows), acceptable strength drops sharply.** Strong connascence within a five-line function is fine — you see it all at once and change it in one commit. The same strength between two services owned by different teams means coordinated releases, versioned contracts, backward-compatibility windows, and cross-team meetings. This is why the same construct can be good or terrible depending on where it lives: positional tuple destructuring inside one function is idiomatic; a positional CSV contract between two organizations is a liability. ### 3. Degree Degree = the **number of elements** entangled by this instance of connascence. A magic status code understood in 2 places vs 200. A shared date format used by 3 modules vs every service. High degree amplifies everything: the cost of change scales with degree, and the chance of a missed site scales with degree. It is also the dimension most amenable to incremental improvement — you can shrink degree by funnelling access through a single adapter or facade before you attempt to change strength. ### Page-Jones's rules 1. **Minimize overall connascence** by decomposing the system into encapsulated elements. 2. **Minimize connascence that crosses encapsulation boundaries.** 3. **Maximize connascence within an encapsulation boundary.** Rule 3 surprises people, but it is precisely **cohesion**: things that must change together should live together. Splitting strongly connascent code across modules is how you create the worst kind of coupling — strong *and* remote. Conversely, if two modules turn out to be strongly connascent, the honest fix is often to *merge* them, not to add an interface between them. Note the direct link to the modular monolith / microservice debate: a service boundary drawn through strong connascence produces a distributed monolith. "Where are the strong connascences?" is a better boundary-finding question than "what are the nouns?". ### The triage matrix in practice | Strength | Locality | Degree | Action | |---|---|---|---| | strong (dynamic) | remote (cross-service) | high | Top priority — this is what causes outages and lock-step deploys | | strong | remote | low | Fix or document explicitly (deployment ordering, contract test) | | strong | local (one class) | any | Usually fine — leave it, but keep the unit small | | weak (name/type) | remote | high | Acceptable; this is what a published API *is* | | weak | local | low | Ignore | Guardrails that operationalize it: contract tests and schema registries convert remote connascence of meaning into checked connascence of name/type; consumer-driven contracts limit degree by making consumers explicit; fitness functions can fail a build when a strong form crosses a named boundary.