|
|
Re: Coupling is not neccessarily a bad thing!
|
Posted: May 5, 2005 8:49 PM
|
|
> You provided a good definition of "data coupling" as a
> form of dependency between sections of code through
> variables. "Control coupling" was defined as a form of
> dependency between sections of code through parameters
> representing behaviour. What could "coupling" by itself
> possibly be, if it isn't the broad notion of dependency
> between modular sections of software?
The concept of coupling (along with the concepts of modules, module strength, and cohesion) were introduced in the modular/structured programming literature in the mid-1970s. Glenford Myers' books were influential at the time, because he offered good definitions of different types of coupling (common, data, stamp, control, etc.) and module strength. Myers also described ways to remove unnecessary coupling. Yourdon taught much the same thing, and used the term "coupling" to mean the same thing as Myers. Steve McConnell dusted those old books off and introduced the ideas to a new generation of programmers, using a more modern langauge (more modern than Fortran and PL/I, anyway) for examples.
I've always understood coupling to be one type of dependency, specifically dependency caused by data shared by or passed between modules. Object-oriented and other modern programming techniques offer new ways to couple modules, and also introduce new types of dependencies that Myers and Yourdon did not contemplate. Metaprogramming introduces opportunties for type dependencies -- type coupling, if you prefer -- that 1970s-era langauges did not support.
I'm willing to accept that modern programming languages have outgrown Myers' definition of coupling, and perhaps I'm making distinctions between data and types and relationships among chunks of code that are a lot blurrier today than they were in the 1970s.
Still, I find it useful to use the term "coupling" to refer to the kind of dependency Myers described, and to use other terms for other kinds of dependencies: inheritance, composition, fragile base class, common type definitions, etc.
When Myers named and described the kinds of coupling, and ranked them from bad to better, he didn't say that all coupling is bad. He did say that modules should not be coupled any more than necessary (i.e. don't use globals or common variables), and that some kinds of coupling are worse than others. His principles are mostly still applicable today, but obviously he didn't address all of the trouble C++ can get someone into.
When I read the original example, I didn't see a coupling problem; I saw the fragile base class problem. I didn't mean to get into a debate about the meaning of "coupling."
|
|
Previous Topic
