设计模式六大原则，參见http://www.uml.org.cn/sjms/201211023.asp。
1. 单一职责原则
定义：不要存在多于一个导致类变更的原因。通俗的说，即一个类仅仅负责一项职责。
问题由来：类T负责两个不同的职责：职责P1。职责P2。当因为职责P1需求发生改变而须要改动类T时，有可能会导致原本执行正常的职责P2功能发生问题。
解决方式：遵循单一职责原则。分别建立两个类T1、T2，使T1完毕职责P1功能。T2完毕职责P2功能。这样，当改动类T1时。不会使职责P2发生问题风险；同理，当改动T2时，也不会使职责P1发生问题风险。
2. 里氏替换原则
这项原则最早是在1988年，由麻省理工学院Barbara Liskov女士提出，故称里氏替换原则。
定义：全部引用基类的地方必须能透明地使用其子类的对象。
问题由来：有一功能P1。由类A完毕。现须要将功能P1进行扩展，扩展后的功能为P。当中P由原有功能P1与新功能P2组成。新功能P由类A的子类B来完毕，则子类B在完毕新功能P2的同一时候，有可能会导致原有功能P1发生问题。
解决方式：当使用继承时。遵循里氏替换原则。类B继承类A时。除加入新的方法完毕新增功能P2外，尽量不要重写父类A的方法，也尽量不要重载父类A的方法。
里氏替换原则通俗的来讲就是：子类能够扩展父类的功能。但不能改变父类原有的功能。
它包括下面4层含义：
Ø 子类能够实现父类的抽象方法，但不能覆盖父类的非抽象方法。
Ø 子类中能够添加自己特有的方法。
Ø 当子类的方法重载父类的方法时，方法的前置条件（即方法的形參）要比父类方法的输入參数更宽松。
Ø 当子类的方法实现父类的抽象方法时，方法的后置条件（即方法的返回值）要比父类更严格。
3. 依赖倒置原则
依赖倒置原则的核心思想是面向接口编程。
定义：高层模块不应该依赖低层模块，二者都应该依赖其抽象。抽象不应该依赖细节。细节应该依赖抽象。
问题由来：类A直接依赖类B。假如要将类A改为依赖类C。则必须通过改动类A的代码来达成。
这样的场景下，类A通常是高层模块。负责复杂的业务逻辑。类B和类C是低层模块，负责主要的原子操作；假如改动类A，会给程序带来不必要的风险。
解决方式：将类A改动为依赖接口I。类B和类C各自实现接口I，类A通过接口I间接与类B或者类C发生联系，则会大大减少改动类A的几率。
4. 接口隔离原则
定义：client不应该依赖它不须要的接口。一个类对还有一个类的依赖应该建立在最小的接口上。
问题由来：类A通过接口I依赖类B，类C通过接口I依赖类D，假设接口I对于类A和类B来说不是最小接口。则类B和类D必须去实现他们不须要的方法。
解决方式：将臃肿的接口I拆分为独立的几个接口，类A和类C分别与他们须要的接口建立依赖关系。
也就是採用接口隔离原则。
5. 迪米特法则
迪米特法则又叫最少知道原则。最早是在1987年由美国Northeastern University的Ian Holland提出。通俗的来讲，就是一个类对自己依赖的类知道的越少越好。
定义：一个对象应该对其它对象保持最少的了解。
问题由来：类与类之间的关系越密切，耦合度越大，当一个类发生改变时，对还有一个类的影响也越大。
解决方式：尽量减少类与类之间的耦合。
6. 开闭原则
定义：一个软件实体如类、模块和函数应该对扩展开放，对改动关闭。
问题由来：在软件的生命周期内，由于变化、升级和维护等原因须要对软件原有代码进行改动时，可能会给旧代码中引入错误，也可能会使我们不得不正确整个功能进行重构。而且须要原有代码经过又一次測试。
解决方式：当软件须要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过改动已有的代码来实现变化。