软件架构设计基础——面向模式的分析设计与实现 PPT课件

1 软件架构设计基础面向模式的分析 设计与实现 2 纲要 模式介绍如何在分析中使用模式公共性 变化性分析 一种更好的设计范型如何通过公共性 变化性分析改善软件开发 3 主要内容 如何进行能够适应变化的设计这就要求 识别出那些具体的情况抽象出它们的公共性把每个变化性封装在一个类中我们不试图去预测变化 而是尽量能够更好的适应变化 试图预测变化常常会导致 分析麻痹 症 通过基于上下文设计 我们可以在进行细节设计时 不至于迷失 时刻了解全局 4 什么是模式 模式是在一个特定上下文中 针对一个不断出现的问题的最佳解决方案也可以把模式看作是对问题领域中实体 对象 之间关系的描述模式为我们提供了一种新的建模技术 封装行为上的变化强调设计中的即插即用能力关注开放 封闭原则可以建立并增强用于专业交流的语言 提升交流的效果和效率 5 两个木匠在探讨如何造一个柜子其中一个说 我们应该先向下切割 然后再45度向上切割 接着 再向下 然后再从另外一个方向向上 再向下 不停这样重复 直到完成 木匠行业中的一个模式示例 6 他们所讨论的就是燕尾槽 7 斜面接合 通常应用于相框 8 模式在各个层面都适用 分析 动机设计实现 燕尾槽斜面接合 结实 成本高不结实 成本低好看 防潮易于制作 适合于画框交织接合单面接合齿0 5寸长 0 445度切割 粘合寸深切割 9 关注细节 忽视全局 过于注重如何实现燕尾槽的细节 会致使我们忽视最开始为何需要燕尾槽的动机燕尾槽和斜面接合分别强调了 我们是需要一种美观又经久耐用 但是制作成本高的接合方式呢还是一种无需太结实 但是易于制作且成本低廉的接合方式 10 在增加功能时 问题会出现在哪里 代码编写中吗 集成中吗 哪个更严重一些 为何 11 为何需要学习模式 重用已有的 高质量的解决方案改进设计 使其易于修改开创一种新的面向对象设计范型一种有助于学习的通用术语我们会发现设计不是一个合成的过程 而是一个逐步分化的过程转向一种新的思考方式 12 三个层次的视图 概念层视图规格说明层视图实现层视图MartinFowler UMLDistilled 13 不同层次视图的区别 概念层 描述了你想要什么 不关心如何得到它需求通常在概念层进行描述 我们需要以 的方式处理请求 规格说明层 类的接口对象之间如何交互实现层 代码 14 看看这三样东西 拖把 扫帚 海绵 15 它们一样还是不同 谁认为它们是没有区别的 谁认为它们是有区别的 16 要视情况而定 从具体的物体角度出发 它们是不同的从概念角度出发 它们都是清洁工具 17 实际存在 清洁工具 这个东西吗 在现实世界中 是不存的 但是它在我们的思考中 作为一种抽象分类存在 清洁工具 是不存的 但是特定种类的清洁工具是存在的 18 抽象类 AbstractClass 表示一个概念 因此无法被实例化用来为表示实际实体的类定义接口 也就是说 如何定义如何与从抽象派生出来的对象进行交互 例如 清洁工具 就是拖把 扫帚和海绵的抽象类 19 建模视角 20 这是一个多态的例子 允许存在不同的行为向对象发消息时 无需知道确切的对象类型向对象发消息时 只需要知道其概念类型在上面的例子中 任何拥有拖把 扫帚或者海绵的对象只需知道它所拥有的是 清洁工具 即可 21 从不同的视图看对象 从实现层看 具有方法的数据从规格说明层看 契约的实现体从概念层看 具有职责的实体 22 封装 Encapsulation 通常会认为封装是对象层的东西 数据隐藏 其实 我们经常会看到可以使用封装隐藏一组类 比如 所有的派生类 抽象类和接口在本质上封装了其所有的派生类和实现 使用者根本无需知道它们的存在封装其实要隐藏的是决策和规则 那些容易变化的决策和规则 最好把每个这样的决策和规则封装在一个地方 23 封装和模式 在某种程度上 可以把模式看成是对如下东西进行封装的一种反映变体设计决策数量结构构造方法等等 24 一个简单的例子 消息处理系统 25 问题 我们要开发一个消息处理系统该系统会收到不同类型的消息基于消息的类型 需要不同的处理算法 26 初始方案 MessageProcessor负责实例化Message对象 Message对象来完成消息的处理逻辑 27 面临挑战 每当增加一种新的消息处理算法时 就得修改Message对象我们还可能会造成 GodObject 的问题 一个大的对象承担了太多的职责 GodObject 是违背面向对象原则的必需以过程化的方法完成所有的行为以后行为的变化会导致对代码的更改破坏了对象的封装性全局数据 过程化的代码 28 新需求 多种消息处理类型 我们需要处理两种不同类型的消息TYPE ATYPE B一种解决方案 methodprocessMessage 使用基于消息类型的switch语句进行判断 TYPE A 使用类型A的算法处理消息 break TYPE B 使用类型B的算法处理消息 break 29 使用继承进行特化 我们可以通过特化最初的Message对象来处理新的消息类型 30 这会导致重复和维护性方面的问题 如果再有新的变体 把它放在哪里呢 要么使用大量的switch语句 这会导致代码难以理解 要么过渡的特化 这同样会导致很多麻烦 这种方法把Type A和Type B耦合在一起 当前可能没有问题 但是存在很大隐患我们希望能够把变化封装起来 31 一个好一点的方案 通过抽象来解耦Type A和Type B的处理 32 同样会导致维护性方面的问题 如果再有新的变体 把它放在哪里呢 可以再次继承 但是会产生非常多的类 组合爆炸 级联继承导致很多耦合问题对变化的封装度弱 33 很可能出现的结果 34 看看GangofFour的建议 Gamma Helms Johnson VlissidesDesignPatterns ElementsofReusableObject OrientedDesign的 位作者 35 GangofFour给我们提供的指南 面向接口编程对象组合优于类继承发现设计中的变化 并把变化的概念封装起来发现变化 并用一个类来封装它把该类包含在另一个类中 以避免类继承中出现多个变体 36 发现变化 封装变化 识别出变化的行为定义一个类把变化封装起来 然后通过组合的方式把从该抽象类派生的具体类实例包含进来有助于概念解耦可以推迟决策性能开销小听起来像是 预先设计 但是完全可以以逐步演化的方式进行当出现新的需求时 再提取变化把这些不同的变化提放到自己的类中 37 Strategy模式 38 Strategy模式 因为当前处理东西的不同 或者客户要求不同 导致在不同的时间需要不同的行为GoF意图 定义一族算法 把它们分别封装起来 并使得它们可以互换 Strategy模式可以使得算法和使用该算法的客户独立变化 互不影响 39 Strategy模式 Strategy模式告诉我们如何识别出一组在概念上完成同样功能的规则在我们的例子中 识别出一种和规则的所有实现体交互的通用方式定义一个表达该交互方式的接口或者抽象类把规则的每个变体作为一个实现或者派生 40 Strategy模式 分析 设计与实现 在进行分析时 每当发现一个可变的业务规则 很可能就会需要Strategy模式如果我们知道要使用Strategy模式 那么该模式就会指导我们把变化的规则实现隐藏在一个接口后面在实现时 该模式可以为我们提供可 直接应用的经验 以理解不同实现的内涵模式其实是关于关系的 同样概念规则的不同实现 规则的使用者 41 UML表示 42 以Strategy为例来理解GoF的建议 1 发现变化 策略 并 2 封装变化 策略 3 对象组合优于类继承 Context包含了Strategy类型的对象 而不是让不同的变体从其派生 封装变化 43 具体规则的选择 之前 MessageProcessor要么必需得知道具体的消息类型 swtich 要么必需得知道该实例化那种Message 继承 现在 它只需去实例化合适的ProcessStrategy对象此时 可以使用配置文件 让Message类使用该配置文件自己去找到适合自己的ProcessStrategy对象 44 使用Factory的好处 使用factory 我们可以隐藏 封装 消息处理规则 MessageProcessor无需知道何时该使用哪种处理规则的细节具体消息类型 45 此时需求发生变化会怎样 如果出现了一种新的消息处理规则 我们只需 从ProcessStratey派生一个对应的新类修改Factory对象 更好的做法是更改配置文件 其他对象都无需更改 46 Strategy模式的价值 在概念上更加清晰每个对象处理一项功能 内聚性增强 不同行为之间更加独立 解耦 如果以后出现新的变体 比如 消息的路由方式 我们可以以一种可伸缩的方式进行处理 只需增加另外一种Strategy 47 需要这么复杂吗 如果有许多可变的东西会怎样呢 换句话说 除了消息处理规则外 还可以有如下可变的规则 不同的路由策略不同的合法性检测策略不同的重发策略 switch和继承是无法伸缩的 48 公共性 变化性分析Commonality VariabilityAnalysis CVA 49 公共性 变化性分析 JamesCoplien在其论文Multi paradigmDesignforC 中对公共性 变化性分析做了很多开创性的工作 在自然语言中 抽象指得是关注于一般化 撇掉特殊化 做抽象的过程就是强调共性 忽视无关细节的过程 抽象是一种最为重要的分析工具 免费下载 50 公共性 公共性分析是要寻找公共的元素 这些元素可以帮助我们理解为何一族成员其实是一样的 可以从如下两个方面寻找公共性 基于经验识别从分析中获得 抽象 公共性定义了领域中的基础概念 51 寻找公共性所面临的困难 我们通常是以数据为中心的常常会把对象看成是 智能数据 而不是一组相关行为的集合 52 变化性分析 变化性仅在给定一个公共性参考框架的前提下才有意义 它是公共性的具体变体 从架构的视角来看 公共性分析使得一个架构持久 变化性分析则使得架构可用 公共性 变化性分析是一个反复迭代和修正的过程 53 公共性 变化性分析练习 以一个全球性的电子商务系统需求为例 欧洲日期表示美国的计税规则加拿大的时间格式欧洲的增值税规则德国的运货费率法国的运货规定不同国家地址的合法性检查 美国最重70磅加拿大的运货规定美国的运货规定美国的电话号码格式欧洲的电话号码格式德国最重40公斤欧洲用欧元 美国用美元 等等 54 公共性 变化性分析Vs关系 公共性 变化性分析不涉及不同变体之间的关系在美国使用美元 在欧洲使用欧元 公共性 变化性分析不关心货币和国家之间的关系 美元和欧元都不是国家的变体 它们都是货币的变体 使用公共性 变化性分析 我们首先找出问题领域中出现的公共性和变化性 然后在识别其关系这种做法可以使得特定情形之间的耦合降至最低 55 公共性和变化性 州欧洲北美洲 电话号码格式欧洲美国 加拿大 最大重量德国 40公斤法国 无加拿大 无美国 70磅 国家法国德国加拿大美国 税费欧洲加拿大美国 货币美元加拿大元欧元 运货规定法国德国加拿大 日期格式yyyy mm dddd mm yyyymm dd yyyy 运货费率法国费率德国费率加拿大费率 地址有效性德国法国加拿大美国 56 关于公共性 变化性分析的一些提示 并非所有的公共性及其变体都是有用的 取决于问题领域本身 头脑风暴 经验 演化反馈 有些是关于应用时机的有些是关于实现方式的有些可能仅仅是属性值的不同公共性 变化性分析有助于思考的清晰 它只是一个起点 57 公共性 变化性分析与设计 在概念上相同的东西 通过公共性分析找到 可以成为抽象类或者接口从它们派生的具体类通过变化性分析获取 58 使用公共性 变化性分析来设计类结构 公共性分析 变化性分析 概念层视图 规格说明层视图 实现层视图 通过分析对象必须作什么 概念视图 来决定如何调用它们 规格说明视图 规格说明和概念视图间的关系 必需的接口规格说明和实现视图间的关系 如何实现接口问题 该接口需要多确定 实现这些类时 要确保API提供了解耦和实现所需要的足够信息 59 应用公共性 变化性分析 公共性 变化性分析告诉我们首先找出 那些不变的东西那些变化的东西的公共性定义类或者接口来表示这些公共性定义这些公共性的变体 特定情形 这项工作做完后 再来考虑这些类之间的相互关系规避耦合 封装具体实现考虑将来的变化 60 应用设计模式 大多数设计模式是关于问题领域实体之间的关系的模式为我们提供了一种发现变化 封装变化的方式 也就是 隔离变化这一点非常重要 因为 起初这些变化看出来没有造成多大的问题但是 它们组合起来就变得非常难以处理可以把模式看作是公共性 变化性分析的例证 61 分析矩阵AnalysisMatrix 62 处理变化点 案例研究 假设我们有如下一些需求 我们开发一个适用于 网和 网的综合短消息处理系统 所有的短消息都要进行合法性检查 安全性验证以及转发处理 但是 对于 网和 网的短消息来说 其合法性 安全性检查和转发策略是不同的 63 把需求分解成不同的情况 CASE1 C网短消息在收到C网的短消息时 使用C网的合法性检查规则 C网的安全性检查逻辑 C网的转发处理方法CASE2 G网短消息在收到G网的短消息时 使用G网的合法性检查规则 G网的安全性检查逻辑 G网的转发处理方法 64 设计 在设计之前 我们要对问题领域做一些分析我们希望能够发现会变化的东西 把它们封装起来当需求比较多时 分析矩阵 可以为我们提供帮助 分析矩阵 就是一个矩阵 其中每一列表示一种特定情况 每一行表示在这些情况中发现的概念可以从简单的需求出发 逐步构建该矩阵 65 从第一个开始 在收到C网的短消息时 使用C网的合法性检查规则 C网的安全性检查逻辑 C网的转发处理方法 需求 概念 一种情况 66 继续 在收到C网的短消息时 使用C网的合法性检查规则 C网的安全性检查逻辑 C网的转发处理方法 不同的概念相同的情况 67 继续 在收到C网的短消息时 使用C网的合法性检查规则 C网的安全性检查逻辑 C网的转发处理方法 其他更多概念该情况中的实例 68 G网情况 在收到G网的短消息时 使用G网的合法性检查规则 G网的安全性检查逻辑 G网的转发处理方法 已有概念新情况 69 关于客户 客户常常对自己的问题领域非常了解但是 很少会在概念层面上思考问题当他们想说 通常 时 他们常常说成 总是 当他们想说 很少 时 他们常常说成 决不 当他们说已经解释了所用的情况时 其实只是解释了最常见的情况分析矩阵可以帮助我们就一些特定问题和客户进一步沟通 比如 发现某个概念在某种情况中并没有特定实例 客户非常擅长就特定问题进行交流 70 应用分析矩阵 分析矩阵中的每一列表示一种特定的情况 在我们的例子中 表示的是不同的网络环境以及具体的处理方法表中的每一项可以被认为是一个对象 71 把元素看成是对象 对于复杂的情况 可以针对其中的元素再次应用分析矩阵 72 应用分析矩阵 每一行表示了一个规则在不同情况下的不同实现方式这听起来很像是Strategy模式可以按照该模式进行实现如何正确地实例化策略对象呢 73 如何控制对象的实例化 我们要解决两个问题 要以一种解耦的方式得到并使用所希望的对象对象要形成正确的集Strategy模式可以解决对象的使用问题要想实例化出正确的对象集合 需要一种能够实例化 一族 对象的方式这些对象 集合 促成我们得到创建它们的方法对象工厂 74 AbstractFactory模式 75 AbstractFactory模式 我们需要针对特定的情形 创建出适合的对象族 也就是说 特定的客户需要特定的对象实例集合GoF意图 在无需指明具体类的情况下 提供一个用于创建一族相关或者相互依赖的对象的接口 一组方法 76 AbstractFactory模式 AbstractFactory模式为我们提供了一种实现一组针对某种特定情况的对象的方法在我们的问题中 我们可以把哪种情况需要哪些对象的规则包含在一个AbstractFactory中由AbstractFactory来处理可能的组合关系软件的其余部分只需将对象当成组件使用即可 无需关心其具体类型和族关系 77 AbstractFact