Software Engineering for Students A Programming Approach

6.8 ● Coupling
6.8 Coupling 77
We are familiar with the idea of one component making a method call on another, but
what other types of interaction (coupling) are there between components? Which types
are good and which bad?
First, an important aspect of the interaction between components is its “size”.
The fewer the number of elements that connect components, the better. If components
share common data, it should be minimized. Few parameters should be passed
between components in method calls. It has been suggested that no more than
about 2–4 parameters should be used. Deceit should not be practiced by grouping
together several parameters into a record and then using the record as a single
parameter.
What about the nature of the interaction between components? We can distinguish
the following ways in which components interact. They are listed in an order that goes
from strongly coupled (least desirable) to weakly coupled (most desirable):
1. altering another component’s code
2. branching to or calling a place other than at the normal entry point
3. accessing data within another component
4. shared or global data
5. method call with a switch as a parameter
6. method call with pure data parameters
7. passing a serial data stream from one component to another.
We now examine each of these in turn.
1. Altering another component’s code
This is a rather weird type of interaction and the only programming language that normally
allows it is assembler. However, in Cobol the alter statement allows a program
to essentially modify its own code. The problem with this form of interaction is that a
bug in one component, the modifying component, appears as a symptom in another,
the one being modified.
2. Entering at the side door
In this type of interaction, one component calls or branches to another at a place other
than the normal entry point of the component. Again, this is impossible in most languages,
except assembler, Cobol and early versions of Basic.
The objection to this type of interaction is part of the argument for structured programming.
It is only by using components that have a single entry (at the start) and
one exit (at the end) that we can use the power of abstraction to design and understand
large programs.