设计原则
SRP 单一职责原则
一般会被大家简单理解为：一个函数只完成一个功能。
实际上，单一职责原则是：任何一个软件模块都应该只对某一类行为者负责。
我比较喜欢记住这个解释：任何一个软件模块都应该有且只有一个被修改的原因。当一组人对一些数据有共同的责任时，那这些数据的处理适合放在同一个地方管理，如果放在不同的地方，那么模块就会相互依赖。
OCP 开闭原则
软件要易于扩展，抗拒修改（限制每次被修改所影响的范围）。
常见的实施过程是：先划分按照需求进行功能分组(SRP)，然后调整这些分组之间的依赖关系。即将系统划分为一系列组件，并且将这些组件间的依赖关系按层次结构进行组织，使得高层组件不会因为底层组件被修改而受到影响。
在控制组件之间的影响时要注意，组件不应该依赖其不直接使用的组件。如果不直接使用，应当给组件设计一个外观，阻隔外来的调用。
LSP 里氏替换原则
对一个类进行的操作来说，当这个类替换成其衍生类时，操作仍然保持合理。
比如，正方形为矩形的子类，那么修改矩形边长的setter操作就违法了LSP原则，因为正方形子类的长宽不可任意修改。
以我的理解，LSP限制说明的观点是，如果父类的操作不能适用于子类，那么这个方法或者这个继承关系本身就不是合理的。当外界想要对子类操作时，还要专门加以区分，这样就徒增工作量了。
ISP 接口隔离原则
如果多个用户的调用的操作都放在了一起，那么这一个大组件的修改就牵一发而动全身，是不好的。ISP要做的就是给操作增加一个专门针对每个用户的操作接口，这样每个用户只依赖自己所需的那个接口，而不是把别人的操作也依赖了。
DIP 依赖反转原则
依赖抽象而不是依赖具体实现。
如果有一些具体实现的代码总是变动，那么依赖这些代码的模块会非常辛苦，他们最好依赖抽象。比如硬件时常更新、电脑连接的外设总是变化，那么操作系统或者软件依赖的最好是一个虚拟的外设，这样就可以阻隔外界的变化，等真正用到的时候，再给这些虚拟的外设指定好具体是哪个外设。
例如工厂模式。