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
1700473923
1700473924
设计模式之禅 26.3.3 状态模式的使用场景
1700473925
1700473926
❑行为随状态改变而改变的场景
1700473927
1700473928
这也是状态模式的根本出发点，例如权限设计，人员的状态不同即使执行相同的行为结果也会不同，在这种情况下需要考虑使用状态模式。
1700473929
1700473930
❑条件、分支判断语句的替代者
1700473931
1700473932
在程序中大量使用switch语句或者if判断语句会导致程序结构不清晰，逻辑混乱，使用状态模式可以很好地避免这一问题，它通过扩展子类实现了条件的判断处理。
1700473933
1700473934
1700473935
1700473936
1700473937
设计模式之禅 26.3.4 状态模式的注意事项
1700473938
1700473939
状态模式适用于当某个对象在它的状态发生改变时，它的行为也随着发生比较大的变化，也就是说在行为受状态约束的情况下可以使用状态模式，而且使用时对象的状态最好不要超过5个。
1700473940
1700473941
1700473942
1700473943
1700473945
设计模式之禅 26.4 最佳实践
1700473946
[
上一页 ]
[ :1.700473897e+09 ]
[
下一页 ]