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.
However, to do so would be to overlook a chance to generalize coupling and cohesion into the single measure of connascence.
There are at least two examples of connascence between A and B.
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.
This creates a great deal of connascence across major (class) encapsulation boundaries.
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.
These forms of connascence are generic, in the sense that they could be defined in almost any design paradigm.
For example, in the data dictionary of classic structured analysis (as defined in (3), for example) we have a variation on the connascence of type, even though there is no explicit mention of type.
The connascence between current-customer, and the type CUSTOMER would no longer exist.
An odd kind of connascence derived from polymorphism, which can be illustrated by the following example: Assume a hierarchy of classes and subclasses, C1, C11, C12, C111, C112, .
The issue of connascence is this: In line 1 we could have legally passed an object o11, of class C11, or an object o112, of class C112, or indeed an object of any of the subclasses of C1.