向导就是类似于安装软件时，一大堆下一步的那个窗体。每一个上一步下一步意味着窗体上的控件需要改变，相关的按钮的功能等也需要改变。在制作一个向导时，最初设计中，我用的enum来表示每一个步骤。比如：
switch(stepEnum)
{
case StepEnum.FirstStep:
//some work
break;
case StepEnum.SecondStep:
//some work
break:
//...
default:
//...
}
{
case StepEnum.FirstStep:
//some work
break;
case StepEnum.SecondStep:
//some work
break:
//...
default:
//...
}
这样的设计，使得整个代码中充斥着大量的switch...case语句，并且使得每个步骤涉及到的控件布局，逻辑处理等代码混在一起。很是丑陋，无法忍受。于是我想用试着用state模式来除掉这些坏掉的味道。
State模式用[GOF]的话来说，使允许一个对象在其内部状态改变时改变它的行为。我定义一个抽象的步骤类来取代原有的枚举结构，各步骤继承与这个抽象类。其定义如下：
State模式用[GOF]的话来说，使允许一个对象在其内部状态改变时改变它的行为。我定义一个抽象的步骤类来取代原有的枚举结构，各步骤继承与这个抽象类。其定义如下：
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;}
}
{
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;}
}
通过这样的设计，将每一个步骤的逻辑判断和UI设计都封装在了StepState中。避免了在主窗口中使用枚举类来判断各个操作。简化了主窗口的代码，实现了相关的隔离，除掉了坏掉的味道。同时，利用单件模式，降低反复上一步，下一步付出的代价。基本达到了目的。
但是实践就是实践，没有经典问题那么的纯粹，有些问题很是折磨人。比如步骤转换的控制是由谁控制。步骤转换并不是一个简单的由1-->2-->3-->...的过程。而根据用户输入和选择的不同，可能存在1-->3-->...这样的路径，也可能有1-->2(1)-->3-->...这样的路径。设计中是将状态的转移控制封装在了InitWizardStepState类中（使用GoToNextStep和GoToPreStep来控制）。比如:在1步骤是获取需要转移和需要删除的文件列表，2步骤处理转移文件，3步骤处理删除文件。如果1步骤中，用户并没有输入转移文件，就可以跳过2直接进到3中。直接封装在步骤中可以使得这种处理可以在内部完成。但我越来越觉得这不是一个良好的决定。因为并不符合开闭原则。如果我需要建立一个新的向导，这个向导的次序和相关处理与老步骤不同。我如果还想使用原先的步骤类，我必须修改里面的逻辑，而并不是利用继承建立新的步骤即可。说明这个设计不够良好。
导致这个问题出现的原因,我想是因为在步骤转换是存在着数据的转移.比如在1步骤中获得了某个路径，在2步骤中需要获得这个路径,就将路径需要由步骤1传个步骤2。这其实就与state模式的应用范围产生了偏差。在state模式中，要求作为state的对象可以不依赖于其他对象而独立变化。所以我一直不确定我所谓的state是不是真正的state。
在下一步工作中，想继续改造上面的结构。即把各个步骤所需的（输入和输出的数据）放在一个类中，作为一个context存在。比如：以上面的转移文件和删除文件为例，建立context如下：
但是实践就是实践，没有经典问题那么的纯粹，有些问题很是折磨人。比如步骤转换的控制是由谁控制。步骤转换并不是一个简单的由1-->2-->3-->...的过程。而根据用户输入和选择的不同，可能存在1-->3-->...这样的路径，也可能有1-->2(1)-->3-->...这样的路径。设计中是将状态的转移控制封装在了InitWizardStepState类中（使用GoToNextStep和GoToPreStep来控制）。比如:在1步骤是获取需要转移和需要删除的文件列表，2步骤处理转移文件，3步骤处理删除文件。如果1步骤中，用户并没有输入转移文件，就可以跳过2直接进到3中。直接封装在步骤中可以使得这种处理可以在内部完成。但我越来越觉得这不是一个良好的决定。因为并不符合开闭原则。如果我需要建立一个新的向导，这个向导的次序和相关处理与老步骤不同。我如果还想使用原先的步骤类，我必须修改里面的逻辑，而并不是利用继承建立新的步骤即可。说明这个设计不够良好。
导致这个问题出现的原因,我想是因为在步骤转换是存在着数据的转移.比如在1步骤中获得了某个路径，在2步骤中需要获得这个路径,就将路径需要由步骤1传个步骤2。这其实就与state模式的应用范围产生了偏差。在state模式中，要求作为state的对象可以不依赖于其他对象而独立变化。所以我一直不确定我所谓的state是不是真正的state。
在下一步工作中，想继续改造上面的结构。即把各个步骤所需的（输入和输出的数据）放在一个类中，作为一个context存在。比如：以上面的转移文件和删除文件为例，建立context如下：
public class Context
{
public string[] deleteFileList;
public string[] moveFileList;
}
{
public string[] deleteFileList;
public string[] moveFileList;
}
然后将决定上下步骤的部分从StepState中提取出来。放在主窗口中完成。进一步降低了步骤类之间的耦合。同时增加各步骤类于Context之间的联系。比如：
将public abstract void AddControlToContainer(Control container);
改为public abstract void AddControlToContainer(Control container,Context context);
改为public abstract void AddControlToContainer(Control container,Context context);
这样可以更好的保持可扩展性和可重用性。
本文转自 duguguiyu 51CTO博客，原文链接：http://blog.51cto.com/duguguiyu/363383，如需转载请自行联系原作者
