OO原则
设计模式的最终目标：建立弹性的设计，高复用，可以维护，可以应对变化。（设计模式可以认为是良好的OO设计经验）
常用的面向对象设计原则包括7个，这些原则并不是孤立存在的，它们相互依赖，相互补充。
|
设计原则名称 |
设计原则简介 |
|
单一职责原则 (Single Responsibility Principle, SRP) |
类的职责要单一，不能将太多的职责放在一个类中 |
|
开闭原则 |
软件实体对扩展是开放的，但对修改是关闭的，即在不修改一个软件实体的基础上去扩展其功能 |
|
里氏代换原则 |
在软件系统中，一个可以接受基类对象的地方必然可以接受一个子类对象 |
|
依赖倒转原则 |
要针对抽象层编程，而不要针对具体类编程 |
|
接口隔离原则 |
使用多个专门的接口来取代一个统一的接口 |
|
合成复用原则 |
在系统中应该尽量多使用组合和聚合关联关系，尽量少使用甚至不使用继承关系 |
|
迪米特法则 |
一个软件实体对其他实体的引用越少越好，或者说如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用，而是通过引入一个第三者发生间接交互 |
- 封装变化。把会变化的部分取出并“封装”起来，好让其他部分不受到影响。
- 多用组合，少用继承。（利用继承设计子类的行为，是在编译时静态决定的，而且所有的子类都会继承到相同的行为。然而，如果能够利用组合的做法扩展对象的行为，就可以在运行时动态地进行扩展。通过动态地组合对象，可以写新的代码添加新的功能，而无须修改现有代码。既然没有改变现有代码，那么映入BUG或产生意外副作用的机会将大幅度减少。）
- 针对接口编程，不要针对实现编程。
- 为交互对象之间的松耦合设计而努力。
- 类的设计应该对扩展开放，对修改关闭。（组合思想的进一步应用）
- 要依赖抽象，不要依赖具体类。（依赖倒置原则，变量不可以持有具体类的应用，不要让类派生自具体类，不要覆盖基类中已实现的方法。）
- 最少只是原则：之和你的密友谈话。不要让太多的类耦合在一起，免得修改系统中的一部分，会影响到其他部分。如果多个类之间相互依赖，那么这个系统就会变成一个易碎的系统，它需要许多维护成本，也会因为太复杂而不容易被其他人了解。
- 单一责任原则。一个类应该只有一个引起变化的原因。根据类设计的开闭原则，我们知道要避免类内的改变，因为修改代码很容易造成许多的错误。如果有一个类具有两个改变的原因，那么这会使得将来该类的变化几率上升，而当它真的改变时，你的设计中同时有两个方面将会受到影响。
