这里的模式就是我们常说的设计模式，用演进这个词，是因为我觉得模式不是起点，而是设计的终点在线课堂。《设计模式》这本书的内容不是作者的发明创造，而是其从大量实际的系统里提取出来的，它们大都是早已存在并已经广泛使用的做法，只不过没有被系统的梳理。换句话说，只要遵循前面叙述的某些原则，这些模式完全可能会自然在系统代码中体现出来，在《敏捷软件开发》这本书里，就特意有一个章节，描述了一段代码随着调整慢慢演进到了观察者模式的过程。
拥有模式固然是好的，比如搜索系统里，通过 Template Method 模式，定义一套完整的搜索参数解析模版，只需要增加配置就可以定制不同的查询诉求在线课堂。这里最想强调的是不要设计模式驱动编程，拿交易系统里的状态机来举例子（状态机简直太常见了，简单如家里使用的台灯，都有一个开和关的状态，只是交易场景下会更加复杂），在餐饮外卖交易有如下的状态流转模型：
因为是简写了流程在线课堂，所以上面的代码看起来还是挺能接受的，但是对于订单状态这么复杂的状态机，这个 switch/case 语句会无限膨胀，可读性很差，另一个问题是状态的逻辑和动作没有拆开，《设计模式》提供了一个 State 模式，具体做法是这样：
这个模式确实分离了状态机的动作和逻辑，但是随着状态的增加，不断增加 State 的类会让系统变得异常复杂，而且对 OCP 的支持也不好：对切换状态这个场景，新增类会引起状态切换类的修改，最不能忍受的是这个方式会把整个状态机的逻辑隐藏在零散的代码里在线课堂。