332 DESIGN BY CONTRACT:BUILDING RELIABLE SOFTWARE $11.1 Some important extensions to the basic ideas of Design by Contract will have to wait until the presentation of inheritance,polymorphism and dynamic binding,enabling us to go from contracts to subcontracting. 11.1 BASIC RELIABILITY MECHANISMS The preceding chapters already introduced a set of techniques that directly address the goal of producing reliable software.Let us review them briefly;it would be useless to consider more advanced concepts until we have put in place all the basic reliability mechanisms. First,the defining property of object technology is an almost obsessive concern with the structure of software systems.By defining simple,modular,extendible architectures, we make it easier to ensure reliability than with contorted structures as often result from earlier methods.In particular the effort to limit inter-module communication to the strict minimum was central to the discussion of modularity that got us started;it resulted in the prohibition of such common reliability risks as global variables,and in the definition of restricted communication mechanisms,the client and inheritance relations.The general observation is that the single biggest enemy ofreliability(and perhaps of software quality in general)is complexity.Keeping our structures as simple as possible is not enough to ensure reliability,but it is a necessary condition.So the discussion of the previous chapters provides the right starting point for the systematic effort of the present one. Also necessary if not sufficient is the constant emphasis on making our software elegant and readable.Software texts are not just written,they are read and rewritten many times;clarity and simplicity of notation,such as have been attempted in the language constructs introduced so far,are a required basis for any more sophisticated approach to reliability. Another indispensable weapon is automatic memory management,specifically garbage collection.The chapter on memory management explained in detail why,for any system that creates and manipulates dynamic data structures,it would be dangerous to rely on manual reclamation (or no reclamation).Garbage collection is not a luxury;it is a crucial reliability-enhancing component of any O-O environment. The same can be said of another technique presented (in connection with genericity) in the last chapter:static typing.Without statically enforced type rules,we would be at the mercy of run-time typing errors. All these techniques provide the necessary basis,from which we can now take a closer look at what it will take for a software system to be correct and robust.332 DESIGN BY CONTRACT: BUILDING RELIABLE SOFTWARE §11.1 Some important extensions to the basic ideas of Design by Contract will have to wait until the presentation of inheritance, polymorphism and dynamic binding, enabling us to go from contracts to subcontracting. 11.1 BASIC RELIABILITY MECHANISMS The preceding chapters already introduced a set of techniques that directly address the goal of producing reliable software. Let us review them briefly; it would be useless to consider more advanced concepts until we have put in place all the basic reliability mechanisms. First, the defining property of object technology is an almost obsessive concern with the structure of software systems. By defining simple, modular, extendible architectures, we make it easier to ensure reliability than with contorted structures as often result from earlier methods. In particular the effort to limit inter-module communication to the strict minimum was central to the discussion of modularity that got us started; it resulted in the prohibition of such common reliability risks as global variables, and in the definition of restricted communication mechanisms, the client and inheritance relations. The general observation is that the single biggest enemy of reliability (and perhaps of software quality in general) is complexity. Keeping our structures as simple as possible is not enough to ensure reliability, but it is a necessary condition. So the discussion of the previous chapters provides the right starting point for the systematic effort of the present one. Also necessary if not sufficient is the constant emphasis on making our software elegant and readable. Software texts are not just written, they are read and rewritten many times; clarity and simplicity of notation, such as have been attempted in the language constructs introduced so far, are a required basis for any more sophisticated approach to reliability. Another indispensable weapon is automatic memory management, specifically garbage collection. The chapter on memory management explained in detail why, for any system that creates and manipulates dynamic data structures, it would be dangerous to rely on manual reclamation (or no reclamation). Garbage collection is not a luxury; it is a crucial reliability-enhancing component of any O-O environment. The same can be said of another technique presented (in connection with genericity) in the last chapter: static typing. Without statically enforced type rules, we would be at the mercy of run-time typing errors. All these techniques provide the necessary basis, from which we can now take a closer look at what it will take for a software system to be correct and robust