状态机（理论）
说起状态机，就不得不说状态模式了。
设计模式是死的，而实现是活的。真的，我一直感觉死记硬背真的不适合我，我还是比较适合先理解，然后构建自己的实现版本这样的= =
什么是状态模式，状态模式就是对象的变换情况是有限的，并且这些情况之间的互相转换关系是可知的。转换之间的条件就是根据输入的值来进行变换，那么就可以将转换本身进行封装，从而简化代码。
OK，接下来说说状态机，按照我粗浅地理解，状态机就是一种带有状态标识的对象。状态机会根据你的输入在不同的状态中不断切换，但是绝对不会超过所预设的状态范围之外。常见的就是TCP协议，抓过包的朋友们应该都清楚TCP的头中含有6个状态位，分别表示六种不同的情况，像syn，ack，fin之类的。
最近在学函数式编程，所以也接触到了函数式编程中的状态变化。函数式编程的思想就是不变和静态，但是如果遇到只能通过状态变化的方式来达成需求的情况该怎么办呢？这个时候，只能尽可能地将不变的部分尽可能进行抽象，同时将状态变化的部分尽可能地微粒化。函数式编程的有趣之处就是在于将方法变为纯函数，与此同时，将作用，也就是不可函数式的部分尽可能的与可函数式的部分抽离。因为函数式的部分是透明的，求解的结果是确定的，同时也是充分解耦和高度复用的，所以，对于函数式的部分的单元测试过程是极其便利且高效的。与此同时，因为作用被通过抽象等方法被尽可能地微粒化，所以作用的测试也会变得前所未有的简单。
不知道你是否听过这么一句话，”如果你觉得生活很轻松，那么一定是有人在替你负重前行！“
那么，请让我替他人负重前行吧，我希望用自己的智慧，来让我们的未来更加美好！
既然，函数式编程有这么多的优点，那为什么大多数程序员没有对其很重视呢？这个问题有时间再说吧，要是再讲这个，就会让篇幅过度冗杂。
OK，回到状态机，在函数式编程中状态机如何使用？
状态本身以及对于各个状态的切换的实现肯定不能在函数式库中实现。在库中，我们只能将状态的匹配和匹配成功后的将切换应用到实例这两个过程进行抽象，封装到函数式库中。这样做的原因还是基于我之前所陈述的，要将作用尽可能的微粒化。
我们所有的努力最终到最后都需要面向实践。理论讲解的相关内容就说到这里了，后续再讲实践部分。