第七讲信息系统设计学习课件.pptVIP

(3)低耦合度模式 问题：如何支持低依赖关系和增加重用？ 解决方案：在分配一个职责时要保持低耦合 耦合度是一个类与其他类关联、知道其他类的信息或者依赖其他类的强弱程度的度量，一个具有高耦合度的类存在以下弱点： 其他类定义的改变会迫使这个类改变其自身的局部定义 难以孤立地理解它，必须联系其他类的定义 难以重用，因为要使用这个类的话，还需要它所依赖的其他类也同时存在 高耦合度的模型 举例：归还一本书时，首先请求ResouceItem对象的归还操作，然后记录Loan的归还日期，假设存在逾期情况，则要创建Overdue对象 模型中，ResourceItem依赖了Overdue对象和Loan对象，而Overdue对象又需要和Loan对象建立关联，三者之间都存在耦合 低耦合度的选择（方案一） Loan对象与Overdue对象关联，由Loan创建 低耦合度的选择 :Register makePayment() :Sale :Payment 1: makePayment() 1.1: create() :Register makePayment() p:Payment :Sale 1: create() 2: addPayment(p) 销售完成后记录付款情况，模型如下： 显而易见， 方案二的耦合度要低一些 类型X有一个属性引用了类型Y的实例 类型X调用类型Y对象的服务 类型X有一个方法以各种方式引用了一个类型Y的实例，如方法的局部变量或参数引用了类型Y的实例，或返回一个类型Y的实例等 类型X是类型Y的一个直接的或间解的子类 类型Y是一个接口，类型X实现了这个接口 注意：不能脱离其他模式来孤立地考虑低耦合度，低耦合度适用于很通用的普通类和可重用性高的类 耦合度在OOP中的体现 问题：如何将复杂性保持在可控制范围内？ 解决方案：在分配一个职责时要保持类的高聚合度 聚合度是对一个类中的各个职责之间相关程度和集中程度的度量。一个具有低聚合度的类存在以下弱点： 难以理解 难以重用 难以维护 容易受到外界所发生的细微变化的影响 一个聚合度高的类所含的方法数通常很少，功能之间的关联程度强，并且所承担的工作量不是太大。 (4)高聚合度模式 (5)控制者模式 问题：谁来负责处理一个外部输入事件？ 解决方案：使用非用户界面类的控制者类来处理一个外部事件 控制者类有以下的选择： 代表整个“系统”的类（如Register） 代表整个企业或组织的类(如商店) 代表真实世界中参与职责的主动对象类（Actor,如出纳员） 代表一个用例中所有事件的虚拟处理者类（如购买商品处理者/退还商品处理者，它不是一个实体对象，而是一个人造的软件单元），可为每个用例建立一个这样的用例控制类 可以使用控制类处理一个用例中的所有的事件 使用用例控制类 可以使用ReturnLogic类协调还书过程 该消息可以由控制类发出。控制类可先通过ResourceItem对象获得Loan对象。 这样ResourceItem和Loan的耦合降低了 努力的方向 一口吃不成胖子 设计师不是学出来的，是练出来的 螺旋上升的规律 先体会OO思想 实践 代码修改，理解设计原则 模式的运用，再实践 再体会，然后才能成为自己的知识 * * 1 松耦合软件分成模块 大的软件都是由一个一个小模块组成的 小模块还可能再由更小的模块组成一个模块就是相互间联系紧密的变量与函数 或对象 不同模块间关系比较松散模块间关系越松散 这样修改一个模块时 对其它模块的影响就越小 这样可以把变化限制在一个模块内2 针对接口编程 而不是针对实现编程具体来说就是 你只要定义这个接口有什么功能 不用定义它是什么实现的当其它模块需要这个功能时 只要调用这个接口就可以 它不必了解你的实现机制当你换一个实现时 就不会同时修改其它模块3 继承 组合 委托与多态与参数化继承是有父子关系的对象的具体化组合就是把有相互关系的对象放在一起 由它们提供某一个或一组功能 这功能需要它们共同配合才能实现委托是一个对象把一个请求转交给另一个对象执行 相当歌手与经济人的关系 经济人是委托者 歌手是执行者多态就是实现的可替换性 你可以在运行时使用另一种实现来代替当前实现而不必修改代码参数化就是根据不同类型的参数提供不同的功能 如c++中的模板机制 如vector类 * 创建型模式与对象的创建有关 结构型模式处理对象或类的组合 行为型模式对类和对象怎样交互和怎样分配职责进行描述类模式处理类与子类的关系 对象模式处理对象间关系 * 创建型模式就是怎样构造一个对象的方法结构型模式就是怎样使用组合的方法行为型则是怎样分配类或对象的功能及怎样调用它们的算法类模式与类继承相关 对象模式与对象间关系相关 * 比如设计一个访问数据库的类，让它完