面向对象设计原则

　　为什么要提倡“设计原则“呢？根本原因是为了代码复用，增加可维护性。那么怎么才能实现代码复用呢？面向对象有几个原则：开闭原则（Open Closed Principle，OCP）、里氏替换原则（Liskov Substitution Principle，LSP）、依赖倒置原则（Dependency Inversion Principle，DIP）、接口隔离原则（Interface Segregation Principle，ISP）、合成/聚合复用原则（Composite/Aggregate Reuse Principle，CARP）、迪米特法则（Principle of Least Knowledge，PLK）。开闭原则具有理想主义的色彩，它是面向对象设计的终极目标。其他几条，则可以看做是开闭原则的实现方法。
　　设计模式就是实现了这些原则，从而达到了代码复用、增加可维护性的目的。

开闭原则

　　此原则是由Bertrand Meyer提出的。原文是：“Software entities should be open for extension,but closed for modification”。就是说模块应对扩展开放，而对修改关闭。模块应尽量在不修改原（是“原”，指原来的代码）代码的情况下进行扩展。开闭原则中“开”，是指对于组件功能的扩展是开放的，是允许对其进行功能扩展的；开闭原则中“闭”，是指对于原有代码的修改是封闭的，即不应该修改原有的代码。
　　实现开闭原则的关键就在于“抽象”。把系统的所有可能的行为抽象成一个抽象底层，这个抽象底层规定出所有的具体实现必须提供的方法的特征。作为系统设计的抽象层，要预见所有可能的扩展，从而使得在任何扩展情况下，系统的抽象底层不需修改；同时，由于可以从抽象底层导出一个或多个新的具体实现，可以改变系统的行为，因此系统设计对扩展是开放的。
　　在软件开发的过程中，一直都是提倡需求导向的。这就要求我们在设计的时候，要非常清楚地了解用户需求，判断需求中包含的可能的变化，从而明确在什么情况下使用开闭原则。
　　关于系统可变的部分，还有一个更具体的对可变性封装原则（Principle of Encapsulation of Variation, EVP），它从软件工程实现的角度对开闭原则进行了进一步的解释。EVP要求在做系统设计的时候，对系统所有可能发生变化的部分进行评估和分类，每一个可变的因素都单独进行封装。
　　我们在实际开发过程的设计开始阶段，就要罗列出来系统所有可能的行为，并把这些行为加入到抽象底层，根本就是不可能的，这么去做也是不经济的。因此我们应该现实的接受修改拥抱变化，使我们的代码可以对扩展开放，对修改关闭。

里氏代换原则

　　里氏代换原则是由Barbara Liskov提出的。如果调用的是父类的话，那么换成子类也完全可以运行。可以说：里氏代换原则是继承复用的一个基础，只有当子类类可以替换父类，软件单位的功能不受到影响时，父类才能真正被复用，而子类也能够在父类的基础上增加新的行为。里氏代换原则是对“开-闭”原则的补充。实现“开-闭”原则的关键步骤就是抽象化。而父类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。

依赖倒转原则

　　依赖倒置原则：1）抽象不应该依赖于具体，具体应当依赖于抽象。2）要针对抽象编程，而不是针对具体编程。3）高层次模块不应该依赖于低层次模块，都应该依赖于抽象。
　　依赖倒置要求在软件设计时要依赖于抽象，不要依赖实现进行编程，降低客户代码与实现之间的耦合。

接口隔离原则

　　客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。接口隔离原则要求把接口细化，每一个接口完成独立的属于自己角色的功能。没有关系的接口合并在一起，将形成一个臃肿的大接口，这是对角色和接口的一种污染。
　　故名思议，接口隔离原则使客户只依赖与它们有关的方法，不强迫客户使用它们不用的方法，如果强迫用户使用它们不使用的方法，那么这些客户就会面临由于这些不使用的方法的改变所带来的改变。

合成/聚合复用

　　合成/聚合复用原则（Composite/Aggregate Reuse Principle，CARP）经常又叫做合成复用原则。合成/聚合复用原则就是在一个新的对象里面使用一些已有的对象，使之成为新对象的一部分；新的对象通过向这些对象的委派达到复用已有功能的目的。它的设计原则是：要尽量使用合成/聚合，尽量不要使用继承。
　　就是说要少用继承，多用合成关系来实现。在使用继承是需严格考虑“is A”的问题，如果该问题不满足，则建议使用组合而非继承。不合理的继承会导致“牵一发而动全身”！而面向对象要求软件尽量脱离耦合。

迪米特法则

　　又叫最小知识原则，不要和陌生人说话，即一个对象应对其他对象有尽可能少的了解。
　　迪米特法则要求：一个软件实体应当尽可能少的与其他实体发生相互作用。每一个软件单位对其他的单位都只有最少的知识，而且局限于那些与本单位密切相关的软件单位。
　　迪米特法则的初衷在于降低类之间的耦合。由于每个类尽量减少对其他类的依赖，因此，很容易使得系统的功能模块功能独立，相互之间不存在（或很少有）依赖关系。
　　迪米特法则不希望类之间建立直接的联系。如果真的有需要建立联系，也希望能通过它的中介者来转达。因此，应用迪米特法则有可能造成的一个后果就是：系统中存在大量的中介类，这些类之所以存在完全是为了传递类之间的相互调用关系——这在一定程度上增加了系统的复杂度。
　　设计模式中外观模式和中介者模式就是对迪米特法则最好的诠释。