为什么要提倡“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编程,而非实现类。这样,更换子类不会影响调用它方法的代码。要让各个类尽可能少的跟别人联系,“不要与陌生人说话”。这样,城门失火,才不至于殃及池鱼。扩展性和维护性才能提高。

最少知识原则

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