设计模式在企业开发中的应用ppt课件.pptVIP

设计模式在企业开发中的应用 领先源于专业 效果来自实力 1 目标 深刻理解面向对象思想理解面向对象的设计原则掌握常用的设计模式掌握设计模式的正确使用 2 内容提要 1什么是面向对象2面向对象的设计原则3常用设计模式及其应用示例 3 一 什么是面向对象 1 1面向对象的世界观1 2面向对象的方法论1 3面向对象的特征 4 1 1面向对象的世界观 面向对象的基本哲学是认为世界是由各种各样具有自己的运动规律和内部状态的对象所组成的 不同对象之间的相互作用和通讯构成了完整的现实世界 因此 人们应当按照现实世界这个本来面貌来理解世界 直接通过对象及其相互关系来反映世界 这样建立起来的系统才能符合现实世界的本来面目 5 1 2面向对象的方法论 面向对象的方法是面向对象的世界观在开发方法中的直接运用 它强调系统的结构应该直接与现实世界的结构相对应 应该围绕现实世界中的对象来构造系统 而不是围绕功能来构造系统 6 1 3面向对象的特征 封装继承多态 7 1 3面向对象的特征 封装每个对象都包含它能进行操作所需要的所有信息 这个特性被称为封装 因此对象不必依赖其他对象来完成自己的操作 封装的好处良好的封装能减少耦合 类内部的实现可以自由的修改 类具有清晰的对外接口 8 1 3面向对象的特征 继承对象的继承代表了一种 is a 的关系 如果两个对象A和B 可以描述为B是A 则表明B可以继承A 继承者还可以理解为是对被继承者的特殊化 因为它除了具备继承者的特性外 还具备自己独有的个性 继承的特点子类拥有父类非privite得属性和方法 子类具有自己的属性和功能 即子类可以扩展父类没有的属性和功能 子类还可以以自己的方式实现父类的功能 方法重写 9 1 3面向对象的特征 多态多态表示不同的对象可以执行相同的动作 但需要通过他们自己的实现代码来执行 使用多态需要注意子类以父类的身份出现子类在工作时以自己的方式来实现子类以父类的身份出现时 子类特有的属性和方法不可以使用 为了使子类的实例完全接替来自父类的成员 父类必须将其成员声明为虚拟的 virtual 子类可以通过override来重写父类的方法 10 活字印刷 面向对象 为什么印刷术不是四大发明之一 而活字印刷是四大发明之一呢 11 2面向对象的设计原则 2 1单一职责原则2 2开放封闭原则2 3依赖倒置原则2 4Liskov替换原则2 5接口隔离原则2 6迪米特法则 12 2 1单一职责原则 单一职责原则的核心思想为 一个类 最好只做一件事 只有一个引起它的变化 单一职责原则可以看做是低耦合 高内聚在面向对象原则上的引申 将职责定义为引起变化的原因 以提高内聚性来减少引起变化的原因 职责过多 可能引起它变化的原因就越多 这将导致职责依赖 相互之间就产生影响 从而大大损伤其内聚性和耦合度 通常意义下的单一职责 就是指只有一种单一功能 不要为类实现过多的功能点 以保证实体只有一个引起它变化的原因 13 2 1单一职责原则 示例一 RBAC 基于角色的权限控制 应用设计示例二 电话示例 14 示例一 15 示例二 16 2 1单一职责原则 单一职责的好处类的复杂性降低 实现什么职责都有清晰明确的定义可读性提高 复杂性降低 那当然可读性提高了可维护性提高 那当然了 可读性提高 那当然更容易维护了变更引起的风险降低 变更是必不可少的 如果接口的单一职责做得好 一个接口修改只对相应的实现类有影响 对其他的接口无影响 这对系统的扩展性 维护性都有非常大帮助 17 2 2开放封闭原则 开放封闭原则的核心思想是 软件实体应该是可扩展的 而不是可修改的 也就是 对扩展开放 对修改封闭的 开放封闭原则主要体现在两个方面 1 对扩展开放 意味着有新的需求或变化时 可以对现有代码进行扩展 以适应新的情况 2 对修改封闭 意味着类一旦设计完成 就可以独立完成其工作 而不要对其进行任何的修改 实现开放封闭原则的核心思想就是对抽象编程 而不对具体编程 因为抽象相对稳定 让类依赖于固定的抽象 所以修改就是封闭的 而通过面向对象的继承和多态机制 又可以实现对抽象类的继承 通过覆写其方法来改变固有行为 实现新的拓展方法 所以就是开放的 需求总是变化 没有不变的软件 所以就需要用封闭开放原则来封闭变化满足需求 同时还能保持软件内部的封装体系稳定 不被需求的变化影响 18 2 2开放封闭原则 在做任何系统时 都不能指望需求在一开始就完全确定 怎样的设计才能面对需求的改变却可以保持相对稳定 从而使得系统可以在第一个版本以后不断推出新的版本呢 开放 封闭原则就是这个问题的答案 软件设计要容易维护又不容易出问题的最好方法就是多扩展 少修改绝对的对修改关闭是不可能的 无论模块是多么的 封闭 都会存在一些无法对之封闭的变化 既然不可能完全封闭 设计人员必须对于他设计的模块应该对哪种变化封闭作出选择 他必须先猜测出最有可能发生的变化种类 然后构造抽象来隔离那些变化 19 2 2开放封闭原则 对修改封闭原则的应用示例 定义1boolConnect stringuserName stringpassword stringftpAddress intport 定义2boolConnect Accountaccount publicclassAccount publicstringUserName get set publicstringPassword get set publicstringFtpAddress get set publicstringintPort get set 一般的设计原则强调方法参数尽量避免基本类型 20 2 2开放封闭原则 对扩展开放的应用示例 排序 21 2 3依赖倒置原则 依赖倒置原则的核心思想是 依赖于抽象 具体而言就是高层模块不依赖于底层模块 二者都同依赖于抽象 抽象不依赖于具体 具体依赖于抽象 依赖一定会存在于类与类 模块与模块之间 当两个模块之间存在紧密的耦合关系时 最好的方法就是分离接口和实现 在依赖之间定义一个抽象的接口使得高层模块调用接口 而底层模块实现接口的定义 以此来有效控制耦合关系 达到依赖于抽象的设计目标 抽象的稳定性决定了系统的稳定性 因为抽象是不变的 依赖于抽象是面向对象设计的精髓 也是依赖倒置原则的核心 依赖于抽象是一个通用的原则 而某些时候依赖于细节则是在所难免的 必须权衡在抽象和具体之间的取舍 方法不是一层不变的 依赖于抽象 就是对接口编程 不要对实现编程 22 2 3依赖倒置原则 示例 一个拿C照的司机能够开Benz小车一个拿C照的司机能够开BMW小车一个拿A照的司机 23 2 3依赖倒置原则 系统的三层架构示例 24 2 4Liskov替换原则 里氏替换原则的核心思想是 子类必须能够替换其基类 这一思想体现为对继承机制的约束规范 只有子类能够替换基类时 才能保证系统在运行期内识别子类 这是保证继承复用的基础 在父类和子类的具体行为中 必须严格把握继承层次中的关系和特征 将基类替换为子类 程序的行为不会发生任何变化 同时 这一约束反过来则是不成立的 子类可以替换基类 但是基类不一定能替换子类 Liskov替换原则 主要着眼于对抽象和多态建立在继承的基础上 因此只有遵循了Liskov替换原则 才能保证继承复用是可靠地 实现的方法是面向接口编程 将公共部分抽象为基类接口或抽象类 通过ExtractAbstractClass 在子类中通过覆写父类的方法实现新的方式支持同样的职责 Liskov替换原则是关于继承机制的设计原则 违反了Liskov替换原则就必然导致违反开放封闭原则 Liskov替换原则能够保证系统具有良好的拓展性 同时实现基于多态的抽象机制 能够减少代码冗余 避免运行期的类型判别 25 2 4Liskov替换原则 里氏替换原则的经典问题 正方形不是长方形鸵鸟非鸟 26 2 5接口隔离原则 接口隔离原则的核心思想是 使用多个小的专门的接口 而不要使用一个大的总接口 接口隔离原则体现在 接口应该是内聚的 应该避免 胖 接口 一个类对另外一个类的依赖应该建立在最小的接口上 不要强迫依赖不用的方法 这是一种接口污染 接口隔离强调接口的单一性 而胖接口存在明显的弊端 会导致实现的类型必须完全实现接口的所有方法 属性等 而某些时候 实现类型并非需要所有的接口定义 在设计上这是 浪费 而且在实施上这会带来潜在的问题 对胖接口的修改将导致一连串的客户端程序需要修改 有时候这是一种灾难 在这种情况下 将胖接口分解为多个特点的定制化方法 使得客户端仅仅依赖于它们的实际调用的方法 从而解除了客户端不会依赖于它们不用的方法 分离的手段主要有以下两种 1 委托分离 通过增加一个新的类型来委托客户的请求 隔离客户和接口的直接依赖 但是会增加系统的开销 2 多重继承分离 通过接口多继承来实现客户的需求 这种方式是较好的 27 2 5接口隔离原则 28 2 5接口隔离原则 使用接口隔离原则应该要注意 接口尽量小 但是要有限度 对接口进行细化可以提高程序设计灵活性是不挣的事实 但是如果过小 则会造成接口数量过多 使设计复杂化 所以一定要适度 为依赖接口的类定制服务 只暴露给调用的类它需要的方法 它不需要的方法则隐藏起来 只有专注地为一个模块提供定制服务 才能建立最小的依赖关系 提高内聚 减少对外交互 使接口用最少的方法去完成最多的事情 运用接口隔离原则 一定要适度 29 2 6迪米特法则 迪米特法则 LawofDemeter 又叫作最少知识原则 LeastKnowledgePrinciple简写LKP 就是说一个对象应当对其他对象有尽可能少的了解 不和陌生人说话 英文简写为 LoD 30 3常用设计模式及其应用示例 3 1设计模式的分类3 2单例模式3 3简单工厂模式3 4工厂模式3 5策略模式3 6代理模式3 7观察者模式3 8门面模式 31 3 1设计模式的分类 创建型 创建对象时 不再由我们直接实例化对象 而是根据特定场景 由程序来确定创建对象的方式 从而保证更大的性能 更好的架构优势 创建型模式主要有简单工厂模式 并不是23种设计模式之一 工厂方法 抽象工厂模式 单例模式 生成器模式和原型模式 32 3 1设计模式的分类 结构型用于帮助将多个对象组织成更大的结构 结构型模式主要有适配器模式 桥接模式 组合器模式 装饰器模式 门面模式 亨元模式和代理模式 33 3 1设计模式的分类 行为性用于帮助系统间各对象的通信 以及如何控制复杂系统中流程 行为型模式主要有命令模式 解释器模式 迭代器模式 中介者模式 备忘录模式 观察者模式 状态模式 策略模式 模板模式和访问者模式 34 3 2单例模式 有些时候 允许自由创建某个类的实例没有意义 还可能造成系统性能下降 如果一个类始终只能创建一个实例 则这个类被称为单例类 这种模式就被称为单例模式 单例模式的特点单例类只能有一个实例单例类必须自己创建自己的唯一实例单例类必须给所有其它对象提供这一实例 35 3 2单例模式 单例模式类图 36 3 2单例模式 单例模式的常见应用场景Windows的TaskManager 任务管理器 windows的RecycleBin 回收站 网站的计数器 一般也是采用单例模式实现 否则难以同步应用程序的日志应用 一般都何用单例模式实现 这一般是由于共享的日志文件一直处于打开状态 因为只能有一个实例去操作 否则内容不好追加Web应用的配置对象的读取 一般也应用单例模式 这个是由于配置文件是共享的资源HttpApplication也是单位例的典型应用 37 3 2单例模式 一个单例模式应用的例子 常用的交流软件QQ 只能打开一个与某个人聊天的窗口 38 3 2单例模式 单例模式应用场景 资源共享的情况下 避免由于资源操作时导致的性能或损耗等控制资源的情况下 方便资源之间的互相通信 如线程池等 39 3 3简单工厂模式 经典问题 编写一个计算器 能够计算加减乘除运算 40 3 3简单工厂模式 从设计模式的类型上来说 简单工厂模式是属于创建型模式 又叫做静态工厂方法 StaticFactoryMethod 模式 但不属于23种GOF设计模式之一 简单工厂模式是由一个工厂对象决定创建出哪一种产品类的实例 简单工厂模式是工厂模式家族中最简单实用的模式 可以理解为是不同工厂模式的一个特殊实现 41 3 3简单工厂模式 简单工厂模式包含的角色以及职责 工厂 Creator 角色 简单工厂模式的核心 它负责实现创建所有实例的内部逻辑 工厂类可以被外界直接调用 创建所需的产品对象 抽象产品 Product 角色 简单工厂模式所创建的所有对象的父类 它负责描述所有实例所共有的公共接口具体产品 ConcreteProduct 角色 是简单工厂模式的创建目标 所有创建的对象都是充当这个角色的某个具体类的实例 42 3 3简单工厂模式 简单工厂模式应用示例 聊天软件对信息的处理 43 3 3简单工厂模式 简单工厂模式的优缺点 优点 工厂类是整个模式的关键 包含了必要的逻辑判断 根据外界给定的信息 决定究竟应该创建哪个具体类的对象 通过使用工厂类 外界可以从直接创建具体产品对象的尴尬局面摆脱出来 仅仅需要负责 消费 对象就可以了 而不必管这些对象究竟如何创建及如何组织的 明确了各自的职责和权利 有利于整个软件体系结构的优化 44 3 3简单工厂模式 缺点 由于工厂类集中了所有实例的创建逻辑 违反了高内聚责任分配原则 将全部创建逻辑集中到了一个工厂类中 它所能创建的类只能是事先考虑到的 如果需要添加新的类 则就需要改变工厂类了 当系统中的具体产品类不断增多时候 可能会出现要求工厂类根据不同条件创建不同实例的需求 这种对条件的判断和对具体产品类型的判断交错在一起 很难避免模块功能的蔓延 对系统的维护和扩展非常不利 45 3 3简单工厂模式 简单工厂模式的应用场景 工厂类负责创建的对象比较少 客户只知道传入工厂类的参数 对于如何创建对象 逻辑 不关心 由于简单工厂很容易违反高内聚责任分配原则 因此一般只在很简单的情况下应用 对于简单工厂模式的缺点 可以在工厂模式中得到克服 46 3 4工厂模式 将计算器程序改为工厂模式实现 47 3 4工厂模式 工厂模式的角色以及职责抽象工厂 Factory 角色 是工厂方法模式的核心 与应用程序无关 任何在模式中创建的对象的工厂类必须实现这个接口 具体工厂 ConcreteCreator 角色 这是实现抽象工厂接口的具体工厂类 包含与应用程序密切相关的逻辑 并且受到应用程序调用以创建产品对象 抽象产品 Product 角色 工厂方法模式所创建的对象的超类型 也就是产品对象的共同父类或共同拥有的接口 具体产品 ConcreteProduct 角色 这个角色实现了抽象产品角色所定义的接口 某具体产品有专门的具体工厂创建 它们之间往往一一对应 48 3 4工厂模式 工厂模式VS简单工厂简单工厂最大的优点在于在工厂中存在必要的逻辑判断 可以根据客户端选择的条件动态的实例化相关的类 去除了客户端对具体产品的依赖 但是却违背了 开放 封闭 原则 工厂模式在实现的时候 客户端需要决定实例化那一个类 选择判断的问题依旧存在 但是工厂模式将简单工厂中在工厂中的判断放在了客户端来进行 49 3 4工厂模式 最佳实践 利用反射利用反射可以去除客户端的逻辑判断 50 3 5策略模式 案例 商场的会员卡制度 商场的会员卡有银卡 金卡 白金卡等级别 而不同的会员卡在消费时可以享受不同的折扣 51 3 5策略模式 策略模式用于封装系列的算法 这些算法通常被封装在一个被称为Context的类中 客户端程序可以自由选择其中一种算法 或让Context为客户端选择一种最佳算法 使用策略模式的优势是为了支持算法的自由切换 52 3 5策略模式 53 3 5策略模式 策略模式的角色以及职责 环境 Context 角色 持有一个Strategy类的引用 抽象策略 Strategy 角色 这是一个抽象角色 通常由一个接口或抽象类实现 此角色给出所有的具体策略类所需的接口 具体策略 ConcreteStrategy 角色 包装了相关的算法或行为 54 3 5策略模式 策略模式与简单工厂模式结合使用 55 3 5策略模式 策略模式中使用反射 56 3 6代理模式 代理模式是一种应用非常广泛的设计模式 当客户端代码需要调用某个对象时 客户端实际上不关心是否准确得到该对象 它只要一个能提供该功能的对象即可 此时我们就可返回该对象的代理 Proxy