686 DESIGN CASE STUDY:MULTI-PANEL INTERACTIVE SYSTEMS $20.5 Features input and choice are attributes;the others are routines.Compared to their counterparts in the functional decomposition,the routines have lost their explicit state arguments,although the state will reappear in calls made by clients,such as s.execute. In the previous approach,execute (formerly execute state)returned the user's See "SIDE choice for the next step.But such a style violates principles of good design.It is preferable EFFECTS IN to treat execute as a command,whose execution determines the result of the query"what FUNCTIONS" choice did the user make in the last state?",available through the attribute choice. 23.L,page748. Similarly,the ANSWER argument to the level 1 routines is now replaced by the secret attribute input.The reason is information hiding:client code does not need to look at answers except through the interface provided by the exported features. Inheritance and deferred classes Class STATE does not describe a particular state,but the general notion of state.Procedure execute is the same for all states,but the other routines are state-specific. Inheritance and deferred classes ideally address such situations.At the STATE level, we know the procedure execute in full detail and the attributes.We also know the existence of the level I routines (display etc.)and their specifications,but not their implementations.These routines should be deferred;class STATE,which describes a set of variants,rather than a fully spelled out abstraction,is itself a deferred class.This gives: indexing description:"States for interactive panel-driven applications" deferred class STATE feature--Access choice:INTEGER --User's choice for next step input:ANSWER --User's answer to questions asked in this state. feature--Status report correct:BOOLEAN is -Is input a correct answer? deferred end feature--Basic operations display is --Display panel associated with current state. deferred end686 DESIGN CASE STUDY: MULTI-PANEL INTERACTIVE SYSTEMS §20.5 Features input and choice are attributes; the others are routines. Compared to their counterparts in the functional decomposition, the routines have lost their explicit state arguments, although the state will reappear in calls made by clients, such as s ● execute. In the previous approach, execute (formerly execute_state) returned the user’s choice for the next step. But such a style violates principles of good design. It is preferable to treat execute as a command, whose execution determines the result of the query “what choice did the user make in the last state?”, available through the attribute choice. Similarly, the ANSWER argument to the level 1 routines is now replaced by the secret attribute input. The reason is information hiding: client code does not need to look at answers except through the interface provided by the exported features. Inheritance and deferred classes Class STATE does not describe a particular state, but the general notion of state. Procedure execute is the same for all states, but the other routines are state-specific. Inheritance and deferred classes ideally address such situations. At the STATE level, we know the procedure execute in full detail and the attributes. We also know the existence of the level 1 routines (display etc.) and their specifications, but not their implementations. These routines should be deferred; class STATE, which describes a set of variants, rather than a fully spelled out abstraction, is itself a deferred class. This gives: indexing description: "States for interactive panel-driven applications" deferred class STATE feature -- Access choice: INTEGER -- User’s choice for next step input: ANSWER -- User’s answer to questions asked in this state. feature -- Status report correct: BOOLEAN is -- Is input a correct answer? deferred end feature -- Basic operations display is -- Display panel associated with current state. deferred end See “SIDE EFFECTS IN FUNCTIONS”, 23.1, page 748