第5章-类图和对象图-4.ppt

5.9.1开闭原则□图5.28的设计：系统运行时，Output类根据当前与系统相连的是哪种类型的打印机而分别使用不同类的print()方法。如果增加新的Legend打印机不但要增加新的Legend类，还有修改Output类的内部结构。图5.28打印输出设计15.9.1开闭原则图5.29的改进设计：Output中有类型为Printer的变量p.不管与哪种打印机相连，输出都调用p.print()。P的具体类型在运行时由系统决定。如果增加Legend打印机只需增加Legend类，并让Legend类实现Printer接口即可，不需改动Output类内部。图5.29打印输出设计25.9.2Liskov替换原则□Liskov替换原则指的是子类可以替换父类出现在父类能出现的任何地方。图5.30：类A要使用类B，运行时，用类C代替类B，则类A仍可以使用原来类B的方法。设计时可以把ClassB设计为抽象类（或接口），让ClassC继承抽象类，而ClassA只与ClassB交互，运行时ClassC会替换ClassB,这样可以保证系统有较好的扩展性，又不需要对类A做修改。图5.30Liskov替换原则的图示说明5.9.3依赖倒置原则□依赖倒置原则指的是依赖关系应该是尽量依赖接口（或抽象类），而不是依赖于具体类。5.9.3依赖倒置原则图5.32面向对象设计中的依赖关系图5.31结构化设计中的依赖关系5.9.3依赖倒置原则□结构化设计中，越是底层模块，越跟实现细节有关，越是高层模块越抽象，但高层模块往往是通过调用底层实现的。也就是抽象的模块要依赖于与具体实现有关的模块，显然这是一种不好的依赖关系。图5.31结构化设计中的依赖关系5.9.3依赖倒置原则□在面向对象的设计中，与具体实现有关的类是依赖于抽象类或接口的。高层的类往往与领域的业务有关，只依赖于一些抽象类或接口。而与具体实现相关的类也只与抽象类或接口有关。当实现细节改变时，不影响高层的类。图5.32面向对象设计中的依赖关系5.9.4接口分离原则接口分离原则指的是在设计时，对于与多个特定客户类有关的接口，采用多个接口比采用一个通用的接口要好。5.9.4接口分离原则5.9.4接口分离原则采用通用接口的问题是，如果ClientA类需要改变所使用的Service接口中的方法，则不但需要改动Service接口和ServiceImp类，还要对ClientB类和ClientC类重新编译。即对ClientA类的修改会影响ClientB类和ClientC类。图5.33使用通用接口的设计5.9.4接口分离原则采用分离接口：每个客户类有一个专用接口，这个接口只声明了与这个客户类有关的方法，而ServiceImp类实现了所有接口。如果ClientA类需要改变所使用的接口中的方法，则只需改动ServiceA接口和ServiceImp类即可，对ClientB类和ClientC类不会影响。图5.33使用分离接口的设计5.9OO设计的原则-额外注意的问题①不同类中相似方法的名字应该相同。例如，对于输入/输出方法，不要在一个类中用input/output命名，在另一个类中用read/write命名。②遵守已有的约定俗成的习惯。例如，对类名、方法名、属性名的命名应遵守已有的约定，或者遵守开发机构中规定的命名方法。5.9OO设计的原则-额外注意的问题③尽量减少消息模式的数目。只要可能，就使消息具有一致的模式，以利于理解。例如，不要在一个消息中，其第一个参数表示消息发送者的URL地址，而在另一个消息中，是最后一个参数表示消息发送者的URL地址。④设计简单的类。类的职责要明确，不要在类中提供太多的服务，应该从类名就可以较容易地推断出类的用途。5.9OO设计的原则-额外注意的问题⑤泛化结构的深度要适当。类之间的泛化关系增加了类之间的耦合性。除非是在特殊情况下（如图形用户界面的类库），一般不要设计有很深层次的类的泛化关系。⑥定义简单的方法。一个类中的方法不应太复杂。如果一个方法太大，很可能就是这个方法包含的功能太多，而有些功能可能是不相关的。5.9OO设计的原则-额外注意的问题□评价设计质量的方法之一是观察它在一段时间内的易变性。一般好的设计变动轨迹如图5.35所示。图5.35设计变动轨迹***5.2.4依赖关系假设有两个元素X、Y，如果修改元素X的定义可能会导致对另一个元素Y的定义修改，则称元素Y依赖于元素X。如一个类向另一个类发送消息，或者一个类