1700473873
1700473874
//定义环境角色
1700473875
1700473876
Context context=new Context（）；
1700473877
1700473878
//初始化状态
1700473879
1700473880
context.setCurrentState（new ConcreteState1（））；
1700473881
1700473882
//行为执行
1700473883
1700473884
context.handle1（）；
1700473885
1700473886
context.handle2（）；
1700473887
1700473888
}
1700473889
1700473890
}
1700473891
1700473892
看到没？我们已经隐藏了状态的变化过程，它的切换引起了行为的变化。对外来说，我们只看到行为的发生改变，而不用知道是状态变化引起的。
1700473893
1700473894
1700473895
1700473896
1700473898
设计模式之禅 26.3 状态模式的应用
1700473899
1700473900
26.3.1 状态模式的优点
1700473901
1700473902
❑结构清晰
1700473903
1700473904
避免了过多的switch……case或者if……else语句的使用，避免了程序的复杂性，提高系统的可维护性。
1700473905
1700473906
❑遵循设计原则
1700473907
1700473908
很好地体现了开闭原则和单一职责原则，每个状态都是一个子类，你要增加状态就要增加子类，你要修改状态，你只修改一个子类就可以了。
1700473909
1700473910
❑封装性非常好
1700473911
1700473912
这也是状态模式的基本要求，状态变换放置到类的内部来实现，外部的调用不用知道类内部如何实现状态和行为的变换。
1700473913
1700473914
1700473915
1700473916
1700473917
设计模式之禅 26.3.2 状态模式的缺点
1700473918
1700473919
状态模式既然有优点，那当然有缺点了。但只有一个缺点，子类会太多，也就是类膨胀。如果一个事物有很多个状态也不稀奇，如果完全使用状态模式就会有太多的子类，不好管理，这个需要大家在项目中自己衡量。其实有很多方式可以解决这个状态问题，如在数据库中建立一个状态表，然后根据状态执行相应的操作，这个也不复杂，看大家的习惯和嗜好了。
1700473920
1700473921
1700473922
[
上一页 ]
[ :1.700473873e+09 ]
[
下一页 ]