1.面向对象的设计原则
单一职责原则、开闭原则、里氏代换原则 、依赖倒置原则、接口隔离原则、合成/聚合复用原则、迪米特法则
（1）单一职责原则（SRP）
一个类，只有一个引起它变化的原因
如果一个类有一个以上的职责，这些职责就耦合在了一起
当一个职责发生变化时，可能会影响其它的职责
多个职责耦合在一起，会影响复用性
SRP中，把职责定义为“变化的原因”
将业务规则和持久化的控制分离
Façade和Proxy模式进行重构
（2）开闭原则（OCP）
软件实体（类、模块、函数等）应该是可以扩展的，但是不可修改
遵循开放-封闭原则设计的两个主要特征
–对于扩展是开放的
–对于更改是封闭的
好处
–可复用性好
软件完成以后，仍然可以对软件进行扩展，加入新的功能，非常灵活 。因此，这个软件系统就可以通过不断地增加新的组件，来满足不断变化的需求。
–可维护性好
由于对于已有的软件系统的组件，特别是它的抽象底层不去修改，因此，我们不用担心软件系统中原有组件的稳定性，这就使变化中的软件系统有一定的稳定性和延续性
特例：STRATEGY模式：既开放又封闭的Client
（3）里氏代换原则（LSP）
子类必须能够替换掉它们的基类型
里氏代换原则是对“开-闭”原则的补充
如果两个具体的类A，B之间的关系违反了LSP的设计
–创建一个新的抽象类C，作为两个具体类的超类，将A，B的共同行为移动到C中来解决问题
–从B到A的继承关系改为委派关系
在进行设计的时候，我们尽量从抽象类继承，而不是从具体类继承
长方形和正方形的例子不满足LSP
OOD的IS-A关系是就行为方式而言的，行为方式是可以进行合理假设的，是客户程序设计所依赖的
（4）依赖倒置原则（DIP）
高层模块不应该依赖于底层模块，二者都应该依赖于抽象
抽象不应该依赖于细节。细节应该依赖于抽象
Hollywood原则: “Don‘t call us, we’ll call you”.程序中所有的依赖关系都应该终止于抽象类和接口针对接口而非实现编程
依赖于抽象的启发式规则：
任何变量都不应该持有一个指向具体类的指针或引用
任何类都不应该从具体类派生
任何方法都不应该覆写他任何基类中的已经实现了的方法
（5）接口隔离原则（ISP）
使用多个专门的接口比使用单一的总接口要好
一个类对另外一个类的依赖性应当是建立在最小的接口上的
一个接口代表一个角色，不应当将不同的角色都交给一个接口
不应该强迫客户依赖于它们不用的方法。接口属于客户，不属于它所在的类层次结构
满足接口隔离原则,调用者只能访问它自己的方法,不能访问到不应该访问的方法
（6）合成/聚合复用原则（CARP）
合成（Composition）和聚合（Aggregation）都是关联（Association）的特殊种类。聚合表示整体和部分的关系，表示“拥有 ”；合成则是一种更强的“拥有”，部分和整体的生命周期一样
在OOD中，有两种基本的办法可以实现复用
合成/聚合
继承
HAS-A而非IS-A
（7）迪米特法则（LoD）
迪米特法则可以简单说成：talk only to your immediate friends
一个软件实体应当尽可能少的与其他实体发生相互作用。每一个软件单位对其他的单位都只有最少的知识，而且局限于那些与本单位密切相关的软件单位
迪米特法则的初衷在于降低类之间的耦合
设计模式的门面模式（Facade）和中介模式（Mediator），都是迪米特法则应用的例子
2.面向对象的高效编程原则
避免创建重复对象
消除过期的对象引用
避免使用终结函数
为所有导出API的元素编写文档注释
使类和成员的可访问能力最小化
复合优先于继承
接口优先于抽象类
定义内部类：优先考虑静态成员类
设计模式可以看http://blog.csdn.net/ydx115600497/article/details/52079826等一系列设计模式
