设计原则

    为什么要提倡“Design Pattern呢？根本原因是为了代码复用，增加可维护性。那么怎么才能实现代码复用呢？

面向对象有几个原则：

• 开闭原则（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”。就是说模块应对扩展开放，而对修改关闭。模块应尽量在不修改原（是“原”，指原来的代码）代码的情况下进行扩展。那么怎么扩展呢？

    玉帝招安美猴王：当年大闹天宫的美猴王便是玉帝天庭的新挑战。太白金星给玉皇大帝提出的建议是：招安，一则不动众劳师，二则收仙有道也。换言之，不劳师动众、不破坏天规便是“闭”，收仙有道便是“开”。招安之法便是玉帝天庭的“开-闭”原则，通过给美猴王封一个“弼马温”的官职，便可使现有系统满足变化了的需求，而不必更改天庭的既有秩序。用面向对象的语言来讲，不允许更改的是系统的抽象类层，而运行扩展的是系统的实现层。

里氏代换原则

    里氏代换原则是由Barbara Liskov提出的。如果调用的是父类的话，那么换成子类也完全可以运行。比如：

Parent p = new Child1();p.walk();

要将 Child1 类改为 Child2 类，没问题，完全可以运行。Java编译程序会检查程序是否符合里氏代换原则。还记得java继承的一个原则吗？子类override方法的访问权限不能小于父类对应方法的访问权限。比如 Parent 中的方法 walk() 访问权限是 Public，那么 Child1和 Child2中的 walk()方法就不能是protected或private，编译不能通过。为什么要这样呢？你想啊：如果 Child1的 walk()方法是private。那么下面这段代码就不能执行了：

Parent p = new Child1();p.walk();

可以说：里氏代换原则是继承复用的一个基础。

依赖倒转原则

    抽象不应该依赖于细节，细节应当依赖于抽象。

    要针对接口编程，而不是针对实现编程。

传递参数，或者在组合聚合关系中，尽量引用层次高的类。

主要是在构造对象时可以动态的创建各种具体对象，当然如果一些具体类比较稳定，就不必在弄一个抽象类做它的父类，这样有画蛇添足的感觉.

接口隔离原则

    定制服务的例子，每一个接口应该是一种角色，不多不少，不干不该干的事，该干的事都要干。

合成/聚合复用

    合成/聚合复用原则（Composite/Aggregate Reuse Principle，CARP）经常又叫做合成复用原则。合成/聚合复用原则就是在一个新的对象里面使用一些已有的对象，使之成为新对象的一部分；新的对象通过向这些对象的委派达到复用已有功能的目的。它的设计原则是：要尽量使用合成/聚合，尽量不要使用继承。

    就是说要少用继承，多用合成关系来实现。我曾经这样写过程序：有几个类要与数据库打交道，就写了一个数据库操作的类，然后别的跟数据库打交道的类都继承这个。结果后来，我修改了数据库操作类的一个方法，各个类都需要改动。“牵一发而动全身”！面向对象是要把波动限制在尽量小的范围。

    在Java中，应尽量针对Interface编程，而非实现类。这样，更换子类不会影响调用它方法的代码。要让各个类尽可能少的跟别人联系，“不要与陌生人说话”。这样，城门失火，才不至于殃及池鱼。扩展性和维护性才能提高。

最少知识原则

    也叫迪米特法则。不要和陌生人说话，即一个对象应对其他对象有尽可能少的了解。