Today is Independence Day in the USA, which got me thinking about loosely-coupled “independent” software components. I was reminded
of a video I bookmarked quite a while ago
of Jim Weirich’s “Grand Unified Theory
of Software Design” talk at MountainWest RubyConf 2009. I finally watched that video this morning. I highly recommend it. In the video, Jim talks about software connascence. The dictionary definition
of connascence (con-NAY-sense) is: 1. The common birth
of two or more at the same time 2. That which is born or produced with another. 3. The act
of growing together. The brief Wikipedia page about Connascent Software Components says that: Two software components are connascent if a change in one would require the other to be modified in order to maintain the overall correctness
of the system. Connascence is a way to characterize and reason about certain types
of complexity in software systems. The term was introduced to the software world in Meilir Page-Jones’ 1996 book “What Every Programmer Should Know About Object-Oriented Design”. The middle third
of that book is the author’s proposed graphical notation for describing OO designs. UML became the standard about a year later, so a revised version
of the book was published in 1999 as “Fundamentals
of Object-Oriented Design in UML”. Weirich says that the third part
of the book, in which Page-Jones introduces the concept
of connascence “is worth the price
of the entire book”. (The price
of the entire book, by the way, is not much – I just bought a used copy on Amazon for $1.36, so that was a pretty low-risk investment. I’m looking forward to getting the book and learning about connascence from the original source.) Meanwhile, here’s my summary
of Weirich’s summary
of Page-Jones writings about connascence: The stronger the form
of connascence, the more difficult and costly it is to change the elements in the relationship. Some
of the connascence types, ordered from weak to strong are: Connascence
of Name Connascence
of name is when multiple components must agree on the name
of an entity. If you change the name
of a method or property, then you need to change all references to that method or property. Duh. Connascence
of name is unavoidable, assuming your objects are actually used. My main takeaway about connascence
of name is that it emphasizes the importance
of giving things good names so you don’t need to go changing them later. Connascence
of Type Connascence
of type is when multiple components must agree on the type
of an entity. I assume this is more
of a problem for languages without compilers (especially when used in apps without tests). I know it’s an issue with evil JavaScript type coercion. Connascence
of Meaning Connascence
of meaning is when multiple components must agree on the meaning
of particular values, e.g that “1” means normal customer and “2” means preferred customer. The solution to this is to use constants or enums instead
of “magic” strings or numbers, which reduces the coupling by changing the connascence form from “meaning” to “name”. Connascence
of Position Connascence
of positions is when multiple components must agree on the order
of values. This refers to methods with multiple parameters, e.g.: eMailer.Send("
[email protected]", "
[email protected]", "Your order is complete", "Order completion notification");
The more parameters there are, the stronger the connascence
of position is between the component and its callers. In the example above, it’s not immediately clear when reading the code which email addresses are sender and receiver, and which
of the final two strings are subject vs. body. Connascence
of position could be improved to connascence
of type by replacing the parameter list with a struct or class. This “introduce parameter object” refactoring might be overkill for a method with 2 parameters, but would definitely be an improvement for a method with 10 parameters.
This points out two “rules”
of connascence:
The Rule
of Degree: The acceptability
of connascence is related to the degree
of its occurrence.
The Rule
of Locality: Stronger forms
of connascence are more acceptable if the elements involved are closely related. For example, positional arguments in private methods are less problematic than in public methods.
Connascence
of Algorithm
Connascence
of algorithm is when multiple components must agree on a particular algorithm. Be DRY – Don’t Repeat Yourself. If you have “cloned” code in multiple locations, refactor it into a common function.
Those are the “static” forms
of connascence. There are also “dynamic” forms, including…
Connascence
of Execution
Connascence
of execution is when the order
of execution
of multiple components is important. Consumers
of your class shouldn’t have to know that they have to call an .Initialize method before it’s safe to call a .DoSomething method.
Connascence
of Timing
Connascence
of timing is when the timing
of the execution
of multiple components is important. I’ll have to read up on this one when I get the book, but assume it’s largely about threading.
Connascence
of Identity
Connascence
of identity is when multiple components must reference the entity. The example Weirich gives is when you have two instances
of the “Bob” Employee class and you call the .RaiseSalary method on one and then the .Pay method on the other does the payment use the updated salary?
Again, this is my summary
of a summary, so please be forgiving if I misunderstood anything. Once I get/read the book, I’ll make corrections if necessary and share any other useful information I might learn.
See Also:
Gregory Brown: Ruby Best Practices Issue #24: Connascence as a Software Design Metric (That link is failing at the time I write this, so I had to go to the Google cache
of the page.)
