设计模式的原则

　　为什么要提倡"Design Pattern"呢？根本原因是为了代码复用，增加可维护性。那么怎么才能实现代码复用呢？面向对象有几个原则：开闭原则(Open Closed Principal，OCP)、里氏代换原则（LSP）、依赖倒转原则（DIP）、接口隔离原则（ISP）以及抽象类（Abstract Class）、接口(Interface)。开闭原则具有理想主义的色彩，它是面向对象设计的终极目标。其他几条，则可以看做是开闭原则的实现方法 　　设计模式就是实现了这些原则，从而达到了代码复用、增加可维护性的目的。

开放封闭原则

 

　　此原则是由"Bertrand Meyer"提出的。原文是："Software entities should be open for extension,but closed for modification"。就是说模块应对扩展开放，而对修改关闭。模块应尽量在不修改原(是"原"，指原来的代码)代码的情况下进行扩展。那么怎么扩展呢？我们看工厂模式"factory pattern":假设中关村有一个卖盗版盘和毛片的小子，我们给他设计一"光盘销售管理软件"。我们应该先设计一"光盘"接口。如图： 　　

[pre]______________ 　　

|<>| 　　

| 光盘 | 　　

|_____________| 　　

|+卖() | 　　

| | 　　

|_____________|[/pre] 　　

而盗版盘和毛片是其子类。小子通过"DiscFactory"来管理这些光盘。代码为： 　　

public class DiscFactory{ 　　

               public static 光盘 getDisc(String name)

               { 　　

                    return (光盘)Class.forName(name).getInstance(); 　　

               } 　　

} 　　

有人要买盗版盘，怎么实现呢？ 　　

public class 小子{ 　　

               public static void main(String[] args)

               { 　　

                    光盘 d=DiscFactory.getDisc("盗版盘"); 　　

                    d.卖(); 　　

               } 　　

} 　　

如果有一天，这小子良心发现了，开始卖正版软件。没关系，我们只要再创建一个"光盘"的子类"正版软件"就可以了。不需要修改原结构和代码。怎么样？对扩展开放，对修改关闭。"开-闭原则" 　　工厂模式是对具体产品进行扩展，有的项目可能需要更多的扩展性，要对这个"工厂"也进行扩展，那就成了"抽象工厂模式"。

 

里氏代换原则

 

　　里氏代换原则是由"Barbara Liskov"提出的。里氏代换原则是对“开-闭”原则的补充。实现“开-闭”原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。如果调用的是父类的话，那么换成子类也完全可以运行。比如： 　　

          光盘 d=new 盗版盘(); 　　

          d.卖(); 　　

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

          光盘 d=new 盗版盘(); 　　

          d.卖(); 　　

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

          
  合成/聚合复用原则

 

　　合成/聚合复用原则(Composite/Aggregate Reuse Principle ,CARP)经常又叫做合成复用原则。合成/聚合复用原则就是在一个新的对象里面使用一些已有的对象，使之成为新对象的一部分；新的对象通过向这些对的委派达到复用已有功能的目的。它的设计原则是；要尽量使用合成/聚合，尽量不要使用继承。 　　就是说要少用继承，多用合成关系来实现。我曾经这样写过程序：有几个类要与数据库打交道，就写了一个数据库操作的类，然后别的跟数据库打交道的类都继承这个。结果后来，我修改了数据库操作类的一个方法，各个类都需要改动。"牵一发而动全身"!面向对象是要把波动限制在尽量小的范围。 　　在Java中，应尽量针对Interface编程，而非实现类。这样，更换子类不会影响调用它方法的代码。要让各个类尽可能少的跟别人联系，"不要与陌生人说话"。这样，城门失火，才不至于殃及池鱼。扩展性和维护性才能提高 　　理解了这些原则，再看设计模式，只是在具体问题上怎么实现这些原则而已。张无忌学太极拳，忘记了所有招式，打倒了"玄冥二老"，所谓"心中无招"。设计模式可谓招数，如果先学通了各种模式，又忘掉了所有模式而随心所欲，可谓OO之最高境界。呵呵，搞笑，搞笑！（JR）

 

依赖倒转原则

 

　　抽象不应该依赖于细节，细节应当依赖于抽象。 　　要针对接口编程，而不是针对实现编程。 　　传递参数，或者在组合聚合关系中，尽量引用层次高的类。 　　主要是在构造对象时可以动态的创建各种具体对象，当然如果一些具体类比较稳定，就不必在弄一个抽象类做它的父类，这样有画蛇添足的感觉。

     开闭原则的主要机制就是依赖倒转原则，这个原则的内容是：要依赖于抽象，不要依赖于具体，即要针对接口编程，不针对实现编程。　　

     依赖也就是耦合，共分为下面3种。　　

     零耦合（Nil Coupling）关系：两个类没有依赖关系。　　

     具体耦合（Concrete Coupling）关系：两个具体的类之间有依赖关系，如果一个具体类直接引用另外一个具体类，就是这种关系。　　

     抽象耦合（Abstract Coupling）关系：这种关系发生在一个具体类和一个抽象类之间，这样就使必须发生关系的类之间保持最大的灵活性。　　

     依赖倒转原则要求客户端依赖于抽象耦合，抽象不应当依赖于细节，细节应当依赖于抽象。这个原则的另外一个表述就是：要针对接口编程，不要对实现编程。程序在需要引用一个对象时，应当尽可能地使用抽象类型作为变量的静态类型，这就是针对接口编程的含义。依赖倒转原则是达到开闭原则的途径。　　

     要做到依赖倒转原则，使用抽象方式耦合是关键。由于一个抽象耦合总要涉及具体类从抽象类继承，并且需要保证在任何引用到某类的地方都可以改换成其子类，因此，里氏代换原则是依赖倒转原则的基础，依赖倒转原则是OOD的核心原则，设计模式的研究和应用都是用它作为指导原则的。

 

接口隔离原则

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

           使用多个专门的接口比使用单一的总接口要好。　　

          一个类对另外一个类的依赖性应当是建立在最小的接口上的。　　

          一个接口代表一个角色，不应当将不同的角色都交给一个接口。没有关系的接口合并在一起，形成一个臃肿的大接口，这是对角色和接口的污染。

 

抽象类

 

　　抽象类不会有实例，一般作为父类为子类继承，一般包含这个系的共同属性和方法。 　　注意：好的继承关系中，只有叶节点是具体类，其他节点应该都是抽象类，也就是说具体类 　　是不被继承的。将尽可能多的共同代码放到抽象类中。

 

迪米特法则

 

　　  最少知识原则，就是说一个对象应当对其他对象有尽可能少的了解。不要和陌生人说话。

       迪米特法则的初衷在于降低类之间的耦合。由于每个类尽量减少对其他类的依赖，因此，很容易使得系统的功能模块功能独立，相互之间不存在（或很少有）依赖关系。　　

　　 迪米特法则不希望类直接建立直接的接触。如果真的有需要建立联系，也希望能通过它的友元类来转达。因此，应用迪米特法则有可能造成的一个后果就是：系统中存在大量的中介类，这些类之所以存在完全是为了传递类之间的相互调用关系——这在一定程度上增加了系统的复杂度。外观模式（Facade）和中介模式（Mediator），都是迪米特法则应用的例子。