设计模式示例.pptVIP

第12章 设计模式示例 12.1 Observer模式 12.2 Observer模式的实现 12.3 示例代码 12.4 上机指导 12.1 Observer模式 前面各章已经分别对面向对象程序设计的基本概念、基本原理、使用C++程序设计语言实现面向对象的程序设计的具体技术以及面向对象分析方法做了介绍。在本章中将通过一个叫做Observer模式的设计示例说明在面向对象程序中模式的概念，并讨论设计模式在面向对象程序设计中的作用和应用。 12.1.1 设计模式 面向对象程序设计中的设计模式，简单地说，就是一些设计面向对象软件的经验总结。是某个具体形式的一种抽象。在特殊的非任意的环境中，该形式不断地、反复地出现。模式是在某种特定的场景(context)下对某个不断重复出现的问题的解决方案。模式本身并没有任何的创新性，它仅仅是对于一些已经被证明为优秀的解决方法的归类、总结，目的是为了重用该解决方案而又不用做重复的劳动。其中，“特定场景”和“重复”两个限定词非常关键，“特定场景”给出了什么时候以及为什么使用一个模式，“重复”说明了模式的可重复性从而可以被重用。 一般地，软件体系结构的子系统通常由几个更小的体系结构单元构成，这些单元就可用设计模式来描述。设计模式(Design Pattern)提供了一个用于细化软件系统的子系统或组件或它们之间关系的图。它描述了通信组件的公共再现结构。通信组件可用于解决特定语境中的一个一般设计问题。设计模式在规模上比体系结构模式小，但独立于特定编程语言或编程范例。这里介绍的Observer模式属于设计模式的范畴。 惯用法依赖于模式描述的语言特征，所以前面两类模式是和语言无关的。 设计模式是经常发生的设计问题的解决方案。它描述了如何利用一组类来解决问题。通常模式不包含算法，它关注的是类之间的关系。通过使用设计模式，可以利用已证实的、能导致更佳设计和更快实现的解决方案。设计模式还有利于长期的代码维护。 关于模式及其描述，R.Gabrel曾经给出一个简洁而又清楚的定义： “ 每一个模式都有三部分规则。这些规则给出了某一个环境、某一个在该环境中重复发生并要求权衡的系统和某一个允许这些权衡得以解决的软件形式之间的关系” 。可以按照这3个规则从3个方面描述一个模式。Erich 建议使用的模式描述元素如下。 模式名称：一个简短的富有表现力的名称； 意图：模式要做什么事； 别称：该模式的其他名字； 动机：解决的问题及该模式如何解决问题的实例； 适用性：该模式所应用的场景； 结构：代表该模式的类图(结构图)； 参与者：模式中的类及其职责的描述 协作：描述参与者之间的交互(用序列图)； 效果：描述交替使用、设计选择和使用该模式的影响。 现在对模式描述的许多的形式化方法都是从这个基础派生出来的。 由于模式是经验的总结，每个人对同样的经验会有不同的总结，因此，模式有重要的人为因素。好的模式追求实用性和美学原则。在面向对象程序设计中使用的模式应该是一个“好”的模式。一个好的模式必须满足如下条件。 (1) 它解决一个问题。 从模式可以得到问题的解，而不仅仅是给出原则和抽象。 (2) 它是一个被证明了的概念。它通过记录得到解，而不是通过推理得到解。 (3) 解并非是显然的。许多问题的解是通过最基本的原则得到的。好的模式应该间接得到解。 (4) 它描述了一种关系。它不仅仅描述模块，它也给出了更深层的结构和机理。 12.1.2 Observer模式 Observer模式也称为依赖模式，更常见的是叫做发布－订阅模式，它在界面设计方面应用广泛。众所周知，面向对象开发的一个主导原则是，在给定的应用程序中正确地分配任务。一般地，一个对象只应做一件事，而且要将它做好。使用这种方法可确保在对象之间划定清晰的界限，因而可提供更高的重用性和系统可维护性。一个正确划分任务特别重要的领域就是，用户界面和基础业务逻辑之间的交互。 Observer模式就是从这类常见问题中抽象出来的解决方案。这类常见问题的具体例子是图12.1所示的网上商店。 图12.1 网上商店应用 按照Erich Gamma等人在“设计模式—面向对象软件重用基础”中对Observer模式的论述，Observer模式的意图是，定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。而它的动机是，当将一个系统分割成一系列相互协作的类时，避免为了维护相关对象间的一致性而使各个类紧密耦合，因为这样降低了它们的可重用性。 Observer模式适用于以下任一情况： (1) 一个抽象模型有两个方面，其中的一个方面依赖于另一方面。将这二者封装在独立的对象中以使它们可以各自独立地改变和重用；