72 APPROACHES TO REUSABILITY $4.2 benefit from the experience of their elders and peers.How can the general idea contribute to reuse?Design patterns should not encourage a throwback to the "all that counts is design reuse"attitude mentioned earlier.A pattern that is only a book pattern,however elegant and general,is a pedagogical tool,not a reuse tool;after all,computing science students have for three decades been learning from their textbooks about relational query optim ization,Gouraud shading,AVL trees,Hoare's Quicksort and Dijkstra's shortest path algorithm without anyone claiming that these techniques were breakthroughs in reusability.In a sense,the patterns developed in the past few years are only incremental additions to the software professional's bag of standard tricks.In this view the new contribution is the patterns themselves,not the idea of pattern. As most people who have looked carefully at the pattern work have recognized,such See“Programs a view is too limited.There seems to be in the very notion of pattern a truly new with holes'”,page contribution,even if it has not been fully understood yet.To go beyond their mere 506. pedagogical value,patterns must go further.A successful pattern cannot just be a book description:it must be a software component,or a set of components.This goal may seem remote at first because many of the patterns are so general and abstract as to seem impossible to capture in actual software modules;but here the object-oriented method provides a radical contribution.Unlike earlier approaches,it will enable us to build reusable modules that still have replaceable,not completely frozen elements:modules that serve as general schemes (patterns is indeed the appropriate word)and can be adapted to various specific situations.This is the notion of behavior class (a more picturesque term is programs with holes);it is based on O-O techniques that we will study in later chapters, in particular the notion of deferred class.Combine this with the idea of groups of components intended to work together-often known as frameworks or more simply as libraries-and you get a remarkable way of reconciling reusability with adaptability. These techniques hold,for the pattern movement,the promise of exerting,beyond the new-bag-of-important-tricks effect,an in-depth influence on reusability practices. Reusability through the source code Personnel,design and specification forms of reuse,useful as they may be,ignore a key goal of reusability.If we are to come up with the software equivalent of the reusable parts of older engineering disciplines,what we need to reuse is the actual stuff of which our products are made:executable software.None of the targets ofreuse seen so far-people, designs,specifications-can qualify as the off-the-shelf components ready to be included in a new software product under development. If what we need to reuse is software,in what form should we reuse it?The most natural answer is to use the software in its original form:source text.This approach has worked very well in some cases.Much of the Unix culture,for example,originally spread in universities and laboratories thanks to the on-line availability of the source code, enabling users to study,imitate and extend the system.This is also true of the Lisp world. See also“Formats The economic and psychological impediments to source code dissemination limit for reusable compo- the effect that this form ofreuse can have in more traditional industrial environments.But ent distribution"”, a more serious limitation comes from two technical obstacles: page 79 below.72 APPROACHES TO REUSABILITY §4.2 benefit from the experience of their elders and peers. How can the general idea contribute to reuse? Design patterns should not encourage a throwback to the “all that counts is design reuse” attitude mentioned earlier. A pattern that is only a book pattern, however elegant and general, is a pedagogical tool, not a reuse tool; after all, computing science students have for three decades been learning from their textbooks about relational query optimization, Gouraud shading, AVL trees, Hoare’s Quicksort and Dijkstra’s shortest path algorithm without anyone claiming that these techniques were breakthroughs in reusability. In a sense, the patterns developed in the past few years are only incremental additions to the software professional’s bag of standard tricks. In this view the new contribution is the patterns themselves, not the idea of pattern. As most people who have looked carefully at the pattern work have recognized, such a view is too limited. There seems to be in the very notion of pattern a truly new contribution, even if it has not been fully understood yet. To go beyond their mere pedagogical value, patterns must go further. A successful pattern cannot just be a book description: it must be a software component, or a set of components. This goal may seem remote at first because many of the patterns are so general and abstract as to seem impossible to capture in actual software modules; but here the object-oriented method provides a radical contribution. Unlike earlier approaches, it will enable us to build reusable modules that still have replaceable, not completely frozen elements: modules that serve as general schemes (patterns is indeed the appropriate word) and can be adapted to various specific situations. This is the notion of behavior class (a more picturesque term is programs with holes); it is based on O-O techniques that we will study in later chapters, in particular the notion of deferred class. Combine this with the idea of groups of components intended to work together — often known as frameworks or more simply as libraries — and you get a remarkable way of reconciling reusability with adaptability. These techniques hold, for the pattern movement, the promise of exerting, beyond the new-bag-of-important-tricks effect, an in-depth influence on reusability practices. Reusability through the source code Personnel, design and specification forms of reuse, useful as they may be, ignore a key goal of reusability. If we are to come up with the software equivalent of the reusable parts of older engineering disciplines, what we need to reuse is the actual stuff of which our products are made: executable software. None of the targets of reuse seen so far — people, designs, specifications — can qualify as the off-the-shelf components ready to be included in a new software product under development. If what we need to reuse is software, in what form should we reuse it? The most natural answer is to use the software in its original form: source text. This approach has worked very well in some cases. Much of the Unix culture, for example, originally spread in universities and laboratories thanks to the on-line availability of the source code, enabling users to study, imitate and extend the system. This is also true of the Lisp world. The economic and psychological impediments to source code dissemination limit the effect that this form of reuse can have in more traditional industrial environments. But a more serious limitation comes from two technical obstacles: See “Programs with holes”, page 506. See also “Formats for reusable compo￾nent distribution”, page 79 below