《设计模式》课件

《设计模式:可复用面向对象软件的基础》是引导读者走出软件设计迷宫的指路明灯，凝聚了软件开发界几十年设计经验的结晶。四位顶尖的面向对象领域专家精心选取了最具价值的设计实践，加以分类整理和命名，并用简洁而易于重用的形式表达出来。本书已经成为面向对象技术人员的圣经和词典，书中定义的23个模式逐渐成为开发界技术交流所必备的基础知识和语汇。 书评 这本书的目的就是将面向对象软件的设计经验作为设计模式记录下来。每一个设计模式系统地命名、解释和评价了面向对象系统中一个重要的和重复出现的设计。我们的目标是将设计经验以人们能够有效利用的形式记录下来。鉴于此目的，我们编写了一些最重要的设计模式，并以编目分类的形式将它们展现出来。 序言 前言 读者指南 第1章 引言 1.1 什么是设计模式 1.2 Smalltalk MVC中的设计模式 1.3 描述设计模式 1.4 设计模式的编目 1.5 组织编目 1.6 设计模式怎样解决设计问题 1.6.1 寻找合适的对象 1.6.2 决定对象的粒度 1.6.3 指定对象接口 1.6.4 描述对象的实现 1.6.5 运用复用机制 1.6.6 关联运行时刻和编译时刻的结构 1.6.7 设计应支持变化 1.7 怎样选择设计模式 1.8 怎样使用设计模式 第2章 实例研究：设计一个文档编辑器 2.1 设计问题 2.2 文档结构 2.2.1 递归组合 2.2.2 图元 2.2.3 组合模式 2.3 格式化 2.3.1 封装格式化算法 2.3.2 Compositor和Composition 2.3.3 策略模式 2.4 修饰用户界面 2.4.1 透明围栏 2.4.2 MonoGlyph 2.4.3 Decorator模式 2.5支持多种视感标准 2.5.1 对象创建的抽象 2.5.2 工厂类和产品类 2.5.3 Abstract Factory模式 2.6 支持多种窗口系统 2.6.1 我们是否可以使用Abstract Factory模式 2.6.2 封装实现依赖关系 2.6.3 Window和Windowlmp 2.6.4 Bridge模式 2.7 用户操作 2.7.1 封装一个请求 2.7.2 Command类及其子类 2.7.3 撤消和重做 2.7.4 命令历史记录 2.7.5 Command模式 2.8 拼写检查和断字处理 2.8.1 访问分散的信息 2.8.2 封装访问和遍历 2.8.3 Iterator类及其子类 2.8.4 Iterator模式 2.8.5 遍历和遍历过程中的动作 2.8.6 封装分析 2.8.7 Visitor类及其子类 2.8.8 Visitor模式 2.9小结 第3章 创建型模式 …… 第4章 结构型模式 …… 第5章 行为模式 …… 第6章 结论 …… 在OO Design中，reueable 是一个非常重要的组成部分。也就是说如何 让你的code能被其他的程序利用是design的关键部分！ 让code reuseable有多种办法，除了oo language本身的hirechay等特性外，把现实中的问题记录下来，然后发表，可防止重复的开发过程。 Design Pattern就是一些已被记录的方法，并且有系统的描述。 根据 Christopher Alexander “每个pattern描述了在特定环境下发生了很多次的问题，然后你便可以描述这些问题的共性并提供解决的办法” 这就好像砖头一定是方的，这样他便能很容易地和其他砖头一起被砌成房子。 Java在resuseable方面有突出的表现，如interface的引入，使很多在 c++中暧昧的继承关系得到有效的解决。应该来说，java语言的本身拥有很多OO的嫡系血统，整合了现代的编程方法。当然我们都了解有关 implementation的缺陷使得它的应用受到很大限制。但从design的角度说，它的确是一种非凡的东西。这也是为什么我想用它来解释pattern的原因。 实例1：在sun java的native lib中，我们随处可见design pattern的身 影。比如在新的event model中，Listener 便是一种叫Observer的 pattern(MFC 中的notification 也是出于其中) 实例2：JFC UI种的plugable Look & Feel 结合了Abstract Factory 和 Bridge Pattern。前者能产生一组widget factory，而后者则提供了建立在一致interface上具体的实现方法。 当然在实际的开发中你可能遇到各种问题，如果你能把它们系统地记录下来并提供实际的解决办法，这就可能是一种新的pattern。但记住 pattern是能解决一类问题的方法，而不是一个问题。所以对一类问题的共性归类很重要。在以后我会介绍如何来做这方面的工作。 虽然Design Pattern源自于Object Oriented Design的方法，但它又是完全基于实践的。因此选择何种语言及上下文的关系对与读者至关重要。基本上每种Pattern都会有相应的UML(1)和Interactive Diagram(2)，同时配以简洁的示范代码来表达作者在当时的想法。 可以想象一种Pattern的应用面决定不止以某种特定的场景。打个比方，Composite Pattern这种建立于包含关系的Object structure可以表达很多类事物，如桌面应用文件的结构，网络中分布对象的集合等等，它并没有局限于某类应用。 而基于不同的实现语言，Pattern的实现也会很不一样。我们以后会提到的Singleton在C++中的实现和Java中的实现有很大的区别。 大致上每种Pattern都包含了一下几个部分： Pattern Name: 名字 Problem: 讲述Pattern的来源及上下文关系。问题的种类可有很多种，有时我们可能想用Objects来表达某种算法，而有时确是为了如何表达Objects之间的结构。而且在一些情况下我们还要告诉读者在碰到这个问题前，我们已经用何种方法解决了前因。 The Solution: 解决之道。包括用哪些元素来做Design，Element之间的关系，结构，调用的顺序，变种等等。为了清晰地表达一个Design，往往辅助以UML，Interactive Diagram，Code Sample等。因为Pattern 就像一种Template，可以应用于不同的场合，所以Solution不应该是描述一种特定的设计。 The Consequence: 结果。这是最容易被人忽视的一点。因为Design需要的Pattern并不往往是最有效率的方案，在一些情况下，我们牺牲很有效率的方案仅仅是为了让别人能看懂我们的程序。(个人认为这很重要)所以我们一定要注明在那些地方我们做了妥协。并尽可能地预计所会产生的正面及负面效果。