$4.2 WHAT SHOULD WE REUSE? 71 This approach is essentially a more organized version of the previous one-reuse of know-how and experience.As the discussion of documentation has already suggested, the very notion of a design as an independent software product,having its own life separate from that of the corresponding implementation,seems dubious,since it is hard to guarantee that the design and the implementation will remain compatible throughout the evolution of a software system.So ifyou only reuse the design you run the risk of reusing incorrect or obsolete elements. These comments are also applicable to a related form ofreuse:reuse ofspecifications To a certain extent,one can view the progress of reusability in recent years,aided by progress in the spread of object technology and aiding it in return,as resulting in part from the downfall of the old idea,long popular in software engineering circles,that the only reuse worthy of interest is reuse of design and specification.A narrow form of that idea was the most effective obstacle to progress,since it meant that all attempts to build actual components could be dismissed as only addressing trivial needs and not touching the truly difficult aspects.It used to be the dominant view;then a combination of theoretical arguments (the arguments of object technology)and practical achievements (the appearance of successful reusable components)essentially managed to defeat it. "Defeat"is perhaps too strong a term because,as often happens in such disputes,the result takes a little from both sides.The idea of reusing designs becomes much more interesting with an approach (such as the view of object technology developed in this book)which removes much of the gap between design and implementation.Then the difference between a module and a design for a module is one of degree,not of nature:a module design is simply a module of which some parts are not fully implemented;and a fully implemented module can also serve,thanks to abstraction tools,as a module design. With this approach the distinction between reusing modules(as discussed below)and reusing designs tends to fade away. Design patterns In the mid-nineteen-nineties the idea of design patterns started to attract considerable attention in object-oriented circles.Design patterns are architectural ideas applicable across a broad range of application domains;each pattern makes it possible to build a solution to a certain design issue. Chapter 21 discuss- Here is a typical example,discussed in detail in a later chapter.The issue:how to es the undoing pat- provide an interactive system with a mechanism enabling its users to undo a previously tern. executed command if they decide it was not appropriate,and to reexecute an undone command if they change their mind again.The pattern:use a class COMMAND with a precise structure(which we will study)and an associated"history list".We will encounter many other design patterns. [Gamma 1995];see One of the reasons for the success of the design pattern idea is that it was more than also [Pree 1994]. an idea:the book that introduced the concept,and others that have followed,came with a catalog of directly applicable pattems which readers could learn and apply Design patterns have already made an important contribution to the development of object technology,and as new ones continue to be published they will help developers to§4.2 WHAT SHOULD WE REUSE? 71 This approach is essentially a more organized version of the previous one — reuse of know-how and experience. As the discussion of documentation has already suggested, the very notion of a design as an independent software product, having its own life separate from that of the corresponding implementation, seems dubious, since it is hard to guarantee that the design and the implementation will remain compatible throughout the evolution of a software system. So if you only reuse the design you run the risk of reusing incorrect or obsolete elements. These comments are also applicable to a related form of reuse: reuse of specifications. To a certain extent, one can view the progress of reusability in recent years, aided by progress in the spread of object technology and aiding it in return, as resulting in part from the downfall of the old idea, long popular in software engineering circles, that the only reuse worthy of interest is reuse of design and specification. A narrow form of that idea was the most effective obstacle to progress, since it meant that all attempts to build actual components could be dismissed as only addressing trivial needs and not touching the truly difficult aspects. It used to be the dominant view; then a combination of theoretical arguments (the arguments of object technology) and practical achievements (the appearance of successful reusable components) essentially managed to defeat it. “Defeat” is perhaps too strong a term because, as often happens in such disputes, the result takes a little from both sides. The idea of reusing designs becomes much more interesting with an approach (such as the view of object technology developed in this book) which removes much of the gap between design and implementation. Then the difference between a module and a design for a module is one of degree, not of nature: a module design is simply a module of which some parts are not fully implemented; and a fully implemented module can also serve, thanks to abstraction tools, as a module design. With this approach the distinction between reusing modules (as discussed below) and reusing designs tends to fade away. Design patterns In the mid-nineteen-nineties the idea of design patterns started to attract considerable attention in object-oriented circles. Design patterns are architectural ideas applicable across a broad range of application domains; each pattern makes it possible to build a solution to a certain design issue. Here is a typical example, discussed in detail in a later chapter. The issue: how to provide an interactive system with a mechanism enabling its users to undo a previously executed command if they decide it was not appropriate, and to reexecute an undone command if they change their mind again. The pattern: use a class COMMAND with a precise structure (which we will study) and an associated “history list”. We will encounter many other design patterns. One of the reasons for the success of the design pattern idea is that it was more than an idea: the book that introduced the concept, and others that have followed, came with a catalog of directly applicable patterns which readers could learn and apply. Design patterns have already made an important contribution to the development of object technology, and as new ones continue to be published they will help developers to Chapter 21 discuss￾es the undoing pat￾tern. [Gamma 1995]; see also [Pree 1994]