Connascence

Core Idea

Connascence is a sophisticated metric for measuring the degree to which one software component depends on another. It answers the question: “If I change this code, what else breaks?”

What Is Connascence?

Connascence refines the traditional concept of Coupling by providing a nuanced taxonomy of dependencies:

• While coupling tells us that modules are connected, connascence tells us how they are connected and what kinds of changes will propagate across module boundaries
• The term means “born together”—when two things are connascent, changing one necessitates changing the other
• Introduced by Meilir Page-Jones to capture subtleties that simple cohesion and coupling metrics miss

Types of Connascence

Connascence exists on a spectrum from static (detectable at compile time) to dynamic (only observable at runtime):

Static Connascence:

• Connascence of Name: Components must agree on a name (method names, variable names)
• Connascence of Type: Components must agree on a type
• Connascence of Meaning: Components must agree on value interpretation (e.g., “true means success”)
• Connascence of Position: Components must agree on the order of values (method parameters)
• Connascence of Algorithm: Components must agree on a particular algorithm

Dynamic Connascence:

• Connascence of Execution: The order of execution matters
• Connascence of Timing: The timing of execution matters
• Connascence of Values: Components must agree on certain values at runtime
• Connascence of Identity: Components must reference the same entity

Dynamic connascence is more problematic—it cannot be detected through static analysis and manifests only at runtime.

The Connascence Hierarchy

Page-Jones established three principles for managing connascence:

1. Minimize connascence across module boundaries — Strong boundaries reduce change propagation
2. Maximize connascence within modules — Related code should be tightly connected
3. Convert strong forms to weaker forms — Replace dynamic connascence with static connascence where possible

For example, converting “connascence of meaning” (implicit boolean flag meaning) to “connascence of name” (explicit enum values) makes dependencies more explicit and easier to maintain.

Why This Matters

Connascence provides architectural guidance that simple coupling metrics cannot:

• Explains why certain refactorings reduce maintenance burden
• Reveals hidden dependencies that cause seemingly unrelated code to break together
• Guides decisions about where to draw module boundaries
• Enables prioritizing refactoring to convert fragile dependencies to weaker, more maintainable forms

Related Concepts

• Coupling — The broader concept connascence refines
• Cohesion — Complementary; strong cohesion within modules supports weak connascence across boundaries
• Modularity — The organizing principle that connascence helps measure
• Measuring-Architecture-Characteristics — Connascence is one metric for assessing structural quality
• Architectural-Governance — Connascence analysis can be automated through fitness functions

Sources

• Richards, Mark and Neal Ford (2020). Fundamentals of Software Architecture: An Engineering Approach. O’Reilly Media. ISBN: 978-1-492-04345-4.

  • Chapter 3: Modularity — Discusses connascence as a sophisticated coupling metric
  • Available: https://www.oreilly.com/library/view/fundamentals-of-software/9781492043447/

• Page-Jones, Meilir (1992). “Comparing Techniques by Means of Encapsulation and Connascence.” Communications of the ACM, Vol. 35, No. 9, pp. 147-151.

  • Original introduction of connascence concept
  • DOI: 10.1145/130994.131004

Note

This content was drafted with assistance from AI tools for research, organization, and initial content generation. All final content has been reviewed, fact-checked, and edited by the author to ensure accuracy and alignment with the author’s intentions and perspective.