目录
第二章 实例研究:设计一个文档编辑器
Lexi : 基于Calder开发的文本编辑应用Doc的。
本章主要介绍了设计模式的一种实际应用场景以及设计模式是如何解决设计问题的。
2.1 设计问题
我们将考察Lexi设计中的七个问题:
- 文档结构
- 格式化
- 修饰用户界面
- 支持多种视感(look-and-feel)
- 支持多种窗口系统
- 用户操作
- 拼写检查和连字符
2.2 文档结构
该小节主要讲解文档物理结构的表示问题
为了匹配文档物理结构,文档内部应支持如下几点:
8. 保持文档的物理结构
9. 可视化生成和显示文档
10. 根据显示位置来映射文档内部表示的元素
此次之外,还有一些限制条件:
11. 一致对待文本和图形
12. 不应过分强调内部表示中单个元素和元素组之间的差别
13. 应考虑和权衡这个或其他潜在的彼此矛盾的限制条件
这里介绍几种权衡文档结构的方法
1、递归组合
2、图元
图元的三大基本责任(1)怎样画(2)占用多大空间(3)父图元和子图元是什么
两种操作:
Intersects操作–判断一个指定的点是否与图元相交
Child操作–返回给定Index的子图元(如有),应内部使用二非直接访问子数据结构。
3、组合模式
2.3 格式化
该小节主要讲解如何构造一个特殊物理结构
封装格式化算法
Compositor和Composition
策略模式
在对象中封装算法是Strategy模式的目的。Composition就是Compositor策略的环境。
2.4 修饰用户界面
- 透明围栏(Transparent Enclosure)
透明围栏结合了以下两个概念:
(1)单子女(单组件)组合
(2)兼容的接口
围栏能通过在代理操作之前或之后添加一些自己的操作来修改组件的行为,也能有效地为组件添加状态。 - MonoGlyph
为了使透明围栏这个概念具象化,我们定义Glyph的子类MonoGlyph作为所有像Border这样“起修饰作用的图元”的抽象类。
例如,MonoGlyph实现Draw操作如下:
void MonoGlyph :: Draw(Window* w){
_component->Draw(w);
}
- Decorator模式
Decorator模式描述了以透明围栏来支持修饰的类和对象的关系。
2.5 支持多种观感标准
一个运行于多个平台的应用程序必须符合各个平台的用户界面风格
- 对象创建的抽象
- 工厂类和产品类
创建工厂实例代码:
GUIFactory* guiFactory;
const char* styleName = getenv("LOOK_AND_FEEL");
if(strcmp(styleName,"Motif") == 0){
guiFactory = new MotifFactory;
}else if(strcmp(styleName,"Presentation_Manager") == 0){
guiFactory = new PMFactory;
}else{
guiFactory = new DefaultGUIFactory;
}
- Abstract Factory模式
2.6 支持多种窗口系统
1、封装实现依赖关系
2、Bridge模式
2.7 用户操作
1、封装一个请求
2、Command类及其子类
3、撤销和重做
4、命令历史记录
5、Command模式
2.8 拼写检查和断字处理
1、访问分散的信息
2、封装访问和遍历
3、Iterator类及其子类
4、Iterator模式
5、遍历和遍历过程中的动作
6、封装分析
7、Visitor类及其子类
8、Visitor模式
2.9 小结
Lexi的设计中使用了八种不同模式:
1、Composite 表示文档的物理结构
2、Strategy 允许不同的格式化算法
3、Decorator 修饰用户界面
4、Abstract Factory 支持多视感标准
5、Bridge 允许多个窗口平台
6、Command 支持撤销用户操作
7、Iterator 访问和遍历对象结构
8、Visitor 允许无限扩充分析能力而不会使文档结构的实现复杂化