倚楼听风雨
淡看江湖路

浅析设计模式第十六章之状态模式

这个状态模式之前老四没接触过,甚至不知道这个名字,参考了一些资料尝试着写一写。就像策略模式,状态模式其实也属于行为模式,关于策略模式您可以参考老四写的这篇《浅析设计模式第二章之策略模式》。

我们都知道在我们经常碰到的业务场景中,经常会碰到一个对象会有多种状态,每种状态可能还要对应不同的对象行为,你的数据库设计经常也会要设计某个字段为状态字段,用来判断或者临界某种业务场景。比如说游戏角色的升级涉及到各种装备的进账等等,再比如说订单有待支付、待处理、已发货、收货完成等。其中待支付状态不能进行发货处理,待处理用户不能确认收货等等,每种状态是对应对象的不同的行为的。这些都涉及到状态模式,就当前这个例子来讲,如果我们设计一个超级订单类,那么这里面会存在很多的中订单状态判断的if-else if-else语句,我们都知道大量的条件判断有很多缺点:

  1. 判断条件下的方法实现不尽相同导致代码冗长,可维护性极差
  2. 代码测试难度较大,针对每种对象状态的测试都不利于维护
  3. 扩展性几乎没有,新增一种状态或者修改某种对象状态,不仅要修改条件代码,还要改变对应的对象行为方法,非常麻烦。

我们都知道方法过长是坏味道,面向对象设计其实就是希望做到代码的责任分解,符合单一职责原则,关于单一职责原则您可以参考老四的这篇文章《浅析设计模式第三章之单一职责原则》,那么这个时候可能就需要状态模式来帮忙解决这个问题,让我们一点点来了解状态模式是如何解决对象多状态多行为的问题的,他还能扩展性的解决什么问题?

定义

状态模式(State): 当一个对象的内在状态改变时允许改变其行为,这个对象看起来像是改变了其类。其别名为状态对象(Objects for States)。

听/看起来还是有点懵逼,其实状态模式解决的就是当控制一个对象状态转换的条件表达式过于复杂时的情况。把状态的判断逻辑转移到表示不同状态的一些列具体的类当中,把判断逻辑简单化处理。

还是敲代码清晰一些,这里我们使用银行账户的例子: 一个用户的银行卡账户分为正常、透支、受限三种状态,正常状态可以正常存取人民币,透支状态在一定额度之内可以正常存取人民币但是要支付利息,受限状态就是只能存钱不能取钱了,并且还要付利息。所以在这个例子中,用户银行卡里面的余额决定着该用户的账户状态,三种状态是随时可能变换的,对应用户的功能也会有对应的限制,我们首先设计一个超级银行账户类,看看不使用状态模式下的类设计是什么样的。

以上代码基本都实现了老四前面写的条件判断的三条缺点,所以我们接下来根据状态模式的定义,来改写上述代码。根据三种不同的账户状态设计三个具体的状态类,分别为账户正常状态类、透支状态类以及受限状态类,他们都实现了银行账户的抽象状态接口供环境类调用。所以,其实再设计角度上来讲状态模式与策略模式差不多,都包含如下几个角色:

  • Context(环境类): 环境类又称为上下文类,它是拥有多种状态的对象。由于环境类的状态存在多样性且在不同状态下对象的行为有所不同,因此将状态独立出去形成单独的状态类。在环境类中维护一个抽象状态类State的实例,这个实例定义当前状态,在具体实现时,它是一个State子类的对象。
  • State(抽象状态类): 它用于定义一个接口以封装与环境类的一个特定状态相关的行为,在抽象状态类中声明了各种不同状态对应的方法,而在其子类中实现类这些方法,由于不同状态下对象的行为可能不同,因此在不同子类中方法的实现可能存在不同,相同的方法可以写在抽象状态类中。
  • ConcreteState(具体状态类): 它是抽象状态类的子类,每一个子类实现一个与环境类的一个状态相关的行为,每一个具体状态类对应环境的一个具体状态,不同的具体状态类其行为有所不同。

但有所不同的是,状态模式中对象的状态是互相转换的,所以负责的状态转换的处理你既可以放到环境类中来处理,也可以放入到具体的状态类来处理,但是我推荐放到环境类当中,至于原因,接下来我们用状态模式实现上述代码的改造就清晰了。

以上老四具体的状态实现类只列举了正常状态实现类,项目所有源码请文末自助获取下载。

如你所见,我们在环境类当中免除了一系列复杂的状态条件判断,银行账户类只专注于存取款的操作,每种状态相当于后台监控,遇到操作权限不足的时候会自动提示给用户。所以对于这种多种状态互相转换的情况,状态模式再适合不过了,接下来我们继续举一反三,状态模式可以扩展性支持多种情况,比如下面这种情形:

如代码所见,我们的需求是开关类共享同一个状态(开关的开或者关),不同于银行的例子,所以我们要在开关类中定义静态的开关状态实现开关状态的共享,从而实现两个开关的状态共享,同时打开或者关闭,这种情况(多个环境对象可能需要共享同一个状态)依然试用与状态模式来解决。

但是上面咱们所写的状态模式代码还存在什么问题呢?是不是每个具体状态类中都有一个状态转换的代码?如果在加一种状态的话,是不是每个状态转换的代码都需要修改?显然不符合开放封闭原则,关于开放封闭原则您可以参考老四的这篇文章《浅析设计模式第四章之开放-封闭原则》,所以在银行例子当中,我们需要将stateCheck方法也要抽象出来就完美了。就是老四之前提及到的,将状态检查方法提取出来放入到环境类当中,这样就可以了,代码就不演示了。

状态模式的优点总结:

  1. 将与特定状态相关的行为局部化,并且将不同状态的行为分割开来,消除庞大的条件分支语句。这样我们通过将特定的状态相关的行为都放入一个对象中,由于所有与状态相关的代码都存在于具体状态实现类当中,所以通过定义新的子类就可以很容易地增加新的状态和对象行为转换。
  2. 状态的集中管理,封装状态的转换规则,这样我们只需要注入不同状态的状态对象到环境类当中就能实现对象的不同行为。
  3. 状态共享。减少系统对象。

缺点总结:

  1. 有多少种状态就有多少个具体的状态类,系统开销大了
  2. 状态对象与环境类对象构造混杂,复杂点状态对象行为会导致代码结构混乱。
  3. 状态模式并不是完善的满足开放-封闭原则,无论是新增/修改状态都需要修改对应类的源码,不过总比错综复杂的条件分支语法强太多。

项目完整源码文末自助获取下载。注册之后即可下载,不要钱的,一个注册只是提高一下学习的门槛,老四没那么势力!!

更博不易,喜欢的老铁有能力烦请赞助盒烟钱,点我去赞助。抱拳。

资源下载

隐藏内容:******,购买后可见!

下载价格:0 G币

您需要先后,才能购买资源

欢迎访问高老四博客(glorze.com),本站技术文章代码均为老四亲自编写或者借鉴整合,其余资源多为网络收集,如涉及版权问题请与站长联系。如非特殊说明,本站所有资源解压密码均为:glorze.com。

赞(14) 给你买杜蕾斯
本站原创文章受自媒体平台原创保护,未经允许不得转载高老四博客 » 浅析设计模式第十六章之状态模式

开始你的表演 抢沙发

觉得文章有用就打赏一下老四,鼓励我更好的创作

非常感谢你的打赏,我们将继续给力更多优质内容,让我们一起创建更加美好的网络世界!

支付宝扫一扫打赏

微信扫一扫打赏

登录

找回密码

注册