$22.4 OTHER SOURCES OF CLASSES 735 architectural solutions in detail,providing precious guidance to others faced with similar problems in telecommunications,Computer-Aided Design,artificial intelligence and other application areas. [Gamma 1995]. The book on "design patterns"by Gamma et al.has started an effort of capturing proven design solutions and is now being followed by several others. Many useful design classes describe abstractions that are better understood as machines than as "objects"in the common (non-software)sense. As with implementation classes,reuse is preferable to invention.One can hope that many of the "patterns"currently being studied will soon cease to be mere ideas, yielding instead directly usable library classes. 22.4 OTHER SOURCES OF CLASSES A number of heuristics have proved useful in the quest for the right abstractions. Previous developments The advice of looking first at what is available does not just apply to library classes.As you write applications,you will accumulate classes which,if properly designed,should facilitate later developments. See“GENERALI Not all reusable software was born reusable.Often,the first version of a class is ZAT1ON”,28.5, produced to meet some immediate requirement rather than for posterity.If reusability is a page 928. concern,however,it pays to devote some time,after the development,to making the class more general and robust,improving its documentation,adding assertions.This is different from the construction of software meant from the start to be reusable,but no less fruitful. Having evolved from components of actual systems,the resulting classes have passed the first test of reusability,namely usability:they serve at least one useful purpose. Adaptation through inheritance When you discover the existence of a potentially useful class,you will sometimes find that it does not exactly suit your present need:some adaptation may be necessary. Unless the adaptation addresses a deficiency which should be corrected in the original as well,it is generally preferable to leave the class undisturbed,preserving its clients according to the Open-Closed principle.Instead,you may use inheritance and redefinition to tune the class to your new need. See“Variation This technique,which our later taxonomy of uses of inheritance will study in detail inheritance".page under the name variation inheritance,assumes that the new class describes a variant of the 828. same abstraction as the original.If used properly (according to the guidelines of the later discussion)it is one of the most remarkable contributions of the method,enabling you to resolve the reuse-redo dilemma:combining reusability with extendibility.§22.4 OTHER SOURCES OF CLASSES 735 architectural solutions in detail, providing precious guidance to others faced with similar problems in telecommunications, Computer-Aided Design, artificial intelligence and other application areas. • The book on “design patterns” by Gamma et al. has started an effort of capturing proven design solutions and is now being followed by several others. • Many useful design classes describe abstractions that are better understood as machines than as “objects” in the common (non-software) sense. • As with implementation classes, reuse is preferable to invention. One can hope that many of the “patterns” currently being studied will soon cease to be mere ideas, yielding instead directly usable library classes. 22.4 OTHER SOURCES OF CLASSES A number of heuristics have proved useful in the quest for the right abstractions. Previous developments The advice of looking first at what is available does not just apply to library classes. As you write applications, you will accumulate classes which, if properly designed, should facilitate later developments. Not all reusable software was born reusable. Often, the first version of a class is produced to meet some immediate requirement rather than for posterity. If reusability is a concern, however, it pays to devote some time, after the development, to making the class more general and robust, improving its documentation, adding assertions. This is different from the construction of software meant from the start to be reusable, but no less fruitful. Having evolved from components of actual systems, the resulting classes have passed the first test of reusability, namely usability: they serve at least one useful purpose. Adaptation through inheritance When you discover the existence of a potentially useful class, you will sometimes find that it does not exactly suit your present need: some adaptation may be necessary. Unless the adaptation addresses a deficiency which should be corrected in the original as well, it is generally preferable to leave the class undisturbed, preserving its clients according to the Open-Closed principle. Instead, you may use inheritance and redefinition to tune the class to your new need. This technique, which our later taxonomy of uses of inheritance will study in detail under the name variation inheritance, assumes that the new class describes a variant of the same abstraction as the original. If used properly (according to the guidelines of the later discussion) it is one of the most remarkable contributions of the method, enabling you to resolve the reuse-redo dilemma: combining reusability with extendibility. [Gamma 1995]. See “GENERALI￾ZATION”, 28.5, page 928. See “Variation inheritance”, page 828