每一个模式描述了一个在我们周围不断重复发生的问题，以及该问题的解决方案的核心。 ————Chistopher Alexander

　　设计模式描述了软件设计过程中一些常见问题的一般性解决方案。 　　面向对象设计模式描述了面向对象设计过程中、特定场景下、类与相互通信的对象之间常见的组织关系。

1. 设计原则

　　单一职责原则(SRP Single Responsibility Principle)： 　　　　一个类应该仅有一个引起它变化的原因，一个类只干它应该干的事情。

　　开放封闭原则(OCP Open Closed Principle)： 　　　　类模块应该是可扩展的，但是不可修改；一个类一旦定型了，就不要去修改它，有变化时就去扩展它。比如在三层中，DAL层中我们在原先的SQL访问基础上需要增加对MySql的支持，不应该去修改原先的类，而是应该建立一个IDAL接口有，让实现该接口的子类去封装变化。

　　Liskov替换原则(LSP Liskov Substituion Principle)： 　　　　里氏替换原则。在父类出现的地方，都可以使用子类代替。

　　依赖倒置原则(DIP Dependency Inversion Principle)： 　　　　高层模块不应该依赖于低层模块，二者都应该依赖于*抽象*。父类应该不知道子类的存在，在使用的时候，要调用最高层的父类，而不是具体实现的子类。 　　　　抽象不应该依赖于实现细节，实现细节应该依赖于*抽象*。子类的实现应该是从父类抽象出来的，此时父类并不知道子类的存在，也不知道子类做了什么具体的实现。

　　接口隔离原则(ISP Interface Segregation Principle)： 　　　　不应该强迫客户程序依赖他们不用或者用不到的方法。只留给客户端需要的接口，不暴露其他客户端无需使用和知道的方法。 　　　　尽量应用专门(单一作用)的接口，而不是单一的总接口(抽象),接口应该面向用户，将依赖建立在最小的接口上。也就是接口实现的功能应该是单一的，不能让一个接口干一件以上的事情。

　　合成/聚合复用原则(CARP Composite/Aggregate Reuse Principle)： 　　　　在吸纳对象中聚合已有对象，使之成为新对象成员，从而通过操作这些对象达到复用的目的。 　　　　合成方式较继承方式更松散，所以应该少继承、多聚合。

　　迪米特法则(LoD Law of Demeter)： 　　　　又叫最小知识原则，指软件实体应该尽可能少的和其他软件实体发生相互作用。也就是一个类不要实现太多不相关的功能，和单一职责原则比较相似。

2. 从设计原则到设计模式

　　1、针对接口编程，而不是针对实现编程： 　　　　客户无需知道所使用的对象的特定类型，只需要知道对象拥有客户所期望的接口。 　　　　假如有一个父类，三个子类继承他，这三个子类就是客户所期望的具体实现，如果让客户直接去接触这三个子类，这种设计是不好的。最好的方法是：让父类实现一个接口，让客户去接触这个接口，而不是具体的实现。

　　2、优先使用对象组合，而不是类继承： 　　　　类继承通常为“白箱复用”。对象组合通常为“黑箱复用”。继承在某种程度上破坏了封装性，子类父类耦合度高；而对象组合则只要求被组合的对象拥有良好定义的接口，耦合度低。

　　3、封装变化点： 　　　　使用封装来创建对象之间的分界层，让设计者可以在分界层的一侧进行修改，而不会对另一侧产生不良影响，从而实现层次间的松耦合。

　　4、使用重构得到模式： 　　　　*设计模式的应用不宜先入为主，一上来就使用设计模式是对设计模式的最大误用，没有一步到位的设计模式。*敏捷软件开发实践提倡的“Reafactoring to Patterns(从重构到模式)”是目前公认的最好的使用设计模式的方法。 　　　　在现有的代码上重构，是最好的方法，没有一步到位的程序，只有不断完善的程序。从0不能直接到100，但是可以从0到1、从1到10……