Practice of creating a wizard in state mode...

The wizard is similar to the one that comes next when installing software. Each step in the previous step means that the controls on the form need to be changed, and the functions of related buttons also need to be changed. When creating a wizard, in the initial design, I used Enum to represent each step. For example:

Switch (stepenum)
{
Case stepenum. firststep:
// Some work
Break;
Case stepenum. secondstep:
// Some work
Break:
//...
Default:
//...
}

This design makes the entireCodeIt is filled with a large number of switch... case statements, and the layout of controls and logic processing code involved in each step are mixed together. It is ugly and intolerable. So I want to use the State mode to remove these bad smells.
The State mode uses [gof] to allow an object to change its behavior when its internal state changes. I define an Abstract Step class to replace the original enumeration structure. Each step inherits from this abstract class. It is defined as follows:

Public abstract class initwizardstepstate
{
Public abstract void addcontroltocontainer (control container );
Public abstract bool couldgotonext ();
Public abstract initwizardstepstate gotonextstep ();
Public abstract initwizardstepstate gotoprestep ();

Public abstract bool isfirststep {Get ;}
Public abstract bool islaststep {Get ;}
}

This design encapsulates the logical judgment and uidesign of each step in stepstate. This avoids the use of enumeration classes in the main window to Determine operations. The code of the main window is simplified, and related isolation is achieved, removing the bad taste. At the same time, the single-piece mode is used to reduce the price paid by repeating the previous step and the next step. Basically achieved the goal.
but the practice is practice. It is not so pure as a classic problem, and some problems are very painful. For example, who controls step conversion. Step conversion is not a simple process from 1 --> 2 --> 3 -->. Depending on the user input and selection, there may be 1 --> 3 -->... such a path may also have 1 --> 2 (1) --> 3 -->... such a path. In the design, status transfer control is encapsulated in the initwizardstepstate class (controlled using gotonextstep and gotoprestep ). For example, step 1 is to obtain the list of objects to be transferred and deleted, step 2 is to process the transferred files, and step 3 is to process the deleted files. If the transfer object is not input in step 1, skip step 2 and go directly to step 3. The process can be directly encapsulated in the step so that it can be completed internally. But I feel that this is not a good decision. Because it does not comply with the open and closed principles. If I need to create a new Wizard, the wizard order and related processing are different from the old step. If I want to use the original step class, I must modify the logic in it, instead of using inheritance to create a new step. This shows that the design is not good enough.
the cause of this problem is that there is data transfer in step conversion. for example, if a path is obtained in step 1 and the path needs to be obtained in step 2, the path needs to be transferred from step 1 to step 2. This actually deviates from the application scope of the State mode. In the state mode, objects that serve as state can be independent of other objects. So I have never been sure whether my so-called state is a real state.
In the next step, we want to continue to rebuild the above structure. That is, put the data (input and output data) required by each step in a class and exist as a context. For example, the following example shows how to create a transfer object and delete an object:

Public class context
{
Public String [] deletefilelist;
Public String [] movefilelist;
}

Then extract the upper and lower steps from the stepstate. In the main window. This further reduces the coupling between step classes. At the same time, the links between steps and context are added. For example:

Add public abstract void addcontroltocontainer (control container );
Change to public abstract void addcontroltocontainer (control container, context );

In this way, the scalability and reusability can be better maintained.