【设计模式】四大原则+迪米特法则

单一职责原则

单一职责原则，就一个类而言，应该仅有一个引起它变化的原因。

如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭受到意想不到的破坏。

软件设计真正要做的许多内容，就是发现职责并把那些职责相互分离[ASD]。

如何判断？

• 如果你能够想到多于一个的动机去改变一个类，那么这个类就具有多于一个的职责[ASD]，就应该考虑类的职责分离。

开放-封闭原则

开放-封闭原则，软件实体（类、模块、函数等等）可以扩展，但不可修改。

也就是对扩展开放，对更改封闭。

该原则要求，你在设计的时候，就该让一个类足够的好，在之后的过程中，不要修改这个写好的类，而是去新增一个类。

但说实话，绝对的封闭是不可能的，所以我们只能再设计的时候尽可能的猜测可能变化的种类，然后构造抽象来隔离变化。

如果真的出现了变化，必须修改之前写好的类，那么我们就需要遵循变化发生立即采取行动，也就是将这个写好的类立刻抽象，便于下次如果再添加功能好添加功能。

举个例子：

• 再写计算器的时候，最开始只是在客户端写了加法，后来需求说再添加减发，这时我将加法和减法提取出来，并抽象出运算符类，之后若需求再说添加其他运算，那么我就不用修改了，只需要加功能即可。

我们希望的是在开发工作展开不久就知道可能发生的变化。查明可能发生的变化所等待的时间越长，要创建正确的抽象就越困难。

依赖倒转原则

依赖倒转原则，原话解释是：抽象不应该依赖细节，细节应该依赖于抽象。简单讲就是：依赖接口编程，再一个就是高层模块不应该依赖低层模块，而是依赖抽象（接口）

举个例子：

• 我们在写有关数据库访问的代码时，先将相关数据库的代码封装起来，之后由另一个模块调用里面的函数。这里数据库模块是低级模块，访问数据库的模块是高级模块。这个事件是高级模块依赖低级模块。

• 现在假设，如果我数据库模块需要更改，那么所有使用该数据库的模块就都需要更改。

• 此时，如果我们在数据库的上面写一个抽象类，或者是接口。那么只要我接口不变，数据库随便改，我高级模块都不需要发生变化。

里氏代换原则

里氏代换原则，子类必须能够替换掉他们的父类型。

也就是说，在程序里，将所有的父类都替换成它的子类，程序的行为没有变化。

怎么理解上述呢？其实就是，父类的功能子类全部都有，子类可以拓展新的功能。

上图解释一下，动物可以吃、喝、跑、叫，那么我的猫类也实现了吃、喝、跑、叫，那么我将所有的动物都替换成猫，程序也在执行这四种行为。这时才表明父类真正的被复用，如果想有别的动物，也必须实现动物类里的吃、喝、跑、叫四个功能。

迪米特法则

迪米特法则，如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用。

只与直接的朋友通信。首先来解释一下什么是直接的朋友：每个对象都会与其他对象有耦合关系，只要两个对象之间有耦合关系，我们就说这两个对象之间是朋友关系。耦合的方式很多，依赖、关联、组合、聚合等。其中，我们称出现成员变量、方法参数、方法返回值中的类为直接的朋友，而出现在局部变量中的类则不是直接的朋友。也就是说，陌生的类最好不要作为局部变量的形式出现在类的内部。

迪米特法则引用https://blog.csdn.net/zhengzhb/article/details/7296930