Connascence (computer programming)

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.

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

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.

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

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

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.