什么时候使用状态模式

前言

最近感觉架构师越来越杂，随随便便面试一个人，简历上都要写上架构相关的内容，好像写上就变成大神一样，但是一细问，却又什么都说不出来，而且问知道哪些设计模式，除了单例，工厂，观察者几个能叫上名，其他的都不是特别了解，最奇葩的是虽然能说出名字和怎么实现的，但是却很少有真正能用上的，感觉莫名其妙，不用你了解他干嘛？

架构师：实话实说在应用端，真心能称得上架构师的少之又少，首先应用代码量与瓶颈并不大，来两个刚毕业的大学生也能写一个应用。其次是代码过于碎片化。每个页面可能就是一个功能，如果说有一个负责架构的人，常常感知无从下手。

但不管需不需要，如果你觉得你是架构师那么是否你了解所有的设计模式。并且能够在适当的时候，引入合适的设计模式。

下面我来介绍一下我在引入状态模式的场景和如何设计的。

首先是场景：

我们是一个打车的软件，首页有地图，有业务A,B,C..公用一个地图，每个业务表现的形式不同，有个业务显示小车，有的业务显示搜索，而且各个业务之间前后关系。

A业务可以进入B业务，B业务可以进入C业务，C业务结束，会返回B业务，也可以直接回到A业务。

介绍完场景，我们就开始design我们的设计，

整体设计思想如下：

Context为环境类，

一个抽象状态类和各个子状态就是业务A,B,C

MapNotifyListener是提供给各个业务作为callback使用。

状态的管理我们采用堆栈的形式。

这就是一个状态模式的实现，可能感觉比较简单，但是架子做好了，我们就可以填充我们需要的东西了

1.在抽象状态类中，我们声明一个static 地图实力，这样符合我们的需求场景。所有的状态公用一个。

2.我们可以在每个状态入栈，出栈时加入一些回调，create，resume，pause，init等等，可以参照Activity 的设计。这样各个业务只需要在自己的状态里处理自己的逻辑。

3.我们设计状态中方法回调的时候，可以参考classLoader加载的双亲委派思想，业务执行的时候，选择性的执行父栈中的方法，可以达到最大化的代码复用率

好处：

1.各个业务之间没有耦合

2.分工明确，负责架构的人单独维护这个架构，各个业务只需要关注业务实现就可以了

3.扩展方便，如果我们需要加一个类似的业务，只需要实现一个业务状态就可以了，符合设计原则中的开闭原则。

坏处：

当然也不是没有坏处的，这里的环境类多会设计为单例，调用方便，而且可以保证我们只有一个栈的管理，所有栈的管理尤为重要，入栈和出栈的时机要掌握好，否则很容易造成栈的混乱或者内存泄漏。

总结：

虽然无法找到最好的设计模式。但可以找到最适合当前业务的。