我在另一篇博客里声称:做技术的思路是优先“怎么用”、而后再“是什么”。然而这里,我却想讨论一下状态模式与策略模式“是什么”,以及它们之间的区别。
这并不是打脸,而是我在经过长久的思考“怎么用”之后,终于明白了它们“是什么”。
状态机
让我想明白的契机,是“如何实现状态机(当然,是有限确定状态机)”这样一个问题。下图是一个简单的状态机:
策略与状态
我原本计划用这样一套类来实现这个状态机:
画好类图之后我发现,这是个典型的策略模式。但是从直觉上来看,状态模式才是状态机的天然盟友。因此我又尝试着画了一套状态模式的图:
对比
一眼看上起,这两张类图一模一样。当然,仔细看看,一定能发现其中的区别。相同点会带来相同的优点,不同之处造就了各自的缺点。
相同点
这两张类图似乎一般无二:一个对外接口;若干个接口方法;一个基类;若干个子类;另外有一个工厂与之配合。
之所以有如此高的相似度,是因为这两种模式的基本思路都是一样的:对外提供一个抽象,对内扩展为不同的实现。
不同点
看起来,只有接口方法不同:策略模式用一个接口方法来处理所有的状态迁移;而状态模式则用不同方法来处理迁移到不同状态时的动作。
这个看起来不起眼的区别,实际上代表了这两种模式截然不同的“抽象”方式。策略模式将状态迁移的“操作”设计为抽象接口;而状态模式的抽象接口代表了“状态”本身。换句话说,策略模式是对行为的抽象,状态模式是对数据的抽象。
优点
面向接口的设计和编程方式可以带来数不尽的有点:接口对内高内聚,对外低耦合;实现类内部高内聚,彼此之间低耦合;对新增实现类保持开放,对修改现有类尽量封闭;等等等等。
缺点
用策略模式实现状态机,从代码还原到状态机时会遇到一些困难。在我实践过的代码中,团队成员都反应过这一点。用状态模式来做会更明白一些:因为状态模式同时封装了数据和行为,虽然也只是一个“片段”,但片段中包含的信息更多。
用状态模式实现,则会遇到实例化的问题。这是由于包含有数据,所以“状态”实例线程不安全。因而每次执行状态迁移操作时,系统都需要使用一个新的实例。当然,这个问题可以变通解决,但是相比天然只有行为、通常只需要单例实现的策略模式,这还是算得上一个缺点的。
转载于:https://blog.51cto.com/winters1224/1959650