In this article, I discuss the similarities and differences between the structured and object-oriented approaches to software design by means of two principles: encapsulation and connascence. I conclude by suggesting experiments involving connascence, the use of tools to mediate its effects and a set of steps necessary to define any new design paradigm.
However, to do so would be to overlook a chance to generalize coupling and cohesion into the single measure of connascence.(2)
int i; and B to be the assignment: i : = 7; There are at least two examples of connascence between A and B.
(2) I chose the word "connascence" from the Latin roots meaning "born together." It is etymologically close to the French "connaissance" meaning knowledge, awareness or consciousness.
The ideals of low coupling and high cohesion now generalize beyond structured design and yield a statement that is applicable to object-oriented design (or indeed to any future design paradigm with partitioning, encapsulation and visibility rules): Eliminate any unnecessary connascence and then minimize connascence across encapsulation boundaries by maximizing connascence within encapsulation boundaries.
One prediction of connascence, as applied specifically to object-oriented design, relates to the use of inheritance.
Therefore, connascence tells us that inheritance by a subclass from a superclass should be restricted to only those features of the superclass that are already externally visible.
Another object-oriented design prediction of connascence recommends foregoing the use of the C++ "friend" construct--a construct that blatantly promotes connascence across encapsulation boundaries.
Here we see two forms of connascence: name and type.
These forms of connascence are generic, in the sense that they could be defined in almost any design paradigm.