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.)
