Connascence
Connascence (/kəˈneɪsəns/) is a software quality metric invented by Meilir Page-Jones to allow reasoning about the complexity caused by dependency relationships in object-oriented design much like coupling did for structured design. In software engineering, two 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. In addition to allowing categorization of dependency relationships, connascence also provides a system for comparing different types of dependency. Such comparisons between potential designs can often hint at ways to improve the quality of the software.
Strength
A form of connascence is considered to be stronger if it is more likely to require compensating changes in connascent elements. The stronger the form of connascence, the more difficult and costly it is to change the elements in the relationship.
Degree
The acceptability of connascence is related to the degree of its occurrence. Connascence might be acceptable in limited degree but unacceptable in large degree. For example, a function or method that takes two arguments is generally considered acceptable. However, it is usually unacceptable for functions or methods to take ten arguments. Elements with a high degree of connascence incur greater difficulty, and cost, of change than elements that have a lower degree.
Locality
Locality matters when analyzing connascence. Stronger forms of connascence are acceptable if the elements involved are closely related. For example, many languages use positional arguments when calling functions or methods. This connascence of position is acceptable due to the closeness of caller and callee. Passing arguments to a web service positionally is unacceptable due to the relative unrelatedness of the parties. The same strength and degree of connascence will have a higher difficulty and cost of change, the more distant the involved elements are.
Types
This is a list of some types of connascence ordered approximately from weak to strong forms.
Static connascences
Connascenses are said to be "static" if they can be found by visually examining the code.
Connascence of name (CoN)
Connascence of name is when multiple components must agree on the name of an entity. Method names are an example of this form of connascence: if the name of a method changes, callers of that method must be changed to use the new name.
Connascence of type (CoT)
Connascence of type is when multiple components must agree on the type of an entity. In statically typed languages, the type of method arguments is an example of this form of connascence. If a method changes the type of its argument from an integer to a string, callers of that method must be changed to pass a different argument than before.
Connascence of meaning (CoM) or connascence of convention (CoC)
Connascence of meaning is when multiple components must agree on the meaning of particular values. Returning integers 0 and 1 to represent false and true, respectively, is an example of this form of connascence.
Connascence of position (CoP)
Connascence of position is when multiple components must agree on the order of values. Positional parameters in method calls are an example of this form of connascence. Both caller and callee must agree on the semantics of the first, second, etc. parameters.
Connascence of algorithm (CoA)
Connascence of algorithm is when multiple components must agree on a particular algorithm. Message authentication codes are an example of this form of connascence. Both sides of the exchange must implement exactly the same hashing algorithm or the authentication will fail.
Dynamic connascence
Connascenses are said to be "dynamic" if they can only be discovered at runtime.
Connascence of execution (CoE)
Connascence of execution is when the order of execution of multiple components is important.
Connascence of timing (CoT)
Connascence of timing is when the timing of the execution of multiple components is important.
Connascence of values (CoV)
Connascence of values is when several values must change together.
Connascence of identity (CoI)
Connascence of identity is when multiple components must reference the same entity.
Reducing connascence
Reducing connascence will reduce the cost of change for a software system. One way of reducing connascence is by transforming strong forms of connascence into weaker forms. For example, a method that takes several arguments could be changed to use named parameters. This would change the connascence from CoP to CoN. Reducing the degree and increasing locality of involved elements constitute other ways to reduce connascence.
References
- Grand Unified Theory of Software Design, Jim Weirich
- Meilir Page-Jones, Comparing techniques by means of encapsulation and connascence, Communications of the ACM, Volume 35, Issue 9
- What Every Programmer Should Know About Object Oriented Design, Meilir Page-Jones, Dorset House Publishing, ISBN 0-932633-31-5
- Fundamentals of Object-Oriented Design in UML, Meilir Page-Jones, Addison-Wesley Pub Co; ISBN 0-201-69946-X
- Manuel Rivero; Aug 9, 2018; Connascence: A Look at Object-Oriented Design in Java