Re: The Demand for Software Quality
Posted: Oct 28, 2003 2:32 PM
> The conclusion is: Chose your camp, camarade. Either
> her you have at your disposal a tool that imposes you
> constraints, but offers you some simplicity (like Eiffel
> or Java), or you may have a more complicated tool that
> offers more possibilities, at the price of an accrued need
> for thinking and mastering risks (like C++). I personnally
> prefer the later.
I guess that misses Meyers' point pretty well.
For example, from p. 3:
I think we build in software some of the most complex
artifacts that have ever been envisioned by humankind,
and in some cases they just overwhelm us. The only way
we can build really big and satisfactory systems is to
put a hold on complexity, to maintain a grasp on
Basically, Meyers' is claiming that the choice isn't there anymore. If we choose a tool that "offers more possibilities, at the price of an accrued need for thinking and mastering risks" then - despite our best intentions, skill, and "mastery" - we will produce systems with defects.
The point behind information hiding, DBC, component design, "published/publisized" interfaces, dependency inversion, dependency management, and other techniques is to allow the power of "divide and conquor" to be brought to bear on a large problem. If we design systems where every class/component depends on the *implementation* of an unbounded number of other classes or components, then no mater how much we divide, we can never conquor. For example, allow one circular dependency into a C++ system and watch the build-time go through the roof for almost any small change.
Once we start designing our systems with an eye to controling interactions and dependencies, we can start to reduce the complexity of each individual "component" to the point that it can be understood (and tested) in isolation. Then, the complexity of the larger system is limited to the intrinsic complexity of the interactions between components.
If the number of components is "m" and the number of interactions is "n", then the complexity of the fully-coupled system is m*n; the complexity of the fully decoupled system is m+n. For "m" and "n" that are greater than 2, the difference is dramatic; when "n" and "m" both get into the thousands, the difference is between managable and "overwhelming".
In those situations, the choice of a "tool that imposes [some] constraints" isn't a deficieny, it's a aide. Those "constraints" are eactly the language features that the developer uses to express the independence and inter-dependence of the components in the system.