930 THE SOFTWARE CONSTRUCTION PROCESS $28.6 The first part implies applying reusability concems throughout development.The second implies not taking the result for granted,but performing a generalization step to remove any traces of context-specific elements. The generalization task may involve the following activities: Abstracting:introducing a deferred class to describe the pure abstraction behind a On abstracting and certain class. factoring see“Variet-- ies of class abstrac- Factoring:recognizing that two classes,originally unrelated,are in fact variants of tiom”,page860. the same general notion,which can then be described by a common ancestor. Adding assertions,especially postconditions and invariant clauses which reflect increased understanding of the semantics of the class and its features.(You may also have to add a precondition,but this is more akin to correcting a bug,since it means the routine was not properly protected.) Adding rescue clauses to handle exceptions whose possibility may initially have been ignored. Adding documentation. The first two of these activities,studied in the discussion of inheritance methodology,reflect the non-standard view of inheritance hierarchy construction that we explored then:the recognition that,although it would be nice always to go from the general to the specific and the abstract to the concrete,the actual path to invention is often more tortuous,and sometimes just the other way around. The role of generalization is to improve classes that may be considered good enough for internal purposes-as long,that is,as they are only used within a particular system- but not any more when they become part of a library available to any client author who cares to use them for his own needs.Peccadillos that may have been forgivable in the first setting,such as insufficient specification or reliance on undocumented assumptions, become show-stoppers.This is why developing for reusability is more difficult than ordinary application development:when your software is available to anyone,working on applications of any kind for any platform anywhere in the world,everything starts to matter.Reusability breeds perfectionism;you cannot leave good enough alone. 28.6 SEAMLESSNESS AND REVERSIBILITY The"stalactite"nature of the cluster lifecycle reflects one of the most radical differences between O-O development and earlier approaches.Instead of erecting barriers between successive lifecycle steps,well-understood object technology defines a single framework for analysis,design,implementation and maintenance.This is known as seamless development; one of its consequences,previewed in the last chapter's discussion of the Business Object Notation,is the need for a reversible software development process.930 THE SOFTWARE CONSTRUCTION PROCESS §28.6 The first part implies applying reusability concerns throughout development. The second implies not taking the result for granted, but performing a generalization step to remove any traces of context-specific elements. The generalization task may involve the following activities: • Abstracting: introducing a deferred class to describe the pure abstraction behind a certain class. • Factoring: recognizing that two classes, originally unrelated, are in fact variants of the same general notion, which can then be described by a common ancestor. • Adding assertions, especially postconditions and invariant clauses which reflect increased understanding of the semantics of the class and its features. (You may also have to add a precondition, but this is more akin to correcting a bug, since it means the routine was not properly protected.) • Adding rescue clauses to handle exceptions whose possibility may initially have been ignored. • Adding documentation. The first two of these activities, studied in the discussion of inheritance methodology, reflect the non-standard view of inheritance hierarchy construction that we explored then: the recognition that, although it would be nice always to go from the general to the specific and the abstract to the concrete, the actual path to invention is often more tortuous, and sometimes just the other way around. The role of generalization is to improve classes that may be considered good enough for internal purposes — as long, that is, as they are only used within a particular system — but not any more when they become part of a library available to any client author who cares to use them for his own needs. Peccadillos that may have been forgivable in the first setting, such as insufficient specification or reliance on undocumented assumptions, become show-stoppers. This is why developing for reusability is more difficult than ordinary application development: when your software is available to anyone, working on applications of any kind for any platform anywhere in the world, everything starts to matter. Reusability breeds perfectionism; you cannot leave good enough alone. 28.6 SEAMLESSNESS AND REVERSIBILITY The “stalactite” nature of the cluster lifecycle reflects one of the most radical differences between O-O development and earlier approaches. Instead of erecting barriers between successive lifecycle steps, well-understood object technology defines a single framework for analysis, design, implementation and maintenance. This is known as seamless development; one of its consequences, previewed in the last chapter’s discussion of the Business Object Notation, is the need for a reversible software development process. On abstracting and factoring see “Variet￾ies of class abstrac￾tion”, page 860