SOLID原则其实是由面向对象的五大设计原则组成，也是各种设计模式的基础理论。适当遵守SOLID原则，能写出高内聚，松耦合的代码，便于当需求变动能更快的拓展。废话不多说，下面立即正片。
| 原则名称 | 英文原义 | 中文含义 |
|---|---|---|
| Single Responsibility Principle | A class should have one, and only one, reason to change. | 单一责任原则 |
| Open Closed Principle | You should be able to extend a classes behavior, without modifying it. | 开放封闭原则 |
| Liskov Substitution Principle | Derived classes must be substitutable for their base classes. | 里氏替换原则 |
| Interface Segregation Principle | Make fine grained interfaces that are client specific. | 接口分离原则 |
| Dependency Inversion Principle | Depend on abstractions, not on concretions. | 依赖倒置原则 |
没错，S.O.L.I.D原则就是这五个原则的首字母简称，从气势来看就觉得很“结实”，下面就简单介绍各个原则的含义。
单一责任原则
当需要修改某个类的时候原因有且只有一个。原义就是这样，简单来说就是一个类只尽自己所责，不瞎掺和其他功能，因此只会因为 一个功能 的问题而修改一个类。这样做的好处是一个功能出问题了，调试或者更改时可以完全不会影响到另外有一个功能的执行。
开放封闭原则
当系统需要增加新功能的时候，我们应该在原基础上进行拓展，而不是从零开始把之前的代码都修改了。其实这个原则在继承中得到体现，比如由抽象的鸟类，下面的蜂鸟，金丝雀等都继承鸟类这个类，当出现新的鸟物种时，应当在由鸟类的基础上进行继承然后在子类进行拓展的，而不是因为新物种的特性而修改父类。总而言之，对拓展是开放的，对修改是封闭的 。这样做的好处是完全不用担心影响之前运行良好的代码，放心拓展！
里氏替换原则
用到父类实例的地方，把父类实例替换成子类实例应当时 无缝替换 ，照样能跑通的。之后的依赖倒置原则会告诉我们具体的东西应该依赖抽象，具体的东西(如客户端，展现层)在使用具体服务时，应当时使用父类实例，然后根据多态来真实用到子类的功能，如果不按里氏替换原则来的话，当客户端用到服务时，还要根据子类的具体情况进行调整，这样子类需要修改时，就要改两处(子类和客户端)，不便修改。因此需要做到用到父类的地方，换成子类照样无缝替换，这样如果功能出问题了，我们第一反应是只要修改子类即可！
接口分离原则
接口分离原则就是当一个类实现了一个接口后，接口里面的方法都是对这个类有用的，不存在方法体为空来实现(强迫实现)。就是说，一个接口不要太过臃肿，应该粒度更细 ，因为如果接口太过臃肿，可能导致实现类实现了不属于它自己责任的方法从而违反了单一责任原则。
依赖倒置原则
具体类应该依赖抽象类，高级代码 应当也依赖抽象类 ，而不是依赖低级代码。首先先来说下，高级代码和低级代码都是具体类，其中低级代码指提供基础实现的代码，比如读写文件类，图片上传类，但是他们是具体，比如这个图片上传类是将图片上传到七牛的。其中高级代码是涉及到业务逻辑的代码，如需要用到图片上传用作头像的业务代码。这样就有个问题了，明显高级代码依赖低级代码嘛，不依赖低级代码似不似傻？但是假如有一天七牛上传图片崩了，你需要换其他图片上传服务，但是由之前高级代码依赖低级代码，所以高级类里面全tm都是低级类的片段，想想改起来就觉得可啪！！因此假如一开就依赖抽象，那样就能利用多态灵活更改了。
总结
遵守好的设计理念，不一定做出好的产品。但是用不好的设计，肯定做不出好东西！
设计模式以及理念这东西，应该是理解本质后灵活使用的，而不是死记硬背，不然死记硬背的东西，到时候实操起来也不会第一时间想到使用！！
