写这篇文章是基于最近对编码有了一层新的感悟，想接着这篇文章聊一聊
之前我是读过极客时间的专刊~设计模式之美，在里面了解到各种设计模式的应用场景，及解决的问题。为了能够深入理解设计模式也是下了一番工夫，当时最喜欢个别人聊得就是设计模式，但随着时间的推移，这些招式在自己的脑海里面逐渐淡化，那是否有一种无招胜有招的方法呢？把设计模式融入到自己的血液中呢？最近的梳理业务，进行重构的过程中，感觉到了味道。
话不多说，我们开始。。。。。。。
软件架构：指软件系统的顶层结构，他定义了系统有哪些角色组成，角色之间的关系和运作规律；
软件架构可以定义为上面四个部分，那么我们的编码能否也定义为上面四个组成部分呢？
.......
希望大家可以在此处停下来思考上面的问题~~PS：我喜欢引导大家思考.......
设计模式的底层逻辑
很多事物都有底层逻辑，当掌握了事物的底层逻辑之后，很多事就好办了，如果你已经洞察到了最核心的规律，在实际工作中就只需要按照规律去执行就可以。
举个例子：
我们写的web系统，在页面上存在各种各样的操作，对于底层模型来说，无非就是基于不同的表（角色），根据各个表之间的关系（角色关系），做增删改查（运作规则）。当我们定义好各个层级、各个角色、角色之间的关系、及每个字段的动作之后，其实代码就非常清晰了。
所以我常说，流程图即代码，架构的本质就是层级、角色、关系、规则，这四个组成部分定义清晰了，我们的架构也就完成了。而流程图是辅助我们动态调整四个部分的工具，在我们不断调整各个节点的位置的时候，也是在提升对其的认知。
那么设计模式的底层逻辑又是什么呢？（一个值得深思的话题）
通常现象看本质，这是我们在思考底层的时候常用的方法——归纳法
设计模式有一本经典的书籍：《设计模式：可复用面向对象软件的基础》，在书中作者提到了一句话：“找到变化，封装变化”，这才是设计模式的底层逻辑。很多人忽视了这句话，反而去追寻各种模式的招式，遇到实际的问题又找不到合适的设计模式去解决了。“找到变化，封装变化”非常精练地提示了设计模式的本质，细细品味这句话，再去看23种设计模式，每种设计模式都在应对变化的事，比如策略模式，具体的策略在变化；工厂模式，创建的对象在变化；模板模式，具体模板算法实现在变化…… 在实际问题中，需要我们去看什么在变化，选择哪种设计模式比较合适。
再回过头看底层逻辑，平时我们看到的现象只是现象层，核心是要洞察到事物的底层逻辑，只有那样才能真正理解现象、运用规律，如果你不懂现象背后的底层逻辑，你所有的勤奋都是低水平的重复，很难写出高质量的输出，偶尔一两次起得了良好的效果你也不知道为什么能吸引人。优秀的人能够在现象中，发现规律，找到事物的底层逻辑，将其架构到自身的认知中，当认知发生改变时，就重新架构，所以你会发现优秀的人思维非常清晰，用不好设计模式本质还是没有掌握设计模式的底层逻辑，只看到了设计模式的现象层的招式。设计模式的底层逻辑是“找到变化，封装变化”，这里就有两个问题：什么在变化，如何封装变化，大师以为我们都知道，所以并没有讲具体怎么去寻找变化，怎么去封装变化。接下来具体谈谈怎么去运用设计模式的底层逻辑。
设计模式要回答的两个问题
1 什么在变化
“找到变化，封装变化”这句话，首先要回答的是什么在变化，如果变化没有找到，就不可能封装变化。笔者这里以对象生命周期的视角去看待对象的变化，对象是由创建而产生，然后被使用，最后是消亡。对象有三个不同维度的变化：对象结构的变化、对象规格的变化、对象行为的变化。以对象结构变化为例，对象的关系划分成两类：线性关系和非线性关系（树和图），在线性关系中，如何解决一个对象的变化不会影响到关联的对象？在树型结构中，如何解决不断新增加对象的问题？在图型结构中，如何解决用户方便使用复杂系统的问题？
找到变化是最为关键，不同的业务问题，遇到的变化问题也是不一样的，核心是要找到这些变化。比如对象规格的变化，有数量的变化、类型的变化、外观的变化，在实际编码的过程中就要有这种思考，比如创建一个对象，再深入思想下，有没有其它类型的对象？数量有没有变化？……只有找到了这些变化，具体怎么去封装变化就是技术的问题，接下来讨论如何封装变化。
2 如何封装变化
从封装的类型上看，有数据的封装、方法的封装、类型的封装等。就具体的封装方法而言，常见的有配置项、接口、抽象方法、类、注解、插件等具体的手段，再往上看主要使用了继承、组合的方法，再往上看封装的原则，常见的原则有单一职责、开闭原则、依赖倒置、隔离原则……大部分人平时更多地关注如何封装变化，并没有深入去思考什么在变化。
一个案例
我们应该聊天窗业务的第一感知是发送一个问题，返回答案，这就是最为基础的业务；
- **定义核心流程：**定义聊天窗——获取机器人、使用机器人、答案汇总处理的过程。这其实就是聊天窗维度的底层逻辑。
- **找到变化：**核心流程有了之后，我们就可以基于核心流程进行任务拆解，在任务拆解的过程中识别变化，从上图中我们可以很清晰的看到变化。
- 封装变化：当看到上面的结构之后，我们就会很清晰的知道要使用策略模式、职责链模式。
对象变化的方式和封装的方法就这么几种，重要的是我们对业务的理解。当我们对业务有一个较深的理解的时候，不断的进行任务拆分，拼接组合。我们就能发现代码的层级结构是什么，需要哪些对象（角色），他们之间的关系。按照流程图写代码即可。
