北京大学软件学院设计模式教程(一).pptVIP

设计模式——1#Fa?ade, Adapter, Strategy, Bridge, Abstract Factory 王亚沙 北京大学软件研究所 内容提要 一、Fa?ade模式 二、Adapter模式 三、Strategy模式 四、Bridge模式 五、Abstract Factory模式 六、对面向对象相关概念的反思 一、Fa?ade模式 什么是Fa?ade？ 法文单词，Fa?ade是建筑的正面的意思 欧洲古典建筑通常在正面重点装饰，一些做得十分华丽 幕墙 Fa?ade解决的问题 先说一个生活中的例子——照相 话说春节同学聚会上，我被指派为大家拍张合影 当时的情况是这样的… 时间：晚上8点 地点：餐厅包厢内 要求：能把每个同学正常的照出来（如此而已……） 本人摄影水平：相当初级，从没有用过这款相机 问题 在夜间的包厢里，光线严重不足，如果想找出一张还算正常的照片，需要 调整焦距 调整光圈 打开闪光灯 … 没有时间对照说明书学习了… 如何在不浪费大家表情的情况下迅速把这些都做好呢？ 结果：我比较圆满的完成了拍照任务? 我是如何做到的呢？ 我的解决方案 将照相机设定到夜间肖像模式 按下快门，一切OK 神奇的夜间肖像模式 由照相机自动的为用户配置好夜间肖像拍摄所需的各种模块 为用户提供了一个极为简便的使用接口 现有主流相机大都提供了多种内建的拍摄模式（运动模式、静物模式、连拍模式…） 上述问题用图形来表示： 抽象一下，看看软件中经常存在的问题 问题： 用户使用系统难度增加（必须对系统内部结构有足够了解） 系统逻辑变得复杂（客户端代码中充满了对于各种底层模块的访问） 维护成本增加（客户端代码紧耦合于系统内部模块。一旦系统内部结构变化，就必须修改相应客户端代码） Fa?ade模式 Fa?ade模式的图示 示例：照相机的例子 UML 代码 代码 Fa?ade模式的关键特征 二、Adapter模式 Adapter模式解决的问题 就如前面的课程中说到的那个例子 总是存在一些类，我们希望复用他，但是他却没有我们期望的接口 这个期望的接口，通常是不能修改的 “将一个类的接口转换成客户希望的另一个接口。Adapter模式使原来由于接口不兼容而不能一起工作的类可以一起工作。 Adapter模式 图示： 1. 对象Adapter 图示： 2. 类Adapter 示例：画图的例子 客户类通过Shape接口操作所有的图形 各种Shape的继承关系如下： 现在需要增加一种新的形状——Circle 当然可以选择重新编写这个Circle类，并且使其实现Shape接口 因为需要重新开发Circle的display、undisplay、fill函数，工作量比较大 我们发现有一个别人编写的类可以满足我们的功能，但是这个类的接口不符合Shape类的要求 应用Adapter模式将其轻松搞定 代码： 两个问题： 1，应用类Adapter模式如何设计？ 2，SetLocation、GetLocation和SetColor方法如果不是虚函数，如何处理？ Adapter模式的关键特征 Adapter模式的关键特征 思考：Fa?ade和Adapter是一个模式吗？ Fa?ade和Adapter模式很相似： 他们都是包装——利用对象将已有系统的一部分包装起来，以便于在新系统中使用。 甚至类结构都是相似的： 被包装的对象作为一个成员出现在新对象中，当新对象接受到消息时，他将其交付给被包装对象处理。 那么我们是否可以认为Fa?ade和Adapter是不同名字的同一个模式呢？ 教材中对这两个模式的比较 进一步的思考——模型与模式的区别 先从定义上看： 设计模型是对设计方案的抽象，他抽象的是问题的解 而设计模式是对在某一特定语境下反复出现的一类问题的解决方案 再思考： 设计模式至少包括：context/problem/solution三个部分 设计模式是一个三元组，这三个部分是一个整体，他告诉我们一种解决问题的方法 设计模型是鱼，设计模式是渔授人一鱼不如授人以渔 三、Strategy模式 Strategy模式解决的问题 在实际中我们经常会发现一个问题有多种可选的策略，这些策略在概念上具有相同的功能，但是适用于不同的环境 如果我们简单的使用继承关系来对这些策略上的差异进行建模，可能会导致很多问题： 类的个数迅速失控 代码大量重复、冗余 复用无法进行 用一个例子来说： 这是一个电子商务系统，其中有一个控制器对象（TaskController），用于处理销售请求。他能够确认何时有人在请求销售订单，并将请求转给SalesOrder对象处理 新的需求 要处理多种税额计算的方法。 例如要处理美国、加拿大、中国三个国家的税收方法（税法不同计税方法就不同） 应对策略：