704 INHERITANCE CASE STUDY:"UNDO"IN AN INTERACTIVE SYSTEM $21.3 inspect request code when Line insertion then !LINE INSERTION requested.make (input_text,cursor_position) etc Both forms are multiple-branch choices,but they do not violate the Single Choice “Single Choice", principle:as was pointed out in the discussion of that principle,if a system provides a page 61. number ofalternatives some part ofit must know the complete list of alternatives.The above extract,in either variant,is that point of single choice.What the principle precludes is spreading out such knowledge over many modules.Here,no other part of the system needs access to the list of commands;every command class deals with just one kind of command. It is in fact possible to obtain a more elegant structure and get rid of the multi-branch “Precomputing choice totally;we will see this at the end of presentation. command objects”, page 708. 21.3 MULTI-LEVEL UNDO-REDO Supporting an arbitrary depth of undoing,with the attendant redoing,is a straightforward extension of the preceding scheme. The history list What has constrained us to a single level of undoing was the use of just one object,the last created instance of COMMAND available through requested,as the only record of previously executed commands. In fact we create as many objects as the user executes commands.But because the See chapter 9 on software only has one command object reference,requested,al ways attached to the last garbage collection command,every command object becomes unreachable as soon as the user executes a new command.It is part of the elegance and simplicity of a good O-O environment that we do not need to worry about such older command objects:the garbage collector will take care of reclaiming the memory they occupy.It would be a mistake to try to reclaim the command objects ourselves,since they may all be of different shapes and sizes. To provide more depth of undoing we need to replace the single command requested by a list of recently executed commands,the history list: history:SOME LIST [COMMAND] SOME LIST is not a real class name;in true object-oriented,abstract data type style we will examine what features and properties we need from SOME LIST and draw the conclusion as to what list class (from the Base library)we can use.The principal operations we need are straightforward and well known from previous discussions: put to insert an element at the end (the only place where we will need insertions).By convention,put will position the list cursor on the element just inserted. empty to find out whether the list is empty.704 INHERITANCE CASE STUDY: “UNDO” IN AN INTERACTIVE SYSTEM §21.3 inspect request_code when Line_insertion then ! LINE_INSERTION ! requested ● make (input_text, cursor_ position) etc. Both forms are multiple-branch choices, but they do not violate the Single Choice principle: as was pointed out in the discussion of that principle, if a system provides a number of alternatives some part of it must know the complete list of alternatives. The above extract, in either variant, is that point of single choice. What the principle precludes is spreading out such knowledge over many modules. Here, no other part of the system needs access to the list of commands; every command class deals with just one kind of command. It is in fact possible to obtain a more elegant structure and get rid of the multi-branch choice totally; we will see this at the end of presentation. 21.3 MULTI-LEVEL UNDO-REDO Supporting an arbitrary depth of undoing, with the attendant redoing, is a straightforward extension of the preceding scheme. The history list What has constrained us to a single level of undoing was the use of just one object, the last created instance of COMMAND available through requested, as the only record of previously executed commands. In fact we create as many objects as the user executes commands. But because the software only has one command object reference, requested, always attached to the last command, every command object becomes unreachable as soon as the user executes a new command. It is part of the elegance and simplicity of a good O-O environment that we do not need to worry about such older command objects: the garbage collector will take care of reclaiming the memory they occupy. It would be a mistake to try to reclaim the command objects ourselves, since they may all be of different shapes and sizes. To provide more depth of undoing we need to replace the single command requested by a list of recently executed commands, the history list: history: SOME_LIST [COMMAND] SOME_LIST is not a real class name; in true object-oriented, abstract data type style we will examine what features and properties we need from SOME_LIST and draw the conclusion as to what list class (from the Base library) we can use. The principal operations we need are straightforward and well known from previous discussions: • put to insert an element at the end (the only place where we will need insertions). By convention, put will position the list cursor on the element just inserted. • empty to find out whether the list is empty. “Single Choice”, page 61. “Precomputing command objects”, page 708. See chapter 9 on garbage collection