Connascence

What connascence is

Meilir Page-Jones introduced connascence in 1992 as a unifying metric that subsumes both coupling and cohesion into one vocabulary. Two components are connascent if a change to one requires a corresponding change to the other. The framework classifies why that change is required — whether it is a shared name, a shared type, a shared algorithm, a shared execution order, or a shared timing — and grades how costly the dependency is along three dimensions: strength, locality, and degree.

The coupling ladder from lesson 01 told you what is shared (internals, shared state, control flags, data structures, primitives). Connascence tells you why a change to one component forces a change to another, and it extends the vocabulary to runtime dependencies that the coupling ladder does not reach.

Static connascence: compile-time dependencies

Static connascence is detectable without running the program. A type checker or linter can find it.

Connascence of Name (CoN): two components must agree on a name. The billing engine calls order.getConfirmedItems(). If the order module renames getConfirmedItems to getApprovedLineItems, billing breaks. CoN is the weakest static connascence — a rename refactor fixes it everywhere automatically.

Connascence of Type (CoT): two components must agree on a type. The billing engine accepts (order: ConfirmedOrder). If the order module changes ConfirmedOrder to ApprovedOrder, billing’s parameter type becomes stale. CoT is stronger than CoN — a type rename requires updating every reference that declares the type, not just callers.

Connascence of Meaning (CoM) (also called Connascence of Convention): two components must agree on what a value means. If the order status is encoded as an integer (0 = pending, 1 = confirmed, 2 = cancelled) and billing checks if (order.status === 1), both modules are coupled to the integer convention. When the order module adds a new status (3 = partially fulfilled), billing’s integer check silently misclassifies the new state. CoM is significantly stronger: the coupling is invisible to the compiler and often produces silent runtime failures rather than build failures.

Connascence of Position (CoP): two components must agree on the order of arguments. If billing calls a shared utility as applyDiscount(orderId, percentage, reason) and the utility’s signature is later changed to applyDiscount(reason, percentage, orderId), the caller silently passes the wrong values to each parameter — the code compiles, the types may even match, but the behaviour is wrong. CoP is stronger than CoM because positional coupling is invisible to the caller’s source code: the function name has not changed, the types may not have changed, yet the contract has shifted under the caller. The weakening move is to replace positional arguments with a named parameter object — applyDiscount({ orderId, percentage, reason }) — so the call site is independent of argument order.

Connascence of Algorithm (CoA): two components must use the same algorithm. If billing hashes order IDs for audit log keys using the same MD5 implementation that the order module uses to generate them, both must stay in sync on the hashing algorithm. Changing the algorithm in one without the other produces keys that do not match. CoA is strong: the dependency is not expressed in any type or interface — it lives in the implementation.

Dynamic connascence: runtime dependencies

Dynamic connascence is not detectable by analysis — it requires observing the running system.

Connascence of Execution (CoE): two components must execute in a specific order for correct behavior. The billing module must call validateOrder() before generateInvoice() before triggerPayment(). If any caller skips a step or reverses the order, the system fails at runtime in ways that may not be immediately obvious. CoE is stronger than all static forms because it is invisible to static analysis and the failure mode depends on timing.

Connascence of Timing (CoT*): two components must execute within a time window of each other. A billing webhook receiver must process a payment confirmation within thirty seconds of the order service posting it, or the order times out. This is runtime scheduling coupling: the dependency is on the clock, not on code structure.

Connascence of Values (CoV): two components must agree on the value of related data at runtime. If the billing engine and the order service both maintain a copy of the order total, they must agree. When billing applies a late discount and updates its copy but the order service does not update its copy, the system has inconsistent state. This is distributed state coupling — the strongest and most dangerous form.

Connascence of Identity (CoI) (strongest): two components must reference the same object in memory or the same entity in storage. If billing holds a direct reference to the same Order object that the order service is mutating, both are coupled to the object’s identity and mutation history. This is the runtime equivalent of content coupling.

Three grading dimensions: strength, locality, degree

Knowing the type of connascence is not enough — you also need to know how costly it is. Three dimensions grade the cost:

Strength is the primary axis and follows the type ordering described above. CoN is weaker than CoM; CoE is weaker than CoV. Stronger connascence is more costly to manage because it requires more coordination when either side changes, and failures are often less visible.

Locality measures how close the connascent components are. Two classes in the same package sharing CoM (a convention about integer status codes) is local connascence — it can be enforced by code review and is easy to audit. Two services in different bounded contexts sharing CoM through a shared event schema is distant connascence — each side may evolve independently without noticing the other has changed the meaning of the value. Distant connascence is far more dangerous than local connascence of the same strength.

Degree measures how many elements are involved. CoN between two functions is a point dependency — one rename. CoN between a widely-used constant and thirty call sites is high-degree — one rename plus thirty updates. High-degree connascence amplifies the cost of any change proportionally.

Using connascence to rank refactors

The power of connascence is that it turns “this code is messy” into “here is the specific dependency to weaken and here is how.” Three rules guide the ranking:

1. Weaken first, then eliminate. A connascence of meaning (integer status codes) can be weakened to connascence of type (a typed enum) before being eliminated entirely (event-driven communication with no shared status). Weakening is cheaper than eliminating and is often enough.

2. Localize second. If a strong connascence must exist, pull it inside a single module’s boundary. Two services sharing a CoM can be refactored so that one service owns the convention and translates it for the other — now only one side holds the strong connascence, and the other side sees only CoN (a method name) or CoT (a type).

3. Reduce degree. If you cannot weaken or localize, reduce the number of elements involved. Replace the integer status with a typed constant that is imported by reference — now only one definition exists and all thirty call sites hold CoN rather than CoM.

In the B2B platform, when billing and ordering shared the integer status convention (CoM, distant, degree 30), the ranked refactor was: introduce a OrderStatus enum that both sides import (weakened to CoT, localized to one shared library, degree reduced to one definition). The thirty integer checks become thirty typed comparisons — the compiler now catches the coupling instead of silent runtime misclassifications.