设计模式设计原则

设计模式真的非常非常简单，就是前人总结的如何写出高质量，高扩展，低耦合的代码。就是一个规范概念，不必陷入**设计模式 **这四个字眼里面去了，总结的经验而已。我将用大白话总结设计模式。

单一职责原则

看到类名就需要大概清楚这个类是做什么的，面对庞大的项目系统，一个类里面塞满了乱七八糟的东西，你的接盘侠会拿刀来找你。一个类负责一个功能，设计简洁，明了。

开闭原则

同样是在庞大的项目背景下，千千万万的程序员组合成的代码，即使他写了注释，想要完全读懂别人的代码基本不可能也没这个精力。所以要求程序员写代码时要考虑到代码后期的扩展问题，把代码写死是禁忌，写死了的话别人就只能把你的老代码读懂并修改你的老代码。但如果你提供了扩展，接盘侠就只要写新的需求然后根据文档处理了，不需要管以前的老代码怎么写的，只需要根据文档看你这个老代码是做什么的，扩展的地方在哪，我直接扩展就行。

里氏替换

基类出现的地方一定能使用其子类。反过来却不行。我喜欢动物，那我一定喜欢狗，我喜欢狗，但我却不喜欢所以动物（蛇）。也就是要求我们将父类设计成接口，子类实现父类重写父类方法。通过多态来达到里氏替换。这样可以很方便的实现扩展，根本不用改原来的代码，只需让新代码也实现其接口就行，轻而易举就扩展了。算是开闭原则的实现之一。

依赖倒转

感觉和里氏替换差不多，个人认为可以把这俩看成一个，它要求我们针对接口编程。不陷进去了。

接口隔离

当一个接口过大，方法过多，并且使用时只用到了接口里的某些方法，完全可以把该接口拆分成更细的接口，我都没用到那几个方法，还是不得不给那些方法重写。理解为接口层次的单一职责

合成复用原则

组合：强关系，比如人和头一定是组合关系
聚合：弱一点的关系，电脑和鼠标，即使没有也不会造成毁灭性影响
当我们想用一个已经存在的类时，可以通过继承该类或者把该类的对象组合/聚合进来。相比直接继承破坏了封装性，增加耦合，优先使用组合/聚合对象的方式。（其实这里根本不用提，大家潜移默化就是这么做的，所以说不必陷入设计模式 这个字眼里去，理解即可，过度规范反而加重了负担）

迪米特法则

要求类与类之间尽可能保持独立，减少耦合。如果一个对象必须调用另一个对象的方法，可以通过第三者转发，与无关的第三者耦合可比俩个业务类耦合在一起好多了。