文章同步发表于集体博客 shuyi.tech，欢送点击原文跳转浏览。
设计模式说白了就是传统教训的总结，它能让咱们在适合的场景应用适合的模式，从而放慢咱们的编程速度，也能进步零碎的扩展性、稳定性。这里我想就设计模式提出两个观点：
1、设计模式是用来承载简单的业务逻辑的。
2、用好设计模式须要从变动的角度去了解业务。
设计模式用于承载简单的业务逻辑
如果你的业务非常简单，那么基本上是不须要用到设计模式的。只有当你的业务变得复杂的时候，这才须要用到设计模式。这也是为什么设计模式总是和重构一起被提到，因为重构的时候就阐明这个零碎绝对比较复杂了，不然也不会做崩了。
那为什么说设计模式用于承载简单业务呢？
咱们都晓得设计模式都有一个类图，这些类图其实用于示意这种模式对于变动的拆散（对于变动在下文会说到）。 设计模式应用类图来存储简单的业务关系，使得开发者能够专一于业务逻辑的开发，所以说设计模式用于承载简单的业务。
如上图所示是策略模式的类图，Context 类是上下文类，在该类中初始化了具体的策略。Strategy 则是策略接口，ConcreteStrategies 则是具体的策略类。这个类图应用 Strategy 与 ConcreteStrategies 的实现关系，将不同策略隔离开来，开发者不须要去关怀策略彼此的关系。而应用 Context 与 Strategy 的关系隔离开来，开发者不须要去关怀怎么抉择策略。 所以说 Strategy 与 ConcreteStrategies 的关系、Context 与 Strategy 的关系（类关系）承载了一些逻辑，而就是我所说的：设计模式承载了简单的业务逻辑。
应用设计模式去承载简单的业务逻辑，有好也有坏，但总体来说益处比拟多。害处就是对初学者十分不敌对，可能他们齐全看不懂代码。 益处则是相熟设计模式的人，用设计模式能够高深莫测地晓得业务关系，它们应用设计模式作为语言来表白业务的关系。其次，各块代码之间互相隔离，稳定性、扩展性十分好。
从变动的视角去了解业务
我工作了 5、6 年，本该学什么货色都很快。但我却仍旧花了一两个月的工夫，缓缓推敲每个设计模式的实质。 通过一段时间的推敲，我发现了一个了解设计模式的全新视角：变动。
很多时候咱们去了解一个设计模式，咱们不能仅仅晓得它的类图是怎么的，这样的学习齐全流于外表。咱们须要晓得它为什么要这么做？它这样做的起因是什么？它在什么场景下应用？通过这样的一番思考，我发现： 所有设计模式的诞生，都是为了隔离变动。
在利用的时候，咱们须要去剖析需要中哪些是变动的，哪些是固定的。而后应用设计模式去承载变动的货色，封装固定的货色。
工厂办法模式，实质上是为了隔离创建者与使用者。为什么？因为创建者可能是多变的，而使用者则是确定的。
形象工厂模式，实质上是为了隔离产品族。为什么？因为产品族绝对是多变的，所以要把变动的货色剥离进来。
桥梁模式，实质上是为了将实现剥离进来。为什么？因为实现是多变的，而形象则是确定的，所以要剥离进来。
代理模式，实质上是为了将多变的管制玻璃进来。为什么？因为代理自身是为了加强对指标对象的管制，那其管制的规范可能就很多，明天可能要这个条件，今天可能要那个条件。因而须要将变动的货色剥离进来，因而有了代理类。有了代理类，咱们不会净化指标类。
责任链模式，变动的是对于责任的解决。
命令模式，变动的可能是命令的具体做法、执行规范。
迭代器模式，不变的是迭代模式，变动的是不同的数据结构，迭代算法不一样。
中介者模式，变动？关联？更多是帮忙梳理关系。
备忘录模式，变动？没有特地大，其实就是对于类的状态记录，独自由一个类来管制。
观察者模式，变动？对于察看后的解决是不同的，是变动的。雷同的是，他们都要察看获取触发。
状态模式，变动的是这些状态。
策略模式，变动的是这些具体的做法。
模板办法，变动的是具体的某个细节实现，不变的是整个流程算法。
访问者模式，变动的是不同的拜访对象，不变的是我本身的解决流程（例如文件树的遍历）。
那咱们应该如何从「变动」的角度去剖析业务呢？有什么可遵循的套路吗？有什么最佳实际吗？
首先，咱们还是应该从业务的复杂度动手，看看业务是否足够简单。设计模式的实质是用来承载简单的业务构造，如果业务目前还不清晰，并且也很简略，那就不要用设计模式了。
其次，咱们还是应该从变动这个角度动手，剖析业务零碎中哪些是变动的，哪些是不变的。这个就要求你对业务十分相熟，只有熟悉业务能力弄清楚变动在哪里。
最初，剖析这种变动的各个实体关系，看看是否合乎访问者模式的特色（有固定的成分，又须要变动，又不是继承关系）。