对于OO设计，主要是要求系统的设计结果要能适应系统新的需求变化，一旦需求发生变化，整个系统不用做变动或做很少的变动就可以满足新的需求。OO设计的几条原则：◎开闭原则（Open/ClosedPrinciple，OCP）◎Liskov替换原则（LiskovSubstitutioPrinciple，LSP）◎依赖倒置原则（DependencyInversionPrinciple，DIP）◎接口分离原则（InterfaceSegregationPrinciple，ISP）一、开闭原则开闭原则指的是一个模块在扩展性方面应该是开放的，而在更改性方面应该是封闭的。这个原则说的是，在写模块的时候，应该尽量使得模块可以扩展，并且在扩展时不需要对模块的源代码进行修改。开闭原则最初是由BertrandMeyer提出来的［Mey88］，在所有的OO设计原则中，这个原则可能是最重要的。为了达到开闭原则的要求，在设计时要有意识地使用接口进行封装，采用抽象机制，并利用OO中的多态技术。考虑如下图的设计：Hp类、Epson类、Canon类分别表示不同类型的打印机，Output类与这3个类都有关联。系统运行时，Output类根据当前与系统相连的是哪种类型的打印机而分别使用不同类中的print（）方法。显然在Output类中会有复杂的if...else（或switch...case）之类的分支结构来判断当前与系统相连的是哪种类型的打印机。这是一种不好的设计，因为如果将来系统要增加一种新的打印机类型，例如Legend打印机，则不但要增加一个新的Legend类，还要修改Output类的内部结构。图1的设计不符合OO设计的开闭原则。如图2所示是改进的设计。图2中引入了接口Printer，其中有一个方法print（）。现在Output类只与接口Printer关联，在Output中有类型为Printer的变量p。不管系统与哪种类型的打印机相连，输出时都调用p.print（）方法。而p的具体类型在运行时由系统确定，可能是Hp类型的对象，也可能是Epson类型的对象或Canon类型的对象。现在Output类中不再有if...else（或Switch...case）之类的分支结构，而且，如果系统要增加新的打印机类型，如Legend打印机，则只需增加Legend类，并且让Legend类实现Printer接口即可，而类Output内部不需要做任何改动。因此，图2的设计具有较好的可扩展性。图2打印输出的设计2二、Liskov替换原则Liskov替换原则最早是由Liskov于1987年在OOPSLA会议上提出来的［Lis88］，这个原则指的是子类可以替换父类出现在父类能出现的任何地方。如图3所示是Liskov替换原则的图示说明。图3Liskov替换原则的图示说明类ClassA要使用ClassB，ClassC是ClassB的子类。如果在运行时，用ClassC代替ClassB，则ClassA仍然可以使用原来ClassB中提供的方法，而不需要做任何改动。利用Liskov替换原则，在设计时可以把ClassB设计为抽象类（或接口）。让ClassC继承抽象类（或实现接口），而ClassA只与ClassB交互，运行时ClassC会替换ClassB。这样可以保证系统有较好的可扩展性，同时又不需要对ClassA做修改。三、依赖倒置原则依赖倒置原则指的是依赖关系应该是尽量依赖接口（或抽象类），而不是依赖于具体类。为了说明依赖倒置原则，先看结构化设计中的依赖关系。如图4所示。图4结构化设计中的依赖关系在结构化设计中，高层的模块依赖于低层的模块。图4中，主程序会依赖于模块1、模块2、模块3，而模块1又依赖于模块11、模块12，等等。在结构化设计中，越是低层的模块，越跟实现细节有关，越是高层的模块越抽象，但高层的模块往往是通过调用低层的模块实现的。也就是说，抽象的模块要依赖于与具体实现有关的模块，显然这是一种不好的依赖关系。在面向对象的设计中，依赖关系正好是相反的，即与具体实现有关的类是依赖于抽象类或接口，其依赖关系的结构一般如图5所示。图5面向对象设计中的依赖关系在面向对象设计中，高层的类往往与领域的业务有关，这些类只依赖于一些抽象的类或接口，而与具体实现有关的类，如ContreteClass1、ContreteClass2等也只与抽象类和接口有关。当具体的实现细节改变时，不会对高层的类产生影响。需要说明的是，从语义上理解，关联关系、实现关系、泛化关系都是依赖关系。所以在图5中就以具体的关联、实现、泛化关系表示，而不是用虚线加箭头表示各个类之间的依赖关系。四、接口分离原则接口分离原则指的是在设计时采用多个与特定客户类（Client）有关的接口比采用一个通用的接口要