Embed Size (px)
Citation preview
高级软件工程
教学安排回顾
教学安排第4周(9月16日)：概论
第5周(9月23日) ：需求工程
第7周(10月7日) ：软件设计1第8周(10月14日) ：软件设计2第9周(10月14日) ：中间件技术
第9周(10月21日) ：敏捷开发
第10周(10月28日) : 软件项目管理
第11周：云计算概论
第12周：数据中心和云构架
第13周：云计算的关键技术与挑战
第14周：云计算案例和商业模式
第15周：物联网技术概述
第16周：传感器、自动识别技术与RFID第17周：定位系统
第18周：无线宽带网络和移动通信网络
高级软件工程
课程回顾
软件过程模型
Waterfall ModelWaterfall Model with Maintenance CircleWaterfall Model with PrototypingSpiral ModelV ModelPhased Development ModelIncremental and Iterative ModelRUP……
Waterfall• Waterfall• Classic Life Cycle Model• Linear Sequential Model
Prob Def
Req Analy
High‐level Design
Low‐level design
coding
testing
maintenance
Dependencies between any
two subsequent stages
Defer development after
designs
To ensure quality
V‐Model
Incremental and Iterative Model
Incremental Development
Iterative Development
create create
format
create
formatedit
create
More styles
Easyquick
create
More styles
Pasteeasy
create
stylesPasteclumsy
Spira
l Mod
el
统一过程Iterative and incremental developmentUse‐case driven
Project ManagementEnvironment
Business Modeling
ImplementationTest
Analysis & Design
Preliminary Iteration(s)
Iter.#1
Phases
Process Workflows
Iterations
Supporting Workflows
Iter.#2
Iter.#n
Iter.#n+1
Iter.#n+2
Iter.#m
Iter.#m+1
Deployment
Configuration & Change Mgmt
Requirements
Elaboration TransitionInception Construction
In an iteration, you walk through all workflows
非功能需求功能需求
业务需求
用户需求 质量属性
外部接口
系统要求 约束功能需求
项目视图和范围文档
使用实例文档
软件需求文档（SRS）
业务需求
软件需求
Introduction Purpose Definitions System overview References
Overall description Product perspective
System Interfaces User Interfaces Hardware interfaces Software interfaces Communication Interfaces Memory Constraints Operations Site Adaptation Requirements
Product functions User characteristics Constraints, assumptions and dependencies
Specific requirements External interface requirements Functional requirements Performance requirements Design constraints
Standards Compliance Logical database requirement Software System attributes
Reliability Availability Security Maintainability Portability
Other requirements
软件需求文档
需求变更
分析、记录审阅、协商
需求变更过程
基线需求
市场营销 客户 管理层
需求开发
需求管理
市场营销客户
管理层
项目变更
项目环境
软件需求管理
软件需求建模之UML: 用例模型
14
UML建模：类图
http://www.agiledata.org/images/oo101ClassDiagram.gif
UML建模：时序图
There is also notation for loops, conditions, etc.
Name: Class
New object
Create
Message
Return
Delete
Self‐call
形式化方法：Z Notations
高级软件工程
第三节课: 软件设计(1)
主讲：刘驰 副教授 系主任
2013年10月7日
主要内容
软件体系结构的基本概念
典型的软件体系结构风格
特定领域的软件体系结构
分布式系统结构
体系结构框架
设计模式
用户界面设计
1 什么是软件体系结构？Paul Clements; Felix Bachmann, Len Bass, David Garlan, James Ivers, Reed Little, Paulo Merson, Robert Nord, Judith Stafford (2010). Documenting Software Architectures: Views and Beyond, Second Edition. Boston: Addison‐Wesley. ISBN 0‐321‐55268‐7.
“the high level structures of a software system. It can be defined as the set of structures needed to reason about the software system, which comprise the software elements, the relations between them, and the properties of both elements and relations”
这一定义强调在任一体系结构表述中“软件构件”的角色。
1．模式
建筑师C.Alexander对模式给出的经典定义：每个模式都描述了
一个在我们的环境中不断出现的问题及该问题的解决方案。
（1）体系结构模式(architectural pattern)：软件系统的基本结构方案，包含了: (a) 一组预定义的子系统及其责任、(b) 用于组织和管理这些子系统的规则。如：OSI参考模型
（2）设计模式(design pattern)：为软件系统的子系统、构件或者
构件之间的关系提供一个精炼的解决方案，描述了在特定环境
下，用于解决通用软件设计问题的构件以及这些构件相互通信
时的各种结构。
Gang of Four (GoF)提出的23种设计模式。
体系结构模式、风格和框架
Gang‐of‐Four’95
2．风格
风格是带有一种倾向性的模式。同一个问题可以有不同的解决问题的方式，但根据经验，通常会强烈倾向于采用特定的模式，这就是风格。每种风格描述一种系统范畴：
（1）一组构件（如数据库、计算模块）完成系统需要的某种功能；
（2）一组连接件，它们能使构件间实现通信；
（3）约束，定义构件如何集成为一个系统；
（4）语义模型，它能使设计者通过分析系统构成的性质来理解系统的整体性质。
对体系结构风格的研究和实践为大粒度的软件复用提
供了可能。
3．框架
随着应用的发展和完善，某些带有整体性的应用
模式被逐渐固定下来，形成特定的框架，包括基本构成元素和关系。
框架是特定领域问题的体系结构模式，框架定义
了基本构成单元和关系后，开发者就可以集中精力解决业务逻辑问题。
在组织形式上，框架是一个待实例化的完整系
统，定义了软件系统的元素和关系，创建了基本的模块，定义了涉及功能更改和扩充的插件位置。
典型的框架例子有MVC框架和Struts框架。
输入数据经过一系列的计算和操作构件的变换形成输出数据如：管道/过滤器、批处理序列
数据流风格
管道/过滤器结构
2 典型的体系结构风格
管道/过滤器风格具有以下优点：
（1）良好的隐蔽性、高内聚、低耦合
（2）允许设计者将整个系统的输入/输出行为看成是多个过
滤器的行为的简单合成。
（3）支持软件复用。只要提供适合在两个过滤器之间传送
的数据，任何两个过滤器都可被连接起来。
（4）系统维护和增强系统性能简单。新的过滤器可以添加
到现有系统中来；旧的可以被改进的过滤器替换掉。
（5）易于吞吐量分析、诊断死锁
（6）支持并行执行。每个过滤器是作为一个单独的任务完
成，因此可与其他任务并行执行。
管道/过滤器风格有以下缺点：
（1）通常导致进程成为批处理的结构。这是因为虽然过滤器可增量式地处理数据，但它们是独立的，所以设计者必须将每个过滤器看成一个完整的从输入到输出的转换。
（2）不适合处理交互的应用。当需要增量地显示改变时，这个问题尤为严重。
（3）因为在数据传输上没有通用的标准，每个过滤器都增加了解析和合成数据的工作，这样就导致了系统性能下降，并增加了编写过滤器的复杂性。
调用—返回风格1．主程序/子程序体系结构
将功能分解为一个控制层次，其中“主”程序调用一组程序构件，这些程序构件又去调用别的程序构件。这种结构总体上为树状结构，可以在底层存在公共模块。
Remote Procedure Call (RPC)
More for RPCProtocol: XML/JSON‐RPCsynchronous/asynchronous readsynchronous/asynchronous writepublish/subscribe……
主程序/子程序体系结构的优点:
（1）可以使用自顶向下，逐步分解的方法得到体系结构
图，典型的拓扑结构为树状结构。使用过程调用作为
程序之间的交互机制。
（2）采用程序设计语言支持的单线程控制。
主要缺点:
（1）子程序的正确性难于判断，需层次推理处理嵌套。
（2）子系统的结构不清晰。通常可以将多个子程序合成
为一个模块。
2．层次结构整个系统被组织成一个分层结构，每一层为上层提供
服务，并作为下一层的客户。
各种构件
过程调用
3.仓库风格
客户软件
数据仓库
(中心存储库或黑板)
客户软件
客户软件
客户软件 客户软件
客户软件 客户软件
如：数据库系统、超文本系统和黑板系统。
在这种风格中，数据仓库（如文件或数据库）位于这种体系结构的中心，其他构件会经常访问该数据仓库，并对仓库中的数据进行增删改查操作
特定的应用需要特定的体系结构模型，称
为领域相关的体系结构。
通用模型(generic model)
参考模型(reference model)
3 特定领域的软件体系结构
通用模型
从许多实际系统中抽象出来的一般模型
封装了这些系统的主要特征。
例如，许多图书馆开发了自己的图书馆馆藏/流
通系统，若把它们的共同功能抽取出来并创建一个
让所有图书馆都认可的系统体系结构模型，就成为
图书馆通用模型。
描述了一个理想化的包含了系统应具有的所有特征的
软件体系结构。
它是更抽象且是描述一大类系统的模型，并且为设计
者提供有关某类系统设计的一般指导。
参考模型
OSI参考模型
以上两种不同类型的模型之间并不存在严格的区别，
也可以将通用模型视为参考模型。
通用模型可以直接在设计中复用
而参考模型一般是用于领域概念间的交流和对可能的体系
结构做出比较。
通用模型通常是经过“自下而上”地对已有系统的抽象
参考模型是“由上到下”产生的
4 分布式体系结构
在集中式计算技术时代广泛使用的是大型机/小型机计算模
型。
20世纪80年代以后，集中式结构逐渐被以PC为主的微机网络
所取代。个人计算机和工作站的采用，永远改变了大型机/
小型机计算模型，从而产生了分布式计算模型。
分布式计算模型主要具有以下优点：
(1) 资源共享。分布式系统允许硬件、软件等资源共享使用。
(2) 经济性。
(3) 性能与可扩展性。
(4) 固有分布性。
(5) 健壮性。
系统由许多进程组成，这些进
程可以在不同的处理器上并行运
行，极大地提高系统性能。
大型实时系统需要实时采集信
息，并利用采集到的信息进行决
策，然后发送信号给执行机构。
虽然，信息采集、决策制定和
执行控制这些进程可以在同一台
处理器上统一调度执行，但使用
多处理器能够提高系统性能，减
少响应时间。
多处理器体系结构 IBM System Z10 EC, USD 230M
Client/Server体系结构是基于资源不对等产生
的，且为实现资源共享而提出来的
由服务器、客户机和网络三部分组成。
在C/S体系结构中，客户机可以通过远程调用来
获取服务器提供的服务
客户机必须知道可用的服务器的名字及它们所
提供的服务，而服务器不需要知道客户机的身
份，也不需要知道有多少台服务器在运行。
客户/服务器体系结构
传统的C/S体系结构分为两层
Thin Client
Fat Client
（1）瘦客户机模型。数据管理和应用逻辑都在服务器上执行，客户机只负责信息表示部分。缺点：
将繁重的处理负荷放在了服务器和网络上，服务器负责所有的计算，但增加了客户机和服务器之间的网络流量。
（2）胖客户机模型。服务器只负责对数据的管理。客户机软件实现了应用逻辑和与系统用户的交互。充分利用客户机的处理能力，利于分布式处理。但随着系统规模的扩大和复杂性提高，暴露出了以下缺点：
开发成本较高。
用户界面风格不一，使用繁杂，不利于推广使用。
软件移植困难。
软件维护和升级困难。
为了解决以上问题，
三层C/S体系结构应运而
生：增加了应用服务器
（处理应用逻辑）。系统
分成表示层、应用逻辑层
和数据层三个部分。
浏览器/服务器(Browser/Server, B/S) 风格是三层体系结构
的一种实现方式，其具体结构为浏览器/Web服务器/数据
库服务器。
Example: Internet Banking
Summary of C/S Architecture
动机：在C/S模型中，客户机和服务器的地位是不同的
目的：消除客户机与服务器之间的差别，提高系统的
伸缩性以及有效地均衡负载
分布式对象的实质是在分布式异构环境下建立应用系
统框架和对象构件，它将应用服务分割成具有完整逻
辑含义的独立子模块（称为构件）
各个构件可放在同一台服务器或分布在多台服务器上
运行
模块之间通过中间件互相通信。
分布式对象体系结构
这个中间件称为软件总线或对象请求代理(Object Request Broker)，它的作用是在对象之间提供一个无缝接口。
降低主服务器的负荷、共享网络资源、平衡网络中计算机业务处理的分配，提高计算机系统协同处理能力
使应用的实现更为灵活。
构件是一些独立的代码封装体，在分布计算的环境下可
以是一个简单的对象，但大多数情况下是一组相关的对
象组合体，提供一定的服务
构件位置透明、语言独立、平台独立，可互相发送消
息，实现请求服务
构件之间并不存在客户机与服务器的界限，接受服务者
扮演客户机的角色，提供服务者就是服务器。
当前主流的分布式对象技术规范有OMG的CORBA、Microsoft公司的.NET和Sun公司的J2EE。
Example: Data Mining System
5 体系结构框架
MVC框架
即模型—视图—控制器
(model‐view‐controller)它强调将用户输入、数
据模型和数据表示的方式
分开设计
模型: 核心数据和功能
视图: 数据表示
控制器:输入/输出控制
1. 模型对象
模型对象独立于外在显示内容和形式，代表应用领域中的业
务实体和业务规则。模型对象的变化通过事件处理通知视图
和控制器对象。
2. 视图对象
视图对象代表GUI对象，并且以用户需要的格式表示模型状
态，是交互系统与外界的接口。视图对象可以包含子视图，
子视图用于显示模型的不同部分。通常每个视图对象对应一
个控制器对象。3. 控制器对象
控制器对象代表鼠标和键盘事件。它处理用户的输入行为并
给模型发送业务事件，再将业务事件解析为模型应执行的动作；同时，模型的更新与修改也将通过控制器来通知视图，从而保持各个视图与模型的一致性。
在MVC框架的基础上进行扩展得到的。
J2EE体系结构框架
客户层
应用程序
资源层
表示层
表示逻辑
内容管理
会话管理
业务层
应用逻辑
业务规则
业务对象
集成层
数据访问
消息接发
服务集成
J2EE的核心体系结构框架
ControllerView Model
• 客户层：用户通过客户层与系统交互。该层可
以是各种类型的客户端。例如，可编程客户端
（如基于Java Swing的客户端或applet），纯
Web浏览器客户端，WML移动客户端等。
• 资源层：资源层可以是企业数据库，电子商务
解决方案中的外部企业系统，或者是外部SOA服务。数据可以分布在多个服务器上。
J2EE模型是分层结构，中间的3层（表示层，业
务层，集成层）包含应用程序构件，客户层和资
源层处于应用程序的外围。
表示层：也称为Web层或服务器端表示层，用户通
过表示层来访问应用程序。在基于Web的应用系统
中，表示层由用户界面代码和运行于Web服务器或
应用服务器上的过程组成。参考MVC框架，表示层
包括视图(View)构件和控制器构件(Controller)。
业务层：业务层包含表示层中的控制器构件没有实
现的一部分应用逻辑。它负责确认和执行企业范围
内的业务规则和事务，并管理从资源层加载到应用
程序高速缓存中的业务对象。
集成层：集成层负责建立和维护与数据源的连接。例如，通过JDBC与数据库进行通信，利用Java消息
服务（JMS）与外部系统联合。
表示—控制—中介者—实体—基础（presentation-control-mediator-entity-foundation）
垂直层次的分层体系结构框架。包含4层：表示层、控制
层、领域层和基础层。领域层包含两个预定义包：实体
（entity）包和中介者（mediator）包。
PCMEF框架中包的依赖性主要是向下依赖性。表示层依
赖于控制层，控制层依赖于领域层，中介者包依赖于实体包
和基础层。
PCMEF框架
表示层:包含定义GUI对象的类。
控制层:处理表示层的请求，负责大多数程序逻辑、算法、主
要计算以及为每个用户维持会话状态。
领域层:其实体包处理控制请求,中介者包用于创建一个协调实
体类和基础
类的通信通道。
基础层:负责与数据
库和Web服务的通信。
6. 设计模式
什么是设计模式？
创建型模式
结构型模式
行为型模式
广义讲，设计模式是可解决一类软件问题并能重复使用的设计方案
狭义讲，设计模式是对被用来在特定场景下解决一般设计问题的类和相互通信的对象的描述。是在类和对象的层次描述的可重复使用的软件设计问题的解决方案
模式体现的是程序整体的构思，也会出现在分析或者是概要设计阶段
模式的核心思想是通过增加抽象层，把变化部分从那些不变部分里分离出来
什么是设计模式
模式名称(Pattern Name)
问题(Problem)：描述应该在何时使用模式。解释了设计问题和问题存在的前因后果,可能还描述模式必须满足的先决
条件
解决方案(Solution)：描述了设计的组成成分、相互关系及各
自的职责和协作方式。模式就像一个模板，可应用于多种场合，所以解决方案并不描述一个具体的设计或实现，而是提供设计问题的抽象描述和解决问题所采用的元素组合（类和对象）
效果(Consequences)：描述模式的应用效果及使用模式应权
衡的问题
模式的4大基本要素
单一职责原则 (Single Responsibility)“开‐闭”原则 (Open Closed)里氏代换原则 (Liskov Substitution)接口隔离原则 (Interface Segregation)依赖倒置原则 (Dependency Inversion)
设计模式的S.O.L.I.D.原则
设计模式就是实现了上述原则，从而达到代码复用、增加可维护性的目的
定义：对功能扩展是开放的，对修改是关闭的。在进行扩展的时
候，不需要对原来的程序进行修改
好处：灵活可用，可加入新功能，新模块满足不断变化的新需求
由于不修改软件原来的模块，不用担心软件的稳定性
开闭原则（OCP）
主要原则
抽象原则：把系统的所有可能的行为抽象成一个底层；由于
可从抽象层导出多个具体类来改变系统行为，因此对于可变
部分，系统设计对扩展是开放的
可变性封装原则：对系统所有可能发生变化的部分进行评估
和分类，每一个可变的因素都单独进行封装
就一个类而言，应仅有一个引起它变化的原因每一个引起类变化的原因就是一个职责，当类具有多职责时，应把多余职责分离出去，分别创建类来完成每一个职责都是一个变化的轴线，当需求变化时会反映为类的职责的变化
举例 interface Modem{public void dial(String pno);public void hangup();public send(char c);public char recv();
} Modem类有两个职责：连接管理和数据通信，应将它们分离
单一职责原则（SRP）
listKov替换原则（LSP）
定义：“继承必须确保父类所拥有的性质在子类中仍然成立”，当一个子类的实例能够替换任何其父类的实例时，它们之间才具有is‐a‐kind‐of‐A关系
只有当派生类可以替换掉其基类，而软件功能不受影响
时，基类才能真正被复用，派生类也才能够在基类的基础上增加新的行为
本质：在同一个继承体系中的对象应该有共同的行为特征
例子：企鹅是鸟吗？
生物学：企鹅属于鸟类
LSP原则：企鹅不属于鸟类，因为企鹅不会“飞”违反LSP的后果：有可能需要修改客户代码
依赖倒置原则（DIP）
定义：高层模块不应依赖低层模块，二者都应该依赖于抽象
高层模块只应包含重要的业务模型和策略选择
低层模块则是不同业务和策略的实现
高层抽象不依赖高层和低层模块的具体实现， 多只依赖于低层的抽象低层抽象和实现也只依赖于高层抽象
辅助原则
任何变量都不应该持有一个指向具体类的引用
任何类都不应该从具体类派生任何方法都不应覆盖其任何基类中已经实现了的方法
接口隔离原则（ISP）
多个和客户相关的接口要好于一个通用接口
如果一个类有几个使用者，与其让这个类载入所有使用
者需要使用的所有方法，还不如为每个使用者创建一个
特定接口，并让该类分别实现这些接口
ISP Example
ISP Example
创建型模式 结构型模式 行为型模式
根据模式的范围分，模式用于类还是用于对象
类模式：处理类和子类之间的关系，这些关系通过继承建立，是静态的，在编译时刻便确定下来了
对象模式：处理对象间的关系，这些关系在运行时刻是可以变化的，更具动态性
几乎所有模式都使用继承机制
所以“类模式”只指那些集中于处理类间关系的模式
大部分模式都属于对象模式的范畴
设计模式的类型
用来创建对象，抽象了实例化过程单例（Singleton）：保证一个类有且仅有一个实例，
提供一个全局访问点
工厂（Factory）：父类负责定义创建对象的公共接
口，而子类则负责生成具体对象，将类的实例化操作延迟到子类中完成
抽象工厂（Abstract Factory）：为一系列产品提供统
一的创建接口。当需要这个产品族的某一系列的时候，可以从抽象工厂中选出相应的系列创建一个具体的工厂类
创建型设计模式
生成器（Builder）：将复杂对象创建与表示分离，同
样的创建过程可创建不同的表示。允许用户通过指定复杂对象类型和内容来创建对象，用户不需要知道对象内部的具体构建细节
原型（Prototype）：通过“复制”一个已经存在的实例
来返回新的实例（不新建实例）。被复制的实例就是“原型”，这个原型是可定制的。
原型模式多用于创建复杂的或者耗时的实例，因
为这种情况下，复制一个已经存在的实例使程序运行更高效；或者创建值相等，只是命名不一样的同类数据
单例模式 Singleton Method
工厂模式 Factory Method
抽象工厂模式 Abstract Factory Method
建造者模式 Builder Method
原型模式 Prototype Method
创建型设计模式
单例(Singleton)模式的由来
系统中只能有一个窗口管理器、一个文件系统
一个数字滤波器只能有一个A/D转换器
一个会计系统只能专用于一个公司
一个全局变量使得一个对象可以被访问，但它不能阻止
防止实例化多个对象
更好的办法是，让类自身负责保存它的唯一实例。这个
类可以保证没有其他实例可以被创建，并且它可以提供
一个访问该实例的方法
单例模式的意图和适用性
意图：
保证一个类仅有一个实例
并提供一个全局访问点
适用场合：
当类只能有一个实例，且用户可以从一个众所周知的
访问点访问它时
当这个唯一实例是通过子类化可扩展的，并且客户应
该无需更改代码就能使用一个扩展实例时
单例模式的结构
定义一个静态Instance操作，允许客户访问它的唯一实例。Instance是一个类操作（一个静态成员函数）
Example
只给司机一辆车
public class Car{public void run(){System.out.prinln(“…”)}；
}
public class Test{public static void main(String[] args)
Car c= new Car();c.run();
}
public class Car{private Car(){}public static Car getInstance(){return new Car()};public void run(){System.out.prinln(“…”)};
}
public class Test{public static void main(String[] args)
Car c= Car.getInstance();c.run();
}
一点改进
public class Car{private static Car car=new Car();private Car(){}public static Car getInstance(){return car;}public void run(){System.out.prinln(“…”)};
}
public class Test{public static void main(String[] args)
Car c1= Car.getInstance();Car c2= Car.getInstance()’if(c1==c2) System.out.println(“…”)；c.run();
}
单例代码示例
延伸开来：多例Multitonpublic class Car{
private static Car car=new Car();private static List<Car> cars=new ArrayList<Car>();private Car(){public static Car getInstance(){return car;}
}public void run(){System.out.prinln(“…”)};
}
public class Test{public static void main(String[] args)
Car c1= Car.getInstance();Car c2= Car.getInstance()’if(c1==c2) System.out.println()；c.run();
}
单例模式的效果分析
对唯一实例受控访问：因为Singleton类封装唯一实例，
所以它可以严格的控制客户怎样以及何时访问它
缩小命名空间：Singleton模式是对全局变量的一种改
进。它避免了那些存储唯一实例的全局变量占用命名空
间
允许对操作和表示的精化：Singleton类可以有子类，而
且用这个扩展类的实例来配置一个应用是很容易的。可
以用所需要的类的实例在运行时刻配置应用
工厂模式
在面向对象编程中, 常用的方法是用new操作符构造对象实例，但在有些情况下， new操作符直接生成对象会带来一些问题
（1）创建对象之前必须清楚所要创建对象的类信息，但个别情况下
无法达到此要求，譬如打开一个视频文件需要一个播放器对象，但是用户可能不知道具体播放器叫什么名字，需要系统分派给这个视频文件一个合适的播放器，这种情况下用new运算符并不合适
（2）许多类型对象的创造需要一系列步骤需要计算或取得对象的初始设置、需要选择生成哪个子对象实
例在生成需要对象之前必须先生成一些辅助功能对象在这些情况,
新对象的建立就是一个 “过程”，而不仅仅是一个操作。为了能方便地完成这些复杂的对象创建工作，可引入工厂模式
工厂模式的结构
Product：定义工厂方法所创建对象的接口
ConcreteProduct (A, B)：实现Product接口
Factory：声明工厂方法，返回一个Product类型对象。
一个日志管理器：设计日志记录类，支持记录的方法有
FileLog
EventLog
实例 1
// LogFactory类public abstract class LogFactory{public abstract Log Create();
}
// FileFactory类public class FileFactory:LogFactory{public override FileLog Create(){
return new FileLog();}
}
// EventFactory类public class EventFactory:LogFactory{public override EventLog Create(){
return new EventLog();}
}
public class App{public static void Main(string[] args){LogFactory factory = new EventFactory();
Log log = factory.Create();
log.Write();}
}
Public interface Moveable{ public void run(); }
Public class Plane implements Moveable{@Overridepublic void run(){…};}
Public class Car implements Moveable{@Overridepublic void run(){…};}
Public abstract class VehicleFactory{abstract Moveable create();}Public class PlaneFactory extends VehicleFactory{public Moveable create(){return new Plane();} }Public class CarFactory extends VehicleFactory{public Moveable create(){return new Car();} }
Public class Test{public static void main(String[] args){
VehicleFactory f=new PlaneFactory(); // the only change happens here!Moveable m= factory.create();m.run();}
}
实例2：任意定制交通工具的类型和生产过程
抽象工厂模式的由来
面临“一系列相互依赖对象”的创建工作，由于需求变化，这“一系
列相互依赖的对象”也要改变，如何应对这种变化呢？
实例：Windows桌面主题，当更换一个桌面主题的时候，系统的
开始按钮、任务栏、菜单栏、工具栏等都变了，而且是一起变
的，他们的色调都很一致，类似这样的问题如何解决呢？
应用抽象工厂模式，是一种有效的解决途径
抽象工厂模式的意图
意图：提供一个创建一系列相关或相互依赖对象的接口，
而无需指定他们具体的类
适用场合
一个系统独立于其产品创建、组合和表示时
一个系统由多个产品系列中的一个来配置时
强调一系列相关产品对象的设计以便进行联合时
提供一个产品类库，只想显示其接口而非实现时
抽象工厂模式的结构
Abstract Factory：声明创建抽象产品对象的操作接口
ConcreteFactory：实现创建具体对象的操作
Abstract Product：为一类产品对象声明一个接口
ConcreteProduct：定义一个被具体工厂创建的产品对象
实例1：系列产品替换public class Car extends Vehicle{}public class AK47 extends Weapon{}public class Apple extends Food{public Void printName(return…);}
public abstract class Vehicle{public abstract void run();}public abstract class Weapon{public abstract void shoot();}public abstract class Food{public abstract void printName();}
public abstract class AbstractFactory{public abstract Vehicle createVehicle();public abstract Weapon createWeapon();public abstract Food createFood();
}
public class DefaultFactory extends AbstractFactory{public Vehicle createVehicle(){return new Car();}public Weapon createWeapon(){return new AK47();};public Food createFood(){return new Apple();};
}
public class MagicFactory extends AbstractFactory{public Vehicle createVehicle(){return new Broom();}public Weapon createWeapon(){return new MagicStick();};public Food createFood(){return new Mushroom();};
}
public class Test{
AbstactFactory f=new DefaultFactory();// only changes here to MagicFactory();Vehicle v=f.createVehicle();c.run();Weapon w=f.createWeapon();w.shoot();Food a = f.createFood();a.printName();}
花园有三种风格：典雅型、实用型和懒人型
花园中有3个位置需要种植植物：花台、墙角和花园中心
实例 2：花园布置（作业）
风格/位置 花台 中心 墙角
典雅型 郁金香 榕树 兰草
实用型 葡萄 石榴 丝瓜
懒人型 月季 茶花 竹子
工厂模式是一种极端情况下的抽象工厂模式，而抽象工厂模式可
以看成是工厂模式的一种推广
工厂模式的特点
一个抽象产品类，可以派生出多个具体产品类
一个抽象工厂类，可以派生出多个具体工厂类
每个具体工厂类只能创建一个具体的长品类实例
抽象工厂模式的特点
多个抽象产品类，每个抽象产品类可以派生出多个具体产品类
一个抽象工厂类，可以派生出多个具体工厂类
每个具体工厂类可以创建多个具体产品类的实例
抽象工厂模式与工厂模式的区别
提供一个接口，用于创建相关和依赖对象的家族，而不需要明确指定具体类。抽
象工厂允许客户使用抽象接口来创建一组相关产品，而不需要关心具体实际产出
的产品是什么
总结
所有工厂都是用来封装对象的创建
简单工厂，可以把客户程序从具体类解耦
工厂方法使用继承，把对象创建委托给子类，子类实现工厂方法来创建对象
抽象工厂使用对象组合：对象的创建被实现在工厂接口所暴露出来的方法中
所有工厂模式都是通过减少应用程序与具体类之间的依赖关系促进松耦合
工厂方法允许类将实例化延迟到子类进行
抽象工厂创建相关的家族，而不需要依赖他们的具体类
工厂帮助我们针对抽象编程，而不是针对具体类编程
抽象工厂模式与工厂模式的区别
建造者（Builder）模式的由来
在软件系统中，有时面临着“一个复杂对象”的创建工作，
该复杂对象通常由各个部分的子对象用一定的算法构成
这个复杂对象的各个部分经常面临着剧烈变化，但是将它们
组合在一起的算法 却相对稳定
如何应对这种变化？如何提供一种“封装机制”来隔离出
“复杂对象的各个部分”的变化，从而保持系统中的“稳定
构建算法”不随着需求改变而改变？
建造者模式的意图和适用性
意图：将一个复杂的构建与其表示相分离，使同样
的构建过程可以创建不同的表示
适用场合
需要生成的产品有复杂的内部结构
创建复杂对象的算法稳定，或建造者模式可以强
迫生成一定的顺序
当构造过程允许被构造的对象有不同的表示时
Builder：为创建一个Product对象的各个部件制定的抽象接口
ConcreteBuilder：实现Builder接口来构造和装配产品各个部件，提供一个检索产品的接口
Director：构造一个使用Builder接口的对象
Product：表示被构造的复杂对象
建造者模式的结构
建造者模式分析
优点：
使得产品的内部表象可独立变化
客户端不必知道产品内部组成的细节
每一个Builder都相对独立，而与其它Builder无关
可对构造过程更加精细控制
将构建代码和表示代码分开
缺点：
难于“分步骤构建算法”制造产品对象
Builder模式与AbstractFactory模式的区别
Builder返回完整的一个产品，而 AbstractFactory返回一系列有关系的产品
在AbstractFactory模式中，客户采用AbstractFactory生成自己要用的对象，而在建造者模式中，客户指导Builder类如何去生成对象，或
是如何和成一些类来构成建造类，侧重于一步步构造一个复杂对象，然后将结果返回。
房屋由五个部分组成：地板、墙壁、窗户、门和天花板
构建房屋的步骤固定，而具体组件（门、窗等）易变
采用建造者模式分离易变组件和稳定的构建过程
实例 1：设计游戏场景中的房屋
public abstract class House //定义一个房屋抽象类{ }
public abstract class Builder //这一部分是易变的{
public abstract void BuildFloor(); //地板public abstract void BuildDoor(); //门public abstract void BuildWindows(); //窗户public abstract void BuildWall(); //墙壁public abstract void BuildHouseCeiling() //天花板
public abstract House GetHouse();}
public abstract class GameManager{
public static House CreateHouse(Builder builder){
builder.BuildFloor();builder.BuildDoor();builder.Buildwall();builder.BuildWindows();builder.BuildHouseCeiling();
return builder.GetHouse();}
}
public class RomanHouseBuilder : Builder{
public override void BuildDoor() { }public override void BuildFloor() { }public override void BuildWindows() { }public override void BuildWall() { }public override void BuildHouseCeiling() { }public override House GetHouse() { }
}
class App{
public static void main(){
House house =GameManager.CreateHouse(new
RomanHouseBuilder());}
}
实例2：造车（作业）
原型（Prototype）模式
在软件系统中，客户希望创建一个类对象（产品）时，可能有三种情况：
知道产品具体型号(使用new运算符创建)
不知道型号，知道特定的需求(使用工厂模式)
不知道需求，但想要一个和已知对象相同的对象‐使用原型模式
意图：用原型实例指定创建对象种类，并且通过拷贝这些原型创建新的对象
适用性：
当一个系统独立于其产品创建、构成和表示时
当要实例化的类在运行时刻指定时
为了避免创建一个与产品类层次平行的工厂类层次时
原型模式的结构
Client：客户端类向原型管理器提出创建对象请求
抽象原型：它是对各种具体原型的抽象，通常由一个接口或抽象类实现
具体原型：被复制的对象。此角色需要实现抽象的原型角色所要求的接口
原型管理器：创建具体原型类的对象，记录每一个被创建的对象
用户单击调色板上任一个方块，将会返回一个对应的颜色的实例
利用OO的思想，把每一种颜色作为一个对象，并为它们抽
象出一个公用的父类
实例 1：开发调色板
使用原型模式开发调色板的结构图
优点：
（1）对客户隐藏具体产品类，减少了客户知道名字的数目
（2）允许客户只通过注册原型实例就可以将一个具体产品
类并入系统中，客户可以在运行时刻建立和删除原型
（3）具有给一个应用软件动态加载新功能的能力。由于其
独立性较高，可以很容易动态加载新功能而不影响老系
统
（4）产品类可有任意结构
缺点：每个类必须配备一个克隆方法
原型模式的应用效果分析
工厂模式：定义一个创建对象的接口，由子类决定要实
例化的具体类，工厂方法让类把实例化推迟到子类
抽象工厂模式：提供一个接口，用于创建相关或依赖对
象的家族，而不需要明确指定具体类
建造者模式：封装一个产品（复杂对象）的构造过程，
并允许按照步骤构造，向客户隐藏了产品的内部表现
单件模式：一个类只有一个实例，并提供全局访问点
原型模式：当创建给定类实例的过程很昂贵或很复杂
时，使用原型模式，向客户隐藏制造新实例的复杂性
创建型设计模式总结
关注类和对象的结构，采用继承机制来组合接口（类结构型模式），或通过组合一些对象来实现新的功能（对象结构型模式）
组合（Composite）：定义一个接口，用于单一
对象，或用于多个单一对象组成的对象组装饰（Decorator）：给对象动态添加额外的职
责，好比加上装饰物，完善其功能代理（Proxy）：有些对象由于跨网络或其他障
碍，而不能或不想直接访问另一个对象，这时候可以在客户程序和目标对象之间增加一层中间层，让代理对象来代替目标对象打点一切
结构型设计模式
享元（Flyweight）：Flyweight是一个共享对象，它可以
同时在不同上下文使用外观（Facade）：为子系统提供了一个更高层次、更简
单的接口，从而降低子系统复杂度，更易于使用和管理。外观承担了子系统中类交互的责任桥梁（Bridge）：将问题的抽象和实现分离开来实现，
通过用聚合代替继承来解决子类爆炸性增长的问题
适配器(Adapter)：将一个类的接口适配成用户所期待的
接口。一个适配器允许因为接口不兼容而不能在一起工作的类工作在一起，做法是将类自己的接口包装在一个已存在的类中
适配器模式
外观模式
装饰模式
桥接模式
享元模式
代理模式
组合模式
结构型模式
适配器模式的由来
一个team要为外界提供S类服务，但team里面没有能够
完成此项任务的member，只有team外的A可以完成这
项服务。为保证对外服务类别的一致性（提供S服务）
将A招到team内，负责提供S类服务
A不准备接受招安，可安排B去完成这项任务，并让B做好A的工作，让B工作的时候向A请教，此时，B是一个复合体（提供S服务，是A的继承弟子）
将一个类的接口，转换成客户期望的另一个接口，适配
器让原本接口不兼容的类可以一起工作
适配器模式使用过程
客户通过目标接口调用适配器的方法对适配器发出
请求
适配器使用被适配者接口把请求转换成被适配者的
一个或者多个调用接口
客户接收到调用的结果，但并未察觉这一切是适配
器在起转换作用
适配器模式的意图和适用性
意图：将一个类的接口转换成客户希望的另外一个接口，使
得原本由于接口不兼容而不能一起工作的类可以一起工作
适用场合：
使用一个已经存在的类，而它的接口不符合要求
创建一个可以复用的类，该类可以与其他不相关的类或
不可预见的类（即那些接口可能不一定兼容的类）协同
工作
使用一些已经存在的子类，但不可能通过子类化以匹配
各自接口。对象适配器可以适配它的父类接口
适配器模式分为类适配器和对象适配器
类适配器
用一个具体的Adapter类对Adaptee和Target进行匹配，
Adapter类多重继承Adaptee和Target类
Adapter可重定义Adaptee的部分行为，因为Adapter是Adaptee的一个子类
代码示例
//Target：定义Client使用的与特定领域相关的接口public interface Target { void request(); }
//Adaptee:现在需要适配的已经存在的接口public class Adaptee{ public void specificRequest(){} }
//Adapter:对Adaptee的接口与Target接口进行适配public class Adapter extends Adaptee implements Target { public void request() {
super. specificRequest();}
}
对象适配器
允许一个Adapter与多个Adaptee同时工作，即Adaptee本身以及它的所有子类（如果有子类的话）同时工作。Adapter可以一次给所有的Adaptee添加功能使用组合，不仅可以适配某个类，也可以适配该类的任何子类
代码示例
//Target：定义Client使用的与特定领域相关的接口public interface Target { void request(); }
//Adaptee:现在需要适配的已经存在的接口public class Adaptee{ public void specificRequest(){} }
//Adapter:对Adaptee的接口与Target接口进行适配public class Adapter implements Target { public Adapter(Adaptee adaptee) { super(); this.adaptee = adaptee; } public void request(){ adaptee.specificRequest(); } private Adaptee adaptee;
}
着力解决的是类实体之间的通讯关系，希望以面向对
象的方式描述一个控制流程
模版（Template）：定义了一个算法步骤，并允许
子类为一个或多个步骤提供实现。子类在不改变算
法架构的情况下，可重新定义算法中某些步骤
观察者（Observer）：定义了对象之间一对多的依
赖，当这个对象的状态发生改变的时候，多个对象
会接受到通知，有机会做出反馈
迭代（Iterator）：提供一种方法顺序访问一个聚合
对象中各个元素, 而又不需暴露该对象的内部表示
行为型设计模式
责任链（Chain of Responsibility）：很多对象由每一个对象
对其下一个对象的引用而连接起来形成一条链。请求在这个链上传递，直到链上的某一个对象决定处理此请求。
发出这个请求的客户端并不知道链上的哪一个对象 终
处理这个请求，这使系统可以在不影响客户端的情况下动态的重新组织链和分配责任
备忘录（Memento）：在不破坏封装性的前提下，捕获一
个对象的内部状态，并在该对象之外保存这个状态。这样以后就可将该对象恢复到原先保存的状态
命令（Command）：将请求及其参数封装成一个对象，作
为命令发起者和接收者的中介，可以对这些请求排队或记录请求日志，以及支持可撤销操作
状态（State）：允许一个“对象”在其内部状态改变的时候改变
其行为，即不同的状态，不同的行为访问者（Visitor）：表示一个作用于某对象结构中的各元素的
操作。可以在不改变各元素的类的前提下定义作用于这些元素的新操作解释器(Interpreter) ：给定一个语言，定义它的文法的一种表
示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子中介者（Mediator）：用一个中介对象来封装一系列的对象交
互策略（Strategy）：定义一组算法，将每个算法都封装起来，
并且使它们之间可以互换。策略模式使这些算法在客户端调用它们的时候能够互不影响地变化
模板模式 (Template method Pattern) 观察者模式 (Oberserver Pattern) 迭代子模式（Iterator Pattern ) 责任链模式（Chain of Responsibility Pattern）备忘录模式（Memento Pattern）命令模式（Command Pattern）状态模式（State Pattern）访问者模式（Visitor Pattern）中介者模式（Mediator Pattern）策略模式（Strategy Pattern）解释器模式（Interpreter Pattern）
行为型模式
策略模式的由来
多种算法实现同一功能，客户希望在运行时根据上下文选择
其中一个算法
传统策略算法的缺点
使用算法的类复杂而难于维护，尤其当需要支持多种算
法且每种算法都很复杂时问题会更加严重
不同的时候需要不同的算法，支持并不使用的算法可能
带来性能的负担
算法的实现和使用算法的对象紧紧耦合在一起，使新增
算法或修改算法变得十分困难，系统应对变化的能力很
差
将每种算法的实现都剥离出来构成一个个独立算法对象，再
从这些对象中抽象出公共算法接口， 后将算法接口组合到
使用算法类中
策略模式的意图和适用性
意图：定义一系列算法，一个个进行封装，并使其可相
互替换。策略模式使得算法可独立于使用它的客户而变
化
适用场合
在软件构建过程中，某些对象使用的算法可能多种多
样，经常改变，如果将这些算法都编码到对象中，将
会使得对象变得异常复杂；而且有时候支持不同的算
法也是一个性能负担
如何在运行时根据需要透明地更改对象的算法？如何
将算法与对象本身解耦，从而避免上述问题？策略模
式很好地解决了这两个问题
策略模式的结构
策略模式的参与者
Strategy
定义所有支持算法的公共接口
Context使用该接口调用某ConcreteStrategy定义的算法
ConcreteStrategy以Strategy接口实现某具体算法
Context用一个ConcreteStrategy对象来配置
维护一个对Strategy对象的引用
可定义一个接口来让Strategy访问它的数据
策略模式的效果分析
算法和使用算法的对象相互分离，客户程序可以在运行时
动态选择算法，代码复用性好，便于修改和维护用组合替代继承，效果更好。若从Context直接生成子类，
也可以实现对象的多种算法，但继承使子类和父类紧密耦合，使Context类难以理解、难以维护和难以扩展。策略模
式采用组合方式，使Context和Strategy之间的依赖很小，
更利于代码复用
消除了冗长的条件语句序列，将不同的算法硬编码进一个
类中，选择不同的算法必然要使用冗长的条件语句序列，采用策略模式将算法封装在一个个独立的Strategy类中消除
了这些条件语句
算法的动态选择，Strategy模式可以提供相同行为的不同实
现，客户可以根据不同的上下文从不同的策略中选择算法
客户必须了解不同的Strategy，一个客户要选择一个合适的
Strategy就必须知道这些Strategy到底有什么不同
Strategy和Context之间的通信开销加大，根据算法的需要，
Context必须向每个不同的具体Strategy类实例传递不同的参
数，因此Strategy接口就要传递所有这些不同参数的集合，
导致Context会创建和传递一些永远用不到的参数
增加了类和对象数目，因为各种算法被抽取出来单独成
类，导致了对象数目增加，这种情况在算法较多时更加严
重
利用接口如何？
分开变化和不会变化的部分
实现鸭子的行为
Another Example: Diff Sort Algos为多个对象封装了不同的排序算法，允许客户动态改变不同的排序策略
Quicksort、Shellsort和Mergesort排序法
图书折扣的例子有些图书没有折扣
有些图书提供一个固定1元的折扣
有些图书提供一个百分比的折扣
界面设计（UI Designs）1. What is UI?2. UI Design Models3. Design Principles 4. Golden Rule5. Visual Designs
界面设计很复杂
User friendly for anticipated users.
System users often judge a system by its interface rather than its functionality.
A poorly designed interface can cause a user to make catastrophic errors.
Poor user interface design is the reason why so many software systems are never used
Some Facts for UI ……
To suggest some general design principles for user interface design
To explain different interaction styles and their use
To explain when to use graphical and textual information presentation
To explain the principal activities in the user interface designprocess
To introduce usability attributes and approaches to system evaluation
Objectives
User familiarityThe interface should use terms and concepts which are drawn from the experience of the people who will make most use of the system
ConsistencyThe system should display an appropriate level of consistency. Commands and menus should have the same format, command punctuation should be similar, etc.
Minimal surpriseIf a command operates in a known way, the user should be able to predict the operation of comparable commands
Design principles of user interface
RecoverabilityThe interface should include mechanisms to allow users to recover from errors. This might include an undo facility, confirmation of destructive actions, 'soft' deletes, etc.
User guidanceThe interface should provide meaningful feedback when errors occur and provide context‐sensitive user help facilities
User diversityInteraction facilities for different types of user should be supported. For example, some users have seeing difficulties and so larger text should be available
Web 2.0Facilitate participatory information sharing, interoperability, user‐centered design and collaboration on the world wide web.User can provide the data that is on a web 2.0 and exercise some control over that data.e.g.: social networking sites, video sharing sites, Wikis, (micro‐)blogs, etc.
Web 3.0
172
http://www.creativefolks.net/
173
http://www.moma.org/exhibitions/2004/tallbuildings/index_f.html
174
http://w
ww.bh9
9.com/
175
http://www.armani.com/ga_menu/EN/home.html
176
TEXTsMost of the information are conveyed through texts, especially websites.
Careful layout and creational designs can make the website stand out from the peers
Combine texts with FLASH, to embed the texts in the small videos can help a lot.
Besides main texts, website navigator, headings etc. are all composed of texts
177
http://www.gardens‐co.com/v1/
178
http://jonesingfor.com/#/HOME/
179
Font design for businesses is very challenging, that eventually serve as part of the overall business.
In UI design, there is no need \to have the designer be professional in font design, but he/she needs to know how to use them.
180
Logo and Slogans http://www.androians.com/vegas/
181
In general, maximum THREE types of fonts are used in a webpage. If more types of fonts have to be used, try to use those belong to a category.
182
Besides, we can use Color contrast, size contrast, and density contrastto increase the beauty of the layout
On the same page, texts need to be consistent
183
184
185
Image is more intuitive than the texts, also the core elements of UI design, the majority of visual works mostly have excellent graphic design and images
IMAGEs
Through the use of good graphics or pictures, closely seize the viewer's eye.
A good image is worth a thousand words!
186http://www.8yu.com/
187http://www.8yu.com/
188http://www.8yu.com/
189http://www.8yu.com/
190http://www.8yu.com/
191http://www.8yu.com/
192http://www.8yu.com/
193http://www.8yu.com/
194http://www.8yu.com/
195
However, we cannot only emphasize the importance of visual aesthetics, and only beautiful graphics or pictures, but ignoring the core objectives of a website
‐ efficient and accurate information delivery
the customer will not be satified.
196
DRAFT
197
FINAL
198
To design the website, we must be very clear WHY:
who are the target users? What can they get from the website?What do we have as a return from the website, or biz model?
Even with similar objectives, the specific design will also be based on the customer's different requirements
product sales or business services?
Design Goal and Strategy
WICKED SUNGLASSES is a special e‐commerce website to sell sunglasses from a variety of different brands
Also to sell sunglasses, BLINDE only has 5 products, all coming from The Matrix 2
What about to SWAP the website designs for WIKED SUNGLASSES and BLINDE?
To make sure what is the goal of the design, is primarily to find the clients’ advantages, features, and business models.
Sometimes, clients are not sure about what materials to provide, in this case designers can ask the following questions.
Question 1: what is your goal to build the website?
Possible answers:
Advertisement for our provided servicesE‐commerce, sales
For cultures and ideasTo establish a platform for suppliers and customersTo provide public services
*multiple choices* are possible
LENOVO’s website is to primarily describe the products, but also support e‐commerce, and to promote its brand
blood
Blood knowledge
Question 2: what is the scale of your website?
Possible answers:
very small, to just place the materials we have now, unlikely to add new stuff futureStart from small, then may grow bigger, and finally has very rich contents
Very complicates, many columns
Rich resources, rapid updates and grow
Not quite sure at this point, will see
The size of the website will determine the design structure
If the website will experience rapid updates and grow, design has to reserve space for the future and with flexible structures
For example, vertical columns may help if many contents
An example from LENOVO: vertical columns for its rich products
http://www.ray-ban.com/China/
A glass brand: RAY‐BAN (easy to add new products)
http://www.ray-ban.com/China/
Question 3: what are the common features of the users?
Possible answers:
Distributors and end‐users。
Youth from 15‐30
Monthly income higher than 5000 RMB or white collarsArt students or fans
Male or female?
Foreigners only
Question 4: what is the business model?
Possible answers:
website itself will not make money, if clients are interested, they will order in another channel
advertisement and online gaming
users can pay directly online
we sell “information”, e.g., VIP members can have more information than normal usersno income, just for fun
This question is to help designers to understand the expectationof the clients on this website, and in turn to change the design for this purpose
Question 5: How about the used technologies?
Possible answers:
full FLASH, fancy
full HTML will be sufficient
welcome page in FLASH, then static inside or some small flash
3D 360 degrees, product show, FLASH for product descriptionspartly in PHP/ASP
Toyota AYGOD with 360 degrees show
http://www.toyota-europe.com/cars/new_cars/aygo/index.aspx
What is inside Nike “23”?
http://www.nike.com/jumpman23/xx3/cnCN/
Question 6: what about design style?
Possible answers:
modern
professional, rich content, not that fancy
Lively, bright colors, like fruit sugar ...
I don’t like blue, just NO blue pls
shining, I want it to be out of ppl’s imagination!
http://www.tsred.com/
Target Users
Thailand Travel from Japan http://www.thailandtravel.or.jp/studytour/
下次课安排请同学们准备PPT上来讲剩下的几个设计模式
免第二次作业，且课堂参与激励部分给满分
10位同学，每人10分钟（5-8页ppt），讲清楚：
什么是XYZ模式？如何使用？结构？实例？优缺点？
周二前通过邮件报名：[email protected]，写清楚你想讲哪个模式
周三我会回复大家确认，以收到邮件先后顺序为准
如没人报名，将请第一次作业优异者讲授
命令模式状态模式
访问者模式中介者模式
解释器模式
外观模式装饰模式桥接模式享元模式代理模式组合模式
模板模式观察者模式迭代子模式
责任链模式备忘录模式
