软件工程07_设计优化.pptxVIP

;小规模设计;较差的系统和设计;设计结构的优化;设计的基本原则;接口隔离原则;接口类IManeuverable是具体交通工具的抽象，提供了驾驶的接口，如加减速、转弯 类Client在使用（drive）交通工具时，使用的不是具体类，而是其接口类 好处就是当业务需求变化时，更容易发生改变的是具体类，而这些变更可以通过稳定的抽象类进行隔离，使得Client不受变化的影响，从而提高了系统的可维护性。;如果系统中还存在另一类使用者，比如维修者，则他们专注的应该是这些交通工具的运转，而与驾驶相关的操作是不应该暴露给这些维修者类。;面向接口的作用;依赖倒置原则;开放封闭原则;;;Liskov替换原则;单一职责原则;如果有n个变化方向，每个变化方向上有m个变化点呢？ 而且很多子类存在浪费，如果用户在此变化点上根本没有需求！;如何应对这样的状况？答案就是拆分变化！如例子中所示，将Modem拆分成了两个抽象类Connection和DataChannel。 拆分后设计并未结束，两个拆分的抽象类肯定不是也不应该独立存在，下一步的设计？ 单一职责原则要求的条件是比较苛刻的，一个类真的要做到只能有一个功能而一点儿其它功能也不能具有？答案同样是否定的。 多个功能在一个类中是可以同时存在的，但这里有个前提：是否能够成为变化的方向。 如果成为单独的变化方向，则应该按照SRP进行类职责的拆分，否则可以保留功能共存（装饰模式） 。 ;合成/聚合复用原则;;;继承的使用;设计原则的应用;;另外一种改进的方法，正如聚集关系中一个对象本身不能直接处理的信息可由一个实例变量委托至另外一个对象进行处理。 这时几个对象交互的流程可如上页下图所描述，图中假设第i个项目任务为pa。 这种方法的好处是每个类只需了解与其本身相关的子任务，避免了不得不去了解其它所有类的情况。 在这个具体示例中的主要要求就是类的功能应尽量在一个类中进行实现，使得类不需要了解更多的信息就能够完成该项工作，也就降低了类与类之间的耦合程度，遵守了单一职责的原则。 ;;存在一个游戏控制类“Game”，其中有一个多米诺牌类型的实例变量middle用来记录当前可以连接的左右牌值，也就是???牌位middle含有所有已出牌的左侧和右侧的值。 一种可能实现是出牌的时候向Game对象传递该骨牌对象并判断是否此牌可以在首或尾放置。 对应的java实现如下所示： 这种方法之所以不好是因为Game类型的对象需要深入到多米诺牌对象的内部去以获得其需要的核心信息。;更干净的一种实现方法，是由牌对象本身进行验证是否另外一个牌对象可以放置在其旁边。 对多米诺牌的上述实现能够避免在Game类或其它的使用类中对放置位置的判断被重复实现多次。 以上代码中两个不同类的一个方法具有相同的签名，类Game的isPlaceable()函数通过对Domino类的isPlaceable()函数调用完成，这种情况也应尽量避免。一个具有面向对象特点的程序设计方式是使用动态方法的多态特性。 ;多态的基本思想是对于每个变量仔细衡量，在保证业务成功执行的前提下，保持最小可能的类型定义。 多态性在结构上其实就是形成类的继承层次，比如类B从类A继承，类C从类B继承，在对具体变量进行使用的时候，根据需要可以将某个变量定义为根类型A就足够了。 这时此变量对应的实际类型可能为类C，按照类型A来使用的话，则只有A中的方法是可用的，当然A中方法的具体行为是可以在C中重写的（overriding），在重写的过程中需要注意不能违背了liskov替换原则。;对于重写的具体含义有： 重写的方法本质上与父类方法具有相似的行为，但在细节上进行了有针对性的调整。 重写的方法与原方法在相同的条件作用下工作，子类的方法不应有比其父类更严格的条件限制。 重写的方法最高不能超出父类方法的状态。 根据以上的要求，如果一个方法的输入要求的范围是1-10之间的所有数字，返回的结果范围为40-60之间，则一个对其进行重写的方法的输入范围需要包含原输入区间，如-10和10；结果输出区间应是原输出区间的子集，如43-55。 ;与C++中方法的声明部分可以直接指定构造函数的默认值不同，在Java中是不允许这种方式的。 因此在Java中或者把三种构造情况都写出来（对应三个构造函数），或者使用Java版本5以后提供的可变长列表的类型。;如果已经存在某个可用的类，但是该类不具有所有需要的功能，为了达到需求需要对该类进行功能的补充，这也涉及到对现有类的重构。一般有两种方法可以作为调整类设计的合理参考： 第一种方式是借助继承的方式。从已有类继承新类，在新类补充新功能的方法，并与父类提供的方法一起完成所有需要的功能。这种方式适合已有的类是自己开发完成的，或者是基于一个框架系统（见第8章）的开发。 第二种方法是通过委托（De