1700473646
1700473647
super.context.setLiftState（Context.runningState）；
1700473648
1700473649
super.context.getLiftState（）.run（）；
1700473650
1700473651
}
1700473652
1700473653
//停止状态是怎么发生的呢？当然是停止方法执行了
1700473654
1700473655
@Override
1700473656
1700473657
public void stop（）{
1700473658
1700473659
System.out.println（“电梯停止了……”）；
1700473660
1700473661
}
1700473662
1700473663
}
1700473664
1700473665
业务逻辑都已经实现了，我们看看怎么来模拟场景类，如代码清单26-13所示。
1700473666
1700473667
代码清单26-13 场景类
1700473668
1700473669
public class Client{
1700473670
1700473671
public static void main（String[]args）{
1700473672
1700473673
Context context=new Context（）；
1700473674
1700473675
context.setLiftState（new ClosingState（））；
1700473676
1700473677
context.open（）；
1700473678
1700473679
context.close（）；
1700473680
1700473681
context.run（）；
1700473682
1700473683
context.stop（）；
1700473684
1700473685
}
1700473686
1700473687
}
1700473688
1700473689
Client场景类太简单了，只要定义一个电梯的初始状态，然后调用相关的方法，就完成了，完全不用考虑状态的变更，运行结果完全相同，不再赘述。
1700473690
1700473691
我们再来回顾一下我们刚刚批判的上一段代码。首先是代码太长，这个问题已经解决了，通过各个子类来实现，每个子类的代码都很短，而且也取消了switch……case条件的判断。其次是不符合开闭原则，那如果在我们这个例子中要增加两个状态应该怎么做呢？增加两个子类，一个是通电状态，一个是断电状态，同时修改其他实现类的相应方法，因为状态要过渡，那当然要修改原有的类，只是在原有类中的方法上增加，而不去做修改。再次是不符合迪米特法则，我们现在的各个状态是单独的类，只有与这个状态有关的因素修改了，这个类才修改，符合迪米特法则，非常完美！这就是状态模式。
1700473692
1700473693
1700473694
1700473695
[
上一页 ]
[ :1.700473646e+09 ]
[
下一页 ]