当前课程知识点：软件工程与软件自动化 > 第三章 OO与UML > 3.4 从重构到模式 > 模式和设计模式
嗨，大家好
今天开始讨论模式和设计模式
为什么不单单讨论设计模式呢？
这是因为设计模式只是模式中的一种
常用的还有架构模式和分析模式
这些模式对于软件开发活动都有很好的指导意义
因此这里放在一起简单讨论一下，获得整体印象
有感兴趣的同学，可以下去自己寻找相关的资料
来学习
模式记录了专家的经验，让我们这些非专家也能
理解
并且能够快速的运用到我们的工作中去，获得良
好的分析和设计结果
随着大家对模式的普遍掌握，模式的名称也变成
了一份词汇表
能够帮助我们进行更高效的交流
更容易的理解这个系统
举个例子，你有一个商业上的竞争对手让你很苦
恼
你就去向一个大师请教
大师微微一笑，只说了四个字“借刀杀人”
于是你就明白该怎么做了，这就是模式的威力
一个完整的模式不仅给出了问题产生的场景
还给出了具体的解决方案
而且随着时间推移和相关因素的变更，模式也会
发生变化
而且随着时间推移和相关因素的变更，模式也会
发生变化
从层次上来说，最低级的模式是代码模式
这种模式与你所使用的编程语言有关
所以一般不怎么使用
分析模式比较抽象
一般要求通过需求的表面看透问题的本质
从而确定软件系统所使用的某种智力模型
比如我们用用例分析技术描绘了一个斯诺克台球
模拟游戏
通过表面的特征，我们知道是白球和彩球的撞击
包括撞击速度，撞击角度，距离和力度等等
对于背后的运动规律比如质量，速度，动量动能
分析人员可以选用牛顿模型或者爱因斯坦模型
当然啦，选用不同模型会导致不同的复杂度
设计模式用于更好的描述一个系统
我们后面详细说
架构模式提供了软件系统的基础结构组织模型
为其中的组件和组件之间的关系制定了一系列的
规则
从理解的难度说，在大家都具有面向对象技术基
础的前提下
我个人推荐大家学习的顺序是，先学习设计模式
因为设计模式最具体，和我们大部分人的水平比
较接近
代码模式就不建议关注了，因为它是与编程语言
有关
然后可以看一看分析模式和架构模式的资料
软件架构可以理解为软件的一种搭建形式
它往往规定了软件的模块是怎样构成的
通信接口是什么样子的，组件模型和集成框架等
等
已知的架构模式有70多种
其中一些架构模式的名字在设计模式中也能看到
因此有助于相互理解
有些架构模式因为常常使用，所以看起来是非常
简单的
比如我们常说的C/S，B/S，MVC等等
一般来说架构模式往往可以分解成多个设计模式
的联合使用
比如说MVC模式里常常包括了调停者模式、策略
模式
合成模式、观察者模式等等
软件设计模式是专家们从建筑行业借鉴过来的
相对于架构模式来说
相当于架构模式盖好了一栋建筑物，一栋楼
修了各种楼道管道，通了水电煤气
而设计模式关注的是里面某个房间的装修和装饰
具体来讲，就是用一套相互作用的类来强化局部
的类之间的关系
让整个系统更具有灵活性和可扩展性
从而应对可能发生的需求变更
一般来说，程序员比较关注设计模式
因为设计模式可以让他们在面对客户的需求变化
的时候
不至于手忙脚乱
下面我们来看Gof的23种设计模式
Gof提到的这23种设计模式一般被分成3种类型
也就是创建型，结构型和行为型
创建型顾名思义，就是用于替代直接new一个对
象这种状况的
也就是通过把生成对象这件事复杂化
来换取对需求变更的从容应对
结构型关注的是如何安排系统的局部静态结构
将一组对象组合成一个更大的结构
来改善系统的内聚性和耦合性
行为型定义了对象之间的消息传递，路由和流程
控制
这三种类型的设计模式结合起来为程序员提供了
完整的解决方案
使得设计出来的面向对象系统更好的遵循了
我们前面提到过的7种原则和9种通用职责分配模
式
由于时间关系和篇幅关系
我们这里简单的列举几个设计模式的例子
需要进一步学习的同学可以参加相关课程的学习
或者是搜索相关的资料
我们看一下常用的工厂模式，这个模式常常用于
替代new这个关键字生成具有共同接口的对象
从这个角度来看，工厂模式不是万能的
不能随意生成任意的对象
不能随意生成任意的对象
这些对象要有统一的接口
为了便于理解，这里我们认为工厂模式包含了三
种形态
也就是简单工厂，工厂方法和抽象工厂
简单工厂非常简单，它是在模式类的内部使用继
承和多态机制
根据传进来的参数，通过switch语句匹配
如果匹配到哪一种，就把哪一类的子类对象
赋值给父类指针类型
一般高冷一点的程序员是不屑于使用这种方法的
复杂一点的是工厂方法，通过设定几个辅助的工
厂类
来生成对应的对象
这种方法取消了switch语句，提高了系统的可扩
展性
当需要生成新的对象的时候，不需要修改已有的
类
而是派生出新的类和新的对象以及新的辅助工厂
类
而抽象工厂相对更加复杂
用于解决二维的对象产品簇的生成问题
下面再说一下同属于创建型的单件模式
熟悉C语言或其他结构化编程语言的同学都知道
全局变量作为函数存取数据的公共容器
用起来很方便，也很随意，但同时也带来了很多
副作用
在纯面向对象编程语言中已经没有了全局变量的
概念
也没有了全局变量所带来的便利和方便
为此，可以用单件模式来模拟全局变量
同时还具有了“只此一家，别无分店”的效果
单件模式的实现方法有好几种，比较容易理解的
做法就是
先把类的构造函数设置成private隐藏起来
这样别的对象就没有办法直接new这个对象了
如过不new一个对象，怎么才能用它的方法呢？
我们自然想到了要用一个静态的public的方法
这个方法返回一个自身的引用
为了返回这个自身的引用，就需要在类的内部
设置一个静态的私有的自身对象
这里的关键就是要在GetInstance()里的逻辑加上
判断
如果是第一次访问，就new出一个自己返回给调
用者
如果是第二次，第三次的访问
就直接返回自己已经存在的那个对象
当然这里返回的是引用
观察者模式定义了对象之间的一种一对多的关系
当一个对象的状态发生变化, 所有依赖于它的对
象
都会得到通知并被自动更新
这种模式在实际的编程当中经常遇到
比如当用MVC结构的时候，某个model
我们叫数据结构
当这个对象的数据被修改以后
它所对应的多个界面都应该自动刷新
比如从ATM机取钱，ATM机的界面金额更新
手机收到了提示短信
邮箱也收到了取款的通知邮件
微信也收到了银行的推送信息等等
我们来简单看一下观察者模式具体的实现方法
我们看这个图，Subject是被观察者基类
observer是观察者基类
被观察者类中维护了一个列表
用于登记和注销有哪些观察者对我感兴趣
想得到我的更新通知
当我的内部数据发生了变化，按照约定
被观察者就给列表中的每一个观察者发消息
消息也就是调用它们的update()方法
不同的观察者子类就会根据所对应的被观察者子
类的引用
来获取它的状态，并显示在特定的界面上呈现给
用户
在进行程序结构改善的过程当中，容易造成这样
一个误解
就是容易过分的关注程序结构的灵活性
这样做的结果就是最终造成系统的混乱复杂
不容易理解，难以维护，从而导致整个项目的失
败
一个好的程序其实根本不在于
其中应用了多少设计模式，多么有弹性
主要在于这个结构否能够清晰的展现了设计者的
意图
在开发活动中如果一开始就使用设计模式
注意力就会集中在如何使用设计模式上
而不是集中在如何满足需求上
这样就会导致过度设计
如何避免过度设计呢
在初始模型建立之后，一般都会进行重构
重构的时候如果发现某个部分的设计需要
一些额外的灵活性来满足可能产生的需求变更
这时候就可以考虑引入设计模式
对于一个好的重构过程来说
重构的结果到底是不是一个设计模式根本不重要
它的最终动机是什么呢？
减少或者是消除代码冗余，简化设计
最终达到展示真正的设计意图
更加便于交流
使用设计模式可以改善程序结构
经过调整的代码具有了更大的弹性
更容易适应变化，软件系统更加具备可扩展性和
健壮性
过份的强调设计模式导致代码复杂，其他的开发
人员
不得不花更多的时间来理解这些本来可以去除的
复杂性
导致代码维护、扩展困难
那么如何正确使用设计模式呢？
我们认为除了重构之外，TDD测试驱动开发方法
也可以帮助你让你注意到需求的真正目的
这里向大家推荐一本经典图书《从重构到模式》
这本书讲述了如何将重构与设计模式相结合
如何使用设计模式来改善既有的设计
这本书介绍了以模式为导向的重构方法的理论和
实践
非常值得大家学习
下面我们对比一下这些模式的层次关系作为这部
分的小结
不同的模式存在于它们各自的抽象层次和具体层
次上
首先看架构模式，架构模式是一个系统的高层次
策略
它涉及到了大粒度的组件以及整体的性质
架构模式的好坏可以影响到总体的布局和框架性
的结构
设计模式是中等尺度的结构策略
设计模式的好坏不会影响到系统的整体布局和总
体架构
设计模式只定义了子系统或组件的微观结构
分析模式注重策略和业务模型
代码模式是特定的范例和与特定语言有关的编程
技巧
代码模式的好坏不会影响到一个部件或子系统的
结构
更不会影响到系统的布局和大尺度的框架
好，这部分内容我们就讨论到这里，谢谢大家
-1.1 软件工程的前生今世
--开篇阅读
--授课视频
-第一章 软件工程基础--1.1 软件工程的前生今世
-1.2 万变不离其宗
--授课视频1/3
--授课视频2/3
--授课视频3/3
-第一章 软件工程基础--1.2 万变不离其宗
-1.3 唯一不变的是变化
--授课视频1/3
--授课视频2/3
--授课视频3/3
--外部链接
-第一章 软件工程基础--1.3 唯一不变的是变化
-1.4 亡羊补牢为时不晚
--授课视频1/2
--授课视频2/2
-第一章 软件工程基础--1.4 亡羊补牢为时不晚
-扩展阅读与话题讨论
--扩展阅读
--话题讨论
-2.1 方法论来源于恐惧
--授课视频
-第二章 敏捷开发--2.1 方法论来源于恐惧
-2.2 敏捷是什么
--授课视频
-第二章 敏捷开发--2.2 敏捷是什么
-2.3 典型敏捷开发方法
--XP敏捷开发方法
-第二章 敏捷开发--2.3 典型敏捷开发方法
-2.4 敏捷不是万能药
--授课视频
-第二章 敏捷开发--2.4 敏捷不是万能药
-专家谈敏捷
-扩展阅读与话题讨论
--外部链接
--话题讨论
-3.1 面向对象核心概念和基本特性
-第三章 OO与UML--3.1 面向对象核心概念和基本特性
-3.2 面向对象设计基本原则
-第三章 OO与UML--3.2 面向对象设计基本原则
-3.3 通用职责分配模式(GRASP)
--通用职责分配模式
-3.3 通用职责分配模式(GRASP)--作业
-3.4 从重构到模式
--模式和设计模式
-第三章 OO与UML--3.4 从重构到模式
-3.5 使用UML设计面向对象系统
--UML综述
-第三章 OO与UML--3.5 使用UML设计面向对象系统
-3.6 主要UML模型图绘制技巧
--UML用例图
--UML类图
-第三章 OO与UML--3.6 主要UML模型图绘制技巧
-扩展阅读与话题讨论
--设计模式有毒么？
--话题讨论
-4.1 案例简介
--书籍参考
--案例说明
-4.2 对象模型之一
--授课视频1/2
--授课视频2/2
-第四章 对象模型分析--4.2 对象模型之一
-4.3 对象模型之二
--授课视频1/2
--授课视频2/2
-第四章 对象模型分析--4.3 对象模型之二
-4.4 对象模型之交互
--授课视频
-第四章 对象模型分析--4.4 对象模型之交互
-扩展阅读与话题讨论
--图书推荐
--话题讨论
-5.1 软件自动化概述
--软件自动化概述
-第五章 软件自动化技术--5.1 软件自动化概述
-5.2 典型自动化方法和工具
-第五章 软件自动化技术--5.2 典型自动化方法和工具
-5.3 文档自动化
--文档自动化视频
-第五章 软件自动化技术--5.3 文档自动化
-5.4 测试自动化
--测试自动化视频
-第五章 软件自动化技术--5.4 测试自动化
-专家访谈
-扩展阅读与话题讨论
--话题讨论
-6.1 持续集成
-第六章 CI/CD与DevOps--6.1 持续集成
-6.2 持续交付和部署
-第六章 CI/CD与DevOps--6.2 持续交付和部署
-6.3 DevOps
-第六章 CI/CD与DevOps--6.3 DevOps
-专家访谈
-扩展阅读与话题讨论
--DevOps专题
--话题讨论
-7.1 质量和质量保证
--授课视频
-第七章 软件质量保证--7.1 质量和质量保证
-7.2 软件质量模型
--授课视频
-第七章 软件质量保证--7.2 软件质量模型
-7.3 SQA组织与职责
--授课视频
-第七章 软件质量保证--7.3 SQA组织与职责
-7.4 全面软件质量管理
--授课视频
-第七章 软件质量保证--7.4 全面软件质量管理
-专家访谈
--专家访谈
-扩展阅读与话题讨论
--外部链接
--话题讨论
-8.1 软件过程综述
--授课视频
-第八章 软件过程改进--8.1 软件过程综述
-8.2 软件过程改进
--授课视频
-第八章 软件过程改进--8.2 软件过程改进
-8.3 能力成熟度模型
--授课视频
-第八章 软件过程改进--8.3 能力成熟度模型
-8.4 过程改进标准框架
--授课视频
-第八章 软件过程改进--8.4 过程改进标准框架
-扩展阅读与话题讨论
--话题讨论
-9.1软件复用综述
--授课视频
-第九章 软件复用--9.1软件复用综述
-9.2 软件构件技术
--授课视频
-第九章 软件复用--9.2 软件构件技术
-9.3 软件复用实施
--授课视频
-第九章 软件复用--9.3 软件复用实施
-9.4 微服务架构
--授课视频
-第九章 软件复用--9.4 微服务架构
-扩展阅读与话题讨论
--微服务扩展
--话题讨论
-文档提交处--文档提交
