21 Inheritance case study: “undo”in an interactive system udesixmple weneed thatth desigers of amost any interactive system:how to provide a way to undo commands. The discussion will show how inheritance and dynamic binding yield a simple, regular and general solution to an apparently intricate and many-faceted problem;and it will teach us a few general lessons about the issues and principles of object-oriented design. 21.1 PERSEVERARE DIABOLICUM To err is human,it is said,but to foul things up for good takes a computer (aided,one should add,by humans).The faster and more powerful our interactive systems become, the easier it becomes to make them perform actions that we do not really want.This is why we all wish for a way to erase the recent past;not the "big red button"of computer jokes, but a Big Green Button that we can push to pretend that we did not do something that we did but wish we did not. Undoing for fun and profit In an interactive system,the equivalent of the Big Green Button is an Undo operation, which the system's designer has provided for the benefit of any user who,at some stage in a session,wants to cancel the effect of the last executed command. The primary aim of an undo mechanism is to allow users to recover from potentially damaging input mistakes.It is all too easy to type the wrong character or click on"OK" instead of"Cancel".But a good undo facility goes further.It frees users from having to concentrate nervously on every key they type and button they click.Beyond this,it encourages a "What if...?"style of interaction in which users try out various sorts of input,knowing that they can back up easily if the result is not what they expect. Every good interactive system should provide such a mechanism.When present,it tends to be one of the most frequently used operations.(For that reason,the makers ofthe computer on my desk have wisely provided an Undo key on the keyboard,although it is neither green nor particularly big.It is only effective,of course,for those regrettably few software applications whose authors took notice of it.)21 Inheritance case study: “undo” in an interactive system For our second design example we examine a need that confronts the designers of almost any interactive system: how to provide a way to undo commands. The discussion will show how inheritance and dynamic binding yield a simple, regular and general solution to an apparently intricate and many-faceted problem; and it will teach us a few general lessons about the issues and principles of object-oriented design. 21.1 PERSEVERARE DIABOLICUM To err is human, it is said, but to foul things up for good takes a computer (aided, one should add, by humans). The faster and more powerful our interactive systems become, the easier it becomes to make them perform actions that we do not really want. This is why we all wish for a way to erase the recent past; not the “big red button” of computer jokes, but a Big Green Button that we can push to pretend that we did not do something that we did but wish we did not. Undoing for fun and profit In an interactive system, the equivalent of the Big Green Button is an Undo operation, which the system’s designer has provided for the benefit of any user who, at some stage in a session, wants to cancel the effect of the last executed command. The primary aim of an undo mechanism is to allow users to recover from potentially damaging input mistakes. It is all too easy to type the wrong character or click on “OK” instead of “Cancel”. But a good undo facility goes further. It frees users from having to concentrate nervously on every key they type and button they click. Beyond this, it encourages a “What if… ?” style of interaction in which users try out various sorts of input, knowing that they can back up easily if the result is not what they expect. Every good interactive system should provide such a mechanism. When present, it tends to be one of the most frequently used operations. (For that reason, the makers of the computer on my desk have wisely provided an Undo key on the keyboard, although it is neither green nor particularly big. It is only effective, of course, for those regrettably few software applications whose authors took notice of it.)