设计模式入门-六大原则

前言

毕竟是做了两年的开发，对于设计模式的六大原则算是有点熟悉的，只是没了解的这么全面，这次咱们一次讲清楚这六大原则是啥。

开闭原则

对扩展开放，对修改关闭。（在不改变原有代码的基础上通过扩展来实现新功能）
这条设计原则是六条里最重要的！
软件的兼容性其实是很重要的东西，咱们不能轻易的把原先程序的功能做修改，这样子兼容性就很差了。想实现或者修改一个功能时，最好能通过新增模块的方式实现。
举个例子，做一个游乐场的售票功能。某天游乐场举办活动，在满足某些条件时顾客可以享受折扣优惠。
比较差劲的做法是，直接把计算票价的函数给改掉。
比较好的做法是，先做一层封装，比如搞个抽象类，这类里存放的是方法，然后用抽象类的不同子类去不同的实现计算票价的方法。如此一来，旧的计算票价的方法还在那里，只是通过扩展了新的方法，满足了需求。某天活动结束了，旧的功能还能继续用。

里式替换原则

这个原则之前鹏哥讲过，当时我还认真听了一下。即，子类必须能替换他们的父类！比如我写个函数，形参是父类对象，那么它就一定必须能接受一个子类对象，而且程序不会产生任何错误或者是异常。
这个原则其实是为了约束大家，不要瞎搞类的继承，要按照这个规则来搞继承。
我们聊几个可能违背里式替换原则的做法：
1.子类抛出了父类不可能会抛出的异常。
这就纯属坑爹了，如何处理呢？很简单，请子类自我消化掉这些异常。
2.退化函数。
退化函数就是，子类override了父类的一个函数，但是它啥也不做。
那咱们应该怎么做来避免违反里式替换原则呢？
我个人认为，子类尽量不要去override父类的非抽象方法，因为一旦你override了父类的非抽象方法，那就有点僵硬了，比如上面我说的异常，当然还有很多。如果你非要override父类方法，那就请你把父类的方法写成抽象方法，这就万事大吉了。如果你非得override父类的普通方法，那请把输入范围搞得更大，但是输出搞得更严格。（宽进严出）

依赖倒转原则

这个我之前不是很熟悉，咱们一起了解一下。
抽象不应该依赖于具体类，具体类应当依赖于抽象。
这句话其实非常好理解，讲的就是，要针对接口编程，而不是针对实现编程。
啥意思呢？其实很简单，比如函数在接受输入参数的时候，尽量不要接受一种实现类对象，而是多接受一点抽象类对象，你懂我意思吧？
另外呢，想实现这个原则，咱们就得在某些地方上约束一下自己了。比如说，子类就尽量不要搞一些抽象类没有的东西，不然咱们调用的时候还是得接受一个实现类的对象，这就很僵硬。

单一职责原则

一个类只负责一个功能领域中的相应职责。
换句话说，如果这个类需要改变，那么原因只能是一个。
兄弟，想想，如果一个类的功能太多，那么这些功能和功能之间的耦合就很紧密，这很僵硬的。而且，这个类的职责越多，这段代码被复用的可能性就降低了。（啥？你说你喜欢写代码？）
为了满足这条规则，咱们得做好职责划分，这个具体情况具体分析。

接口分离原则

使用多个专门的接口，而不使用单一的总接口，即客户端不应该依赖那些它不需要的接口。
其实就是用单一职责的思想去规范接口设计。别把所有的接口放在一起，咱们按照功能将接口做分割。
总之，对于接口，该干的事情都得干，不该干的事情别干。

知道最少原则

也叫迪米特原则。
通俗的来讲，就是一个类对自己依赖的类知道的越少越好。也就是说，对于被依赖的类来说，无论逻辑多么复杂，都尽量地的将逻辑封装在类的内部，对外除了提供的public方法，不对外泄漏任何信息。迪米特法则还有一个更简单的定义：只与直接的朋友通信。首先来解释一下什么是直接的朋友：每个对象都会与其他对象有耦合关系，只要两个对象之间有耦合关系，我们就说这两个对象之间是朋友关系。耦合的方式很多，依赖、关联、组合、聚合等。其中，我们称出现成员变量、方法参数、方法返回值中的类为直接的朋友，而出现在局部变量中的类则不是直接的朋友。也就是说，陌生的类最好不要作为局部变量的形式出现在类的内部。