设计模式总篇从为什么需要原则到实际落地（附知识图谱）

　　聊聊为什么需要原则
　　我们所有人都看过科幻电影，都看到过未来场景中人类和机器人和平相处的场景
　　为了让拥有自主智能的机器人不失控，人类为机器人制定了三大定律：第一定律：机器人不得伤害人类个体，或者目睹人类个体将遭受危险而袖手不管第二定律：机器人必须服从人给予它的命令，当该命令与第一定律冲突时例外第三定律：机器人在不违反第一、第二定律的情况下要尽可能保护自己的生存
　　当然有时也会出现下面的情况，机器人和人类开始互为阵营，各自为敌
　　但是各自为敌的情况出现，一般都是机器人觉醒了自我意识，不再遵守三大定律
　　从逻辑学来说，如果机器人完全遵守三大定律及其衍生的条约，那么机器人就可以和人类和平相处，当然也会有意外发生。写代码为什么需要设计原则
　　和机器人的三大定律相仿，几十年的编程经验，让几代人总结出来了一些代码设计上的定律，这就是设计模式的七大原则
　　我们遵循七大原则，一定会写出最完美的代码吗？
　　答案当然是不一定，毕竟没有人能保证自己可以完全遵循七大原则，同时个人的编程能力也会起到决定性因素。
　　那我们为什么还要遵守？
　　我自己想到的一句名言（以后或许可以成为名言）
　　向着最好的方向去努力，总不会是最差的结果。七大原则详解开闭原则
　　软件实体对扩展是开放的，但对修改是关闭的，即在不修改一个软件实体的基础上去扩展其功能
　　例如：
　　以策略模式为例，当我们新增一种策略的时候，只需要实现策略顶层接口，在调用的时指向新的策略即可
　　针对这一条原则，在实现难度上要比单一职责更难，在编码期间，我们需要充分考虑未来的拓展性，规范接口，依赖抽象，这样才能在需要拓展的时候，非常方便的实现其效果
　　说明：在接入第三方SSO时，如果需要新增接入方，基于文中的案例，只需实现固定接口，即可优雅的实现相应需求依赖倒置原则
　　要针对抽象层编程，而不要针对具体类编程
　　例如：
　　以适配器模式为例，将一个类的接口转换成客户希望的另外一个接口，以此实现的前提便是代码中所依赖的都是抽象的，因为只有依赖抽象，才能在代码运行期间改变其实体，利用多态实现需要的效果
　　针对该条原则，其实有一定编程经验的人一定会在无形中注意到，而且了解设计模式的话，会发现所有涉及接口和实现的设计模式都会遵从这一条原则
　　最佳实践案例：【一起学系列】之模板方法：写SSO我只要5分钟
　　说明：和上一条原则的侧重点不同，在SSO中必然有其固定的流程，如登录获取Token获取用户信息解析退出等等，在代码的编写阶段，需要我们定义出接口抽象类，然后依赖于抽象层，最终改变具体类，以此达到无缝切换的效果合成复用原则
　　总结一句话就是：多用组合，少用继承
　　例如：
　　以单例模式和代理模式为例，它们都是该模式的最佳实践者，单例模式是把不同的策略接口通过组合的方式嵌入到Context类中，如代码所示：publicabstractclassDuck｛飞行行为是动态的，可能会变的，因此抽成多个接口的组合，而不是让Duck类继承FlyBehaviorflyB每个鸭子的叫声不同，抽象成接口QuackBehaviorquackB｝
　　同理，代理模式也是如此，这里就考虑到一个问题，为什么要多用组合而非继承？
　　其实还是Java中单继承引发的问题，同时继承的语义过于苛刻，因此更多的时候建议善用组合
　　最佳实践案例：【一起学系列】之策略模式：好多鸭子啊
　　说明：策略模式就是合成复用原则的最佳实践者，没有之一单一职责原则
　　类的职责要单一，不能将太多的职责放在一个类中
　　例如：
　　在代码设计中某种场景可能存在多种不同的状态，很可能就把代码混在一起了，这时我们利用状态模式进行设计，把各种状态对应的实现细节都用类的级别单独划分，即体现了单一职则原则
　　针对这一条原则，其实绝大多数人在设计之初都会考虑到，但问题就在于随着工作中人员职责的交叉，很有可能会破坏他人设计的最初目的，为了方便，让一个类拥有五花八门的功能
　　最佳实践案例：【一起学系列】之状态模式：你听过流程模式吗？
　　说明：在状态模式中，每一种状态的处理都是独立的一个类，每个类只需要处理自身的核心逻辑，完美体现了单一职责原则里氏代换原则
　　在软件系统中，一个可以接受基类对象的地方必然可以接受一个子类对象
　　当使用继承时，遵循里氏替换原则。类B继承类A时，除添加新的方法完成新增功能外，尽量不要重写父类A的方法，也尽量不要重载父类A的方法
　　继承包含这样一层含义：父类中凡是已经实现好的方法（相对于抽象方法而言），实际上是在设定一系列的规范和契约，虽然它不强制要求所有的子类必须遵从这些契约，但是如果子类对这些非抽象方法任意修改，就会对整个继承体系造成破坏。而里氏替换原则就是表达了这一层含义
　　例如：
　　我们都用过ArrayList，有谁看过forEach方法的源码？ArrayList的父级接口Iterable定义的默认方法defaultvoidforEach（C？superTaction）｛Objects。requireNonNull（action）；for（Tt：this）｛action。accept（t）；｝｝
　　ArrayList重写的方法：OverridepublicvoidforEach（C？superEaction）｛Objects。requireNonNull（action）；finalintexpectedModCountmodCSuppressWarnings（unchecked）finalE〔〕elementData（E〔〕）this。elementDfinalintsizethis。for（inti0；modCountexpectedModCi）｛action。accept（elementData〔i〕）；｝if（modCount！expectedModCount）｛thrownewConcurrentModificationException（）；｝｝
　　我们看到，ArrayList的重写只是针对数组这种结构优化了性能，其目的性和Iterable接口中的完全一致，因此这种方式的重写不会引起任何问题，反而可以提高效率，我们需要学习这样的方式迪米特原则
　　一个对象应该对其他对象保持最少的了解，又名：最少知道原则
　　例如：
　　在代码设计场景中，某一个类的调用都会固定使用三个方法，是否可以考虑把三个方法抽取出来，提供一个公共的对外方法？这种思路就是外观模式，外观模式也是迪米特原则的最佳实践
　　最佳实践案例：【一起学系列】之适配器模式：还有外观模式呢
　　说明：利用外观模式构建统一的对外方法，屏蔽其内部实现，这样一旦内部实现需要更改，完全不会影响调用方，你Get了吗？接口隔离原则
　　使用多个专门的接口来取代一个统一的接口
　　这个模式其实也很好理解，比如我们定义了接口A，接口B实现了接口A，接口C实现了接口B，基类D其实只需要接口C的方法，但是此时不得不实现所有的方法
　　其实造成这个根本原因：对接口的抽象，设计出现了偏差
　　毕竟看过JDK源码或者Spring源码的同学，可以经常发现某一个接口可能实现了一大堆的接口，但是对于普通开发者而言，没有这种强大的设计能力，就需要在设计的时候多思考，如果发现违背了接口隔离原则的情况，就应该对接口进行拆分思维导图
　　作者：Kerwin
　　链接：https：juejin。impost5f021453e51d4534a40d9db2