Connascence

A measure of coupling: two components are connascent if changing one requires changing the other to keep the system correct. It comes in forms, static (connascence of name, type, meaning, position, algorithm) visible in the code, and dynamic (execution order, timing, value, identity) visible only at runtime, and in strength: how hard the coupling is to spot and to change.

Why it Matters

It gives a precise vocabulary for coupling beyond "tightly" or "loosely." You can compare two designs by the kind and strength of connascence they create, and improve a design by weakening the form of coupling (for example from connascence of position to connascence of name) and keeping any strong connascence local.

Signals

• Components that must always change together.
• Behavior that depends on parameter order (connascence of position).
• Two places that must agree on a magic value (connascence of meaning); code that breaks if calls happen in the wrong order (connascence of execution).

Benefits

A finer way to reason about and rank coupling, and concrete refactorings: weaken the form, and localize the strong forms.

Risks

Treating all coupling as equally bad; naming the forms instead of reducing the painful ones; ignoring dynamic connascence because it is invisible in the source.

Tensions

Some connascence is unavoidable wherever parts must cooperate; the goal is weaker forms and locality, not zero coupling. Reducing one form can introduce indirection that costs more than it saves.

Examples

Replacing positional arguments with named fields turns connascence of position into the weaker connascence of name; two services that must be deployed together exhibit strong dynamic connascence.