设计模式课件-1.概述概要.ppt

应用业务代理类的主要的目的是降低客户端与业务组件之间的紧密关联性和提高业务功能组件类的安全性 * 应该在两个模块之间定义一个抽象接口，上层模块调用抽象接口中定义的方法，下层模块实现该接口的方法 * 它指导我们如何正确地进行接口设计! 谨用继承！ 过于臃肿的接口设计是对接口的污染 接口的污染（Interface Contamination） 一个没有经验的设计师往往想节省接口的数目，将一些功能相近或功能相关的接口合并 所谓接口污染就是为接口添加了不必要的职责 如果开发人员在接口中增加一个新的功能方法的主要目的只是为了减少接口的实现类的数目，如此设计将导致接口被不断地“污染”并“变胖”。 * 软件系统中类的设计是否合理不在乎类本身的数目 接口污染会给系统带来维护和重用等方面的问题。 为了能够重用被污染的接口，接口的实现类就被迫要实现并维护不必要的功能方法。 使用接口的多重继承实现对不同的接口的组合，从而对外提供组合功能——达到“按需提供服务”。 * 在迪米特法则中，对于一个对象，其朋友包括以下几类： (1) 当前对象本身(this)； (2) 以参数形式传入到当前对象方法中的对象； (3) 当前对象的成员对象； (4) 如果当前对象的成员对象是一个集合，那么集合中的元素也都是朋友； (5) 当前对象所创建的对象 * 遵守单一职责原则的设计模式 工厂模式 分离对象的“创建”和对象的“使用” 遵守单一职责原则的设计模式 模板方法模式 分离 “共性功能实现”和“个性扩展” 遵守单一职责原则的设计模式 命令模式 分离“命令的请求者”和“命令的实现者” 遵守单一职责原则的设计模式 代理模式 分离 “服务的请求者”和“服务的提供者” 遵守单一职责原则的体系结构模式 一个模块、子系统也应该仅有一个引起它变化的原因 开闭原则 Open(Open for extension) 模块的行为必须是开放的、支持扩展的，而不是僵化的 Closed(Closed for modification) 在对模块的功能进行扩展时，不应该影响或大规模地影响已有的程序模块 绝大部分的设计模式都符合开闭原则 抽象化是开闭原则的关键 要求开发人员可以在不修改系统中现有的功能代码的前提下，而实现对应用系统的软件功能进行扩展 里氏代换原则 主要是针对继承的设计原则 子类型必须能够替换掉它们的父类型、并出现在父类能够出现的任何地方。 子类可以扩展父类的功能，但不能改变父类原有的功能。 里氏替换原则 子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法。 子类中可以增加自己特有的方法。 当子类的方法重载父类的方法时，方法的前置条件（即方法的形参）要比父类方法的输入参数更宽松。 当子类的方法实现父类的抽象方法时，方法的后置条件（即方法的返回值）要比父类更严格。 依赖倒置原则 将依赖关系倒置为依赖接口 上层模块不应该依赖于下层模块，它们共同依赖于一个抽象 父类不能依赖子类，它们都要依赖抽象类 抽象不能依赖于具体，具体应该要依赖于抽象 接口隔离 一个类对另外一个类的依赖性应当是建立在最小的接口上 客户端不应该依赖那些它不需要的接口（方法） 接口的污染！！！ 如何避免不良好的接口设计 用多个专门的接口，而不使用单一的总接口。 一个接口就只代表一个角色 使用接口隔离原则拆分接口时，首先必须满足单一职责原则 合成复用原则 又称为组合/聚合复用原则 尽量使用对象组合，而不是继承来达到复用目的 一个新的对象里通过关联关系（包括组合关系和聚合关系）来使用一些已有的对象 新对象通过委派调用已有对象的方法达到复用其已有功能的目的 简言之：要尽量使用组合/聚合关系，少用继承！ ？？？ 合成复用原则 继承复用：实现简单，易于扩展，没有足够的灵活性（“白箱”复用 ） 合成复用原则 组合/聚合复用：耦合度相对较低，选择性地调用成员对象的操作；可以在运行时动态进行。（“黑箱”复用 ） 迪米特法则 要求一个软件实体应当尽可能少的与其他实体发生相互作用 又称为最少知识原则 不要和“陌生人”说话 只与你的直接朋友通信 每一个软件单位对其他的单位都只有最少的知识，而且局限于那些与本单位密切相关的软件单位 创建松耦合的类 迪米特法则 某系统界面类(如Form1、Form2等类)与数据访问类(如DAO1、DAO2等类)之间的调用关系较为复杂，如图所示： 迪米特法则 如果其中的一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用 好设计的原则 单一职责原则要求在软件系统中，一个类只负责一个功能领域中的相应职责。 开闭原则要求一个软件实体应当对扩展开放，对修改关闭，即在不修改源代码的基础上扩展一个系统的行为。 里氏代换原则可以通俗表述为在软件中如果能够使用基类对象，那么一定能够使用其