单一职责原则 SRP (Single Reponsibility Principle)
就一个类而言，应该仅有一个引起它变化的原因。 软件设计真正要做的许多内容，就是发现原则并把那些原则相互分离。如果多余一个动机去改变一个类，那么这个类就具有多余的一个职责，这时候就应该考虑类的职责分离。
开放封闭原则 OCP (Open-Colosed Principle)
软件实体(类、模块、函数)应该是可以扩展的，但是不可修改。就是对扩展开放，对修改关闭。通过构建抽象来隔离变化（譬如策略模式）。
依赖倒转原则 DIP (Dependence Inversion Principle)
抽象不应该依赖于细节，细节应该依赖于抽象；高层不应该依赖于低层，低层应该依赖于高层。即针对接口编程，不要针对实现编程。抽象的东西是最稳定 的，我们依赖的就是它的稳定。 编写的过程中应该考虑如何针对抽象编程，而不是针对细节编程，即程序中所有的依赖关系都终止于抽象类或者接口，那就是面向对象设计，反正就是过程化设计 了。 （终止指的是具体实现类的形态已经依赖于抽象类）
里氏代换原则 LSP (Liskov Substitution Principle)
子类型必须能够替代其父类型。即，在软件里面，把父类都替换成他的子类，程序行为没有发生变化。 有了里氏代换原则，才能使继承复用成为可能，只有当子类可以替换掉父类时，软件的功能不受影响，父类才能真正被复用，而子类也能在父类的基础上增加新的行 为。 有了里氏代换原则，才能使开放-封闭成为可能，正是由于子类型的可替换性才使得父类型的模块在无需修改的情况下扩展。
接口隔离原则 ISP (Interface Segregation Principle)
不应该强迫客户依赖于他们不用的方法。接口属于客户，不属于它所在的类层次结构。 通俗的说法：不要强迫用户使用他们不使用的方法，否则这些客户就会面临由于不使用的这些方法的改变所带来的改变。
参考下图的设计，在这个设计里，取款、存款、转帐都使用一个通用界面接口，也就是说，每一个类都被强迫依赖了另两个类的接口方法，那么每个类有可能因为另外两个类的方法(跟自己无关)而被影响。拿取款来说，它根本不关心“存款操作”和“转帐操作”，可是它却要受到这两个方法的变化的影响。
那么我们该如何解决这个问题呢？参考下图的设计，为每个类都单独设计专门的操作接口，使得它们只依赖于它们关系的方法，这样就不会互相影了！
实现方法：1、使用委托分离接口；2、使用多重继承分离接口
迪米特原则 LoD(Law of Demeter)、LKP(Least Knowledge Principle)
如果两个类彼此间不直接通信，那么这两个类就不应当发生直接的相互作用。如果其中一个类要调用另一个类的某个方法的话，可以通过第三方转发这个调用。 强调：在类的结构设计上，每一个类都应该尽量降低成员的访问权限；类之间的耦合越弱，越利于复用，一个处于弱耦合的类被修改，不会对有关系的类造成波及。
合成/聚合复用原则 CARP (Composite/Aggregate Reuse Principle)
在一个新的对象里面使用一些已有的对象，使之成为新对象的一部分。新对象通过向这些对象的委派达到复用已有功能的目的。
参考资料：
http://www.blogjava.net/totobacoo/articles/138227.html
http://www.cnblogs.com/feipeng/archive/2007/03/02/661840.html
