一、针对接口编程，而不是针对实现编程
– 客户无需知道所使用对象的特定类型，仅仅须要知道对象拥有客户所期望的接口。
小注：
接口是定义行为，仅仅是定义我们要做什么事情，至于怎样做这些事情是由接口的实现来做的，当我们定义接口的时候无需关心这个行为怎样实现，仅仅要知道有这个接口就能够。
别人在调用你的代码的时候，都是调用你的接口对象，至于怎样实现。对别人是透明的。
二、优先使用对象组合，而不是类继承
– 类继承通常为“白箱复用”。对象组合通常为“黑箱复用”。继承在某种程度上破坏了封装性，子类父类耦合度高；而对象组合则仅仅要求被组合的对象具有良好定义的接口，耦合度低。
小注：
由于继承在编译时刻就定义了，所以无法在执行时刻改变从父类继承的实现。更糟的是。父类通常至少定义了部分子类的详细表示。
由于继承对子类揭示了其父类的实现细节。所以继承常被觉得“破坏了封装性” 。子类中的实现与它的父类有如此紧密的依赖关系，以至于父类实现中的不论什么变化必定会导致子类发生变化。当你须要复用子类时，实现上的依赖性就会产生一些问题。假设继承下来的实现不适合解决新的问题，则父类必须重写或被其它更适合的类替换。这样的依赖关系限制了灵活性并终于限制了复用性。
一个可用的解决方法就是仅仅继承抽象类。由于抽象类通常提供较少的实现。
对象组合是通过获得对其它对象的引用而在执行时刻动态定义的。组合要求对象遵守彼此的接口约定。进而要求更细致地定义接口。而这些接口并最好还是碍你将一个对象和其它对象一起使用。这还会产生良好的结果：由于对象仅仅能通过接口訪问，所以我们并不破坏封装性；仅仅要类型一致，执行时刻还能够用一个对象来替代还有一个对象。更进一步。由于对象的实现是基于接口写的，所以实现上存在较少的依赖关系。
对象组合对系统设计还有还有一个作用，即优先使用对象组合有助于你保持每一个类被封装，并被集中在单个任务上。这样类和类继承层次会保持较小规模，而且不太可能增长为不可控制的庞然大物。还有一方面。基于对象组合的设计会有很多其它的对象 (而有较少的类)。且系统的行为将依赖于对象间的关系而不是被定义在某个类中。
三、封装变化点
– 使用封装来创建对象之间的分界层。让设计者能够在分界层的一側进行改动。而不会对还有一側产生不良的影响，从而实现层次间的松耦合。
小注：
考虑你的设计中哪些地方可能变化。这样的方式与关注会导致又一次设计的原因相反。它不是考虑什么时候会迫使你的设计改变，而是考虑你怎样才干够在不又一次设计的情况下进行改变。
这里的关键在于封装发生变化的概念，这是很多设计模式的主题。---《设计模式》
四、使用重构得到模式
- 设计模式的应用不宜先入为主，一上来就使用设计模式是对设计模式的最大误用。
没有一步到位的设计模式。
敏捷软件开发实践提倡的“Refactoring to Patterns ”是眼下普遍公认的最好的使用设计模式的方法。
五、单一职责原则（SRP Single Responsibility Principle）
– 一个类应该仅有一个引起它变化的原因。
小注：
所谓职责是指类变化的原因。
假设一个类有多于一个的动机被改变，那么这个类就具有多于一个的职责。而单一职责原则就是指一个类或者模块应该有且仅仅有一个改变的原因。
六、开放封闭原则（OCP Open Closed Principle）
– 类模块应该是可扩展的。可是不可改动（对扩展开放，对更改封闭）
小注：
1、对扩展开放。意味着有新的需求或变化时。能够对现有代码进行扩展，以适应新的情况。
2、对改动封闭，意味着类一旦设计完毕，就能够独立完毕其工作，而不要对类进行不论什么改动。
比方：
将业务功能抽象为接口，当业务员依赖于固定的抽象时，对于改动就是封闭的；而通过继承和多态机制，从抽象体派生出新的扩展实现。就是对扩展的开放。
七、Liskov 替换原则（LSP Liskov Substitution Pinciple）
– 子类必须能够替换它们的基类。
八、依赖倒置原则（DIP Dependency Inversion Principle）
– 高层模块不应该依赖于低层模块，二者都应该依赖于抽象。
– 抽象不应该依赖于实现细节，实现细节应该依赖于抽象。
九、接口隔离原则（ISP Interface Segregation Principle）
– 不应该强迫客户程序依赖于它们不用的方法。
尽量应用专门的接口。而不是单一的总接口。接口应该面向用户。将依赖建立在最小的接口上。
十、合成/聚合复用原则(CARP Composite/Aggregate Reuse Principle )
-在新对象中聚合已有对象。使之成为新对象的成员。从而通过操作这些对象达到复用的目的。
合成方式较继承方式耦合更松散，所以应该少继承、多聚合。
小注：
假设两个类之间是“Has-A”的关系应使用组合或聚合。假设是“Is-A”关系可使用继承。
十一、迪米特法则(LoD Law of Demeter )
又叫最小知识原则，指软件实体应该尽可能少的和其它软件实体发生相互作用
小注：
迪米特法则的初衷在于降低类之间的耦合。由于每一个类尽量降低对其它类的依赖，因此，非常easy使得系统的功能模块功能独立，相互之间不存在（或非常少有）依赖关系。
迪米特法则不希望类之间建立直接的联系。假设真的有须要建立联系，也希望能通过它的友元类来转达。因此，应用迪米特法则有可能造成的一个后果就是：系统中存在大量的中介类。这些类之所以存在全然是为了传递类之间的相互调用关系——这在一定程度上添加了系统的复杂度。