Connascence 101

(Talk delivered in 2023 and 2024 at two different companies)

What makes software difficult to change? Often, it's the dependencies between different parts of the code.

**Connascence** provides a more precise vocabulary for understanding and reasoning about coupling, cohesion, and software design.

In this introductory talk, we'll explore the different types of connascence (static and dynamic), their properties (strength, degree, and locality), and practical guidelines for identifying design problems and making better refactoring decisions.

The goal isn't to introduce yet another set of rigid rules, but to discover a useful tool for discussing software design, making informed trade-offs, and building software that's easier to understand, test, and evolve.

Ultimately, it's about what really matters: **enabling the continuous and sustainable delivery of value.**

1. Connascence 101 May nth, 2024 Isidro López
4. “Standing on the shoulders of giants” • • • • Codesai Meilir Page-Jones Jim Weirich Kevin Rutherford
5. The GOAL Discovering the existence of one more “tool” which might be handy in the future for better delivering value in a continuous and sustainable way 😊
6. Language MATTERS "The limits of my language mean the limits of my world" "My difficulty is only an — enormous — difficulty of expression." (L. Wittgenstein) "If we used a different vocabulary or if we spoke a different language, we would perceive a somewhat different world." https://www.pioneernetwork.net/wp-content/uploads/2016/10/The-Power-of-Language-to-Create-Culture.pdf
7. What is “connascence”? https://en.wiktionary.org/wiki/connascence
8. What is “connascence”? • “A software quality metric & a taxonomy for different types of coupling” • “A general way to evaluate design decisions in an OO design” • “A way to discuss the quality of an OO design, generalizing the measurement of coupling and cohesion, with a more precise vocabulary” Two elements of software are connascent if they are "born together" in the sense that they somehow share the same destiny. [...] I define two software elements A and B to be connascent if there is at least one change that could be made to A that would necessitate a change to B in order to preserve overall correctness Meilir Page-Jones: “Comparing techniques by means of encapsulation and connascence” (1992)
9. Coupling • Coupling measures the degree of interdependence between software components. • Coupling is the degree of relationship between software components. More “academic” definitions: • It measures the binding between code elements that are found in distinct modules. • A measure of the number and strength of connections between procedures. In object-oriented design, we want Coupling to be as low as possible, but not lower, or we end up e.g. with software that does “too much”. Avoid tight coupling; embrace loose coupling. https://leanpub.com/agiletechnicalpracticesdistilled
10. Cohesion Cohesion (noun): “When the members of a group or society are united.” • “Cohesion is a measure of how strongly related and focused the various responsibilities of a software module are, and it refers to the degree to which the elements of a module belong together” • Cohesion is the degree of relationship within a software component/module • It measures the binding between code elements that are found in the same component/module
11. Coupling and Cohesion “The ideal of structured design is to minimize the coupling of a system's design and to maximize the cohesion of the design” (Meilir Page-Jones)
12. Code smells “Code smells or ‘bad smells’ are certain structures in the code that indicate violation of fundamental design principles and negatively impact design quality” They are a collection of code quality antipatterns, to guide our refactorings and improve our design, but, sometimes they are not the ideal tool for this task: • Too fuzzy (e.g. “too many arguments”, “long method”, “data clump”, etc.) • Too much negative load or too judgemental: it’s easy to get emotional and people defensive, which complicates the conversation and improvement. Connascence tries to move the discussion/conversation to more “scientific-ish”/objective/aseptic terms in order to identify design problems 😊
13. When is there “connascence”? [Page-Jones] Connascence between two software elements A and B means either: 1. that you can postulate some change to A that would require B to be changed (or at least carefully checked) in order to preserve overall correctness, or 2. that you can postulate some change that would require both A and B to be changed together in order to preserve overall correctness. In plain English: there is connascence between two software elements when they must change together in order for the software to keep working correctly
14. The nine types of Connascence (Kevin Rutherford) Purely indicative, not prescriptive 😊 • Dynamic ◦ • Static ◦ https://habitablecode.substack.com/p/what-happened-to-connascence it depends on the execution patterns of the code at run-time it can be assessed from the lexical structure of the code
15. Three properties/axes of Connascence • Strength ◦ • Degree: the size of its impact ◦ • Stronger connascences are harder to discover, or harder to refactor. An entity that is connascent with thousands of other entities is likely to be a larger issue than one that is connascent with only a few. Locality: how close the two software elements are to each other ◦ Connascent elements that are close together in a codebase are better than ones that are far apart.
16. Static connascence: Connascence of Name (CoN) • Multiple components must agree on the name of an entity/component. • Example: ◦ method names: if the name of a method changes, callers of that method must be changed to use the new name.
17. Static connascence: Connascence of Position (CoP) • Multiple components must agree on the order of values. • Example: ◦ Positional parameters in functions/methods ▪ Possible solution: named parameters or specific objects (avoid “primitive obsession”). https://codesai.com/posts/2017/07/two-examples-of-connascence-of-position
18. Static connascence: Connascence of Meaning (CoM) • Multiple components must agree on the meaning of particular values. • Example: ◦ Magic numbers or returning None/null with some meaning ▪ Possible solutions: extract to semantic named constants/enums or create explicit objects, use of Maybe, Null Object pattern, etc. https://connascence.io/meaning.html https://slides.com/alfredocasado-1/deck#/9/1
19. Static connascence: summary • Connascence of Name (CoN): when multiple components must agree on the name of an entity. • Connascence of Type (CoT): when multiple components must agree on the type of an entity. • Connascence of Meaning (CoM) or Connascence of Convention (CoC): when multiple components must agree on the meaning of specific values. • Connascence of Position (CoP): when multiple components must agree on the order of values. • Connascence of Algorithm (CoA): when multiple components must agree on a particular algorithm. https://codesai.com/posts/2017/01/about-connascence
20. Dynamic connascence: Connascence of Execution (CoE) • The order of execution of multiple components is important. https://slides.com/alfredocasado-1/deck#/12/2
21. Dynamic connascence: summary • Connascence of Execution (order) (CoE): when the order of execution of multiple components is important. • Connascence of Timing (CoTm): when the timing of the execution of multiple components is important. • Connascence of Value (CoV): when there are constraints on the possible values some shared elements can take. • Connascence of Identity (CoI): when multiple components must reference the same entity. https://codesai.com/posts/2017/01/about-connascence
22. How “should” we apply connascence? Jim Weirich: • Rule of Degree: Convert strong forms of connascence into weaker forms of connascence. ◦ • E.g. Connascence of Meaning to Connascence of Name Rule of Locality: As the distance between software elements increases, use weaker forms of connascence. ◦ i.e. it might be ok to have CoM in the same method but not across different packages Page-Jones: 1. 2. 3. Minimize overall connascence by breaking the system into encapsulated elements. Minimize any remaining connascence that crosses encapsulation boundaries. Maximize the connascence within encapsulation boundaries.
23. How can we “measure” Connascence coupling? • “Your code as a crime scene” ◦ Book and talk “Treat Your Code as a Crime Scene • Adam Tornhill • GOTO 2016” ◦ Code Maat: ▪ • CodeScene (Comercial SaaS solution) ◦ • command line tool used to mine and analyze data from version-control systems Identify hotspots, couplings, etc. in order to prioritize strategic refactorings. Code forensics (last update: Mar 10, 2021) ◦ Enriched wrapper around Code Maat, also with UI. It can measure several types of coupling… even “developer coupling”
24. Final recap • Language matters: “the limits of my language mean the limits of my world” ◦ Having a common vocabulary enables and simplifies communication and understanding • “Code smell” is a too fuzzy (and potentially damaging) concept • “Connascence gives us a more precise vocabulary to talk and reason about coupling and cohesion” ◦ It can be applied at different scopes/contexts: classes, methods, files/folders, functions, modules, packages, code repositories, teams… ◦ It can be used as a tool to help prioritize what should be refactored first (always combined with other factors, like frequency of change or criticality (ie. how much a mistake in that line/method/class would cost to the company) ◦ Remember this a mean for end: enabling the continuous and sustainable delivery of value (in this enabling an evolutionary design easier to change, to understand, to test…)
25. Resources • “This is philosophy: Wittgenstein” (30 minutes video in Spanish) • Original paper from Meilir Page-Jones: “Comparing techniques by means of encapsulation and connascence” (1992) ◦ https://en.wiktionary.org/wiki/connascence • https://connascence.io/ • YOW! 2012 Jim Weirich - Connascence Examined (video, 52 minutes) • Connascence: How to Measure Coupling with Nick Hodges (video, 31 minutes) • https://habitablecode.substack.com/p/what-happened-to-connascence (Kevin Rutherford) • https://tooky.co.uk/connascence-and-inverting-dependencies/
26. Resources • Newsletter “Habitable code” (by Kevin Rutherford) • Codesai resources ◦ https://codesai.com/posts/2017/01/about-connascence ◦ https://codesai.com/posts/2017/07/two-examples-of-connascence-of-position ◦ https://slides.com/franreyesperdomo/connascence ◦ Video “OOP and connascence” (30 minutes, in Spanish) ◦ Listening to test smells: detecting lack of cohesion and violations of encapsulation
27. Books
28. https://es.fanpop.com/clubs/the-looney-tunes-show/images/38740983/title/thats-all-folks-wallpaper