设计模式->面向对象的抽象原则 SOLID

SOLID原则，神马固体原则，当然不是。这是缩写合成的词语，会此原则，就不用学习设计模式了，这个是心法，真正的无招胜有招的境界。当然我们都没有达到那个层次，还是要学学招数（套路）这个招数就是设计模式，废话不说，我们来说基础原则

S：SRP The Single Responsibility Principle  单一责任原则

一个类干一类事情，或者承担一种类型的责任（有的概念是一个类封装了一种变化，类的概念就是尽量减少变化带来的影响，这个是另外一种思路，这里不谈，想了解的同学自己去查阅资料）

举个例子，鸟类有会吃、会飞的方法，有羽毛的属性。在这里我们已经抽象出这个类的特性了，就是这个类仅承担与其它类不同的责任。相同的呢，当然不能写在这个类里面，这里就要抽象了，比如有头、有脚、会叫、会跑这些很多类都有，我们于是乎就抽象出了野兽这个类。

 

OCP  The Open Closed Principle 开放封闭原则

对扩展开放，对修改是封闭

你总不能写个功能不允许它修改吧，那么写个功能想修改，又不想修改源代码逻辑体体系（多多少少要改点源代码），那么怎么办，修改原来逻辑吗，加入if分支语句，加入子函数，当然不是，别人下次怎么改，一个新人看到一大堆if分支，会不会晕菜，那么怎么改，还是抽象，还是用教小孩为例，我们有了老师和家长这个类，有教这方法，那门我们抽象出一个父类，叫做小孩辅导器吧，有个教学的方法，老师和家长都有教这个方法，那么有一天，要叫个辅导老师了，或者叫姐姐来辅导弟弟了，那么怎么办，在小孩教这个方法加入一个分支,如果是老师怎么办，如果是家长怎么办，如果是姐姐怎么办吗，当然不是，我们只需要一个辅导器的对象，只要有教的方法就行，那门来了个姐姐，继承了这个类，有教的方法就OK。弟弟要学习了，拉个人过来，会教就行，我管你是谁呢，哪怕一个步步高点读机，哪里不会点哪里也行。这里就是开闭原则了。个人理解，对修改封闭，不是只不修改代码，而是不修改逻辑，多扩展开发，是用类来替代程序分支。

 

里氏替换原则 The Liskov Substitution Principle里氏替换原则

太高大上，不懂，简单点，就是父类能干的，子类也能干。还是教学这个例子，教学器能干的教这个方法，姐姐也能干，姐姐还是老师都没关系，只要是教学器一个子类就好，对于孩子吗，弟弟只需要是个教学器，管你是姐姐还是步步高点读机，说不定步步高点读机更受欢迎，谁知道呢。

 

依赖倒置原则 The Dependency Inversion Principle依赖倒置原则

来个官方解释：

1. 高层模块不应该依赖于低层模块，二者都应该依赖于抽象 

2．抽象不应该依赖于细节，细节应该依赖于抽象

蒙逼不，官方解释就是这么复杂，百度路由器的概念，会解释半天，术语一大堆，个人理解呢，就简单多了，上网工具而已。同理，这个就是面向接口、或者面向父类，而非面向实现类和子类。同样以弟弟学习为例，弟弟要学习了，不会了，要有个教的方法，你写代码怎么写，要注入一个对象，这个对象有教的方法，肯定是这样的。不然写死为姐姐，哪天姐姐嫁人了怎么办，弟弟就不学习了吗。理解了吗，面向教学器编程，只要注入个教学器就好了。至于某天弟弟要怎么学习，只要给他个教学器子类就好。这样的好处是，随时替换，用通俗的话就是代码是活的，不是硬代码，不写死了。

 

接口分离原则 ISP  The Interface Segregation Principle接口分离原则

来个官方解释：不能强迫用户去依赖那些他们不使用的接口。换句话说，使用多个专门的接口比使用单一的总接口总要好

这个官方的理解不很难懂，简单点就是接口要和别的接口来说，是抽象了不同点的，有特异的。比如我要个飞的功能，你给我提供了一个接口，该接口有飞和跑的功能，显然是不合适，我不需要要跑的功能，不要给我跑。这个其实和单一原则是呼应的，就是专业的类干专业的事情。引申下命令有简单命令和复杂命令两种格式，是不是异曲同工呢。