C#设计模式PPT-0423.pptVIP

第14章构造型模式介绍 创建型模式抽象了实例化过程。它们帮助一个系统独立于如何创建、组合和表示它的那些对象。一个类创建型模式使用继承改变被实例化的类，而一个对象创建型模式将实例化委托给另一个对象。 随着系统演化得越来越依赖于对象复合而不是类继承，创建型模式变得更为重要。当这种情况发生时，重心从对一组固定行为的硬编码（ h a r d - c o d i n g）转移为定义一个较小的基本行为集，这些行为可以被组合成任意数目的更复杂的行为。这样创建有特定行为的对象要求的不仅仅是实例化一个类。 在这些模式中有两个不断出现的主旋律。 第一，它们都将关于该系统使用哪些具体的类的信息封装起来。第二，它们隐藏了这些类的实例是如何被创建和放在一起的。整个系统关于这些对象所知道的是由抽象类所定义的接口。因此，创建型模式在什么被创建， 谁创建它，它是怎样被创建的，以及何时创建这些方面给予你很大的灵活性。它们允许你用结构和功能差别很大的“产品”对象配置一个系统。配置可以是静态的（即在编译时指定），也可以是动态的（在运行时）。 有时创建型模式是相互竞争的。例如，在有些情况下P r o t o t y p e或Abstract Factory用起来都很好。而在另外一些情况下它们是互补的： B u i l d e r可以使用其他模式去实现某个构件的创建。P r o t o t y p e可以在它的实现中使用S i n g l e t o n。 例：一个电脑游戏创建一个迷宫 这个迷宫和游戏将随着各种模式不同而略有区别。有时这个游戏将仅仅是找到一个迷宫的出口；在这种情况下，游戏者可能仅能见到该迷宫的局部。有时迷宫包括一些要解决的问题和要战胜的危险，并且这些游戏可能会提供已经被探索过的那部分迷宫地图。 每一个房间有四面，我们使用C + +中的枚举类型D i r e c t i o n来指定房间的东南西北：enum Direction {North, South, East, West}; enum Direction {North, South, East, West}; 创建型模式显示如何使得这个设计更灵活，但未必会更小。特别是，它们将便于修改定义一个迷宫构件的类。 假设你想在一个包含（所有的东西）施了魔法的迷宫的新游戏中重用一个已有的迷宫布局。施了魔法的迷宫游戏有新的构件，像D o o r N e e d i n g S p e l l，它是一扇仅随着一个咒语才能被锁上和打开的门；以及E n c h a n t e d R o o m，一个可以有不寻常东西的房间，比如魔法钥匙或是咒语。你怎样才能较容易的改变C r e a t e M a z e以让它用这些新类型的对象创建迷宫呢？ 这种情况下，改变的最大障碍是对被实例化的类进行硬编码。创建型模式提供了多种不同方法从实例化它们的代码中除去对这些具体类的显式引。 ? 如果C r e a t e M a z e调用虚函数而不是构造器来创建它需要的房间、墙壁和门，那么你可以创建一个M a z e G a m e的子类并重定义这些虚函数，从而改变被例化的类。这一方法是Factory Method模式的一个例子。 ? 如果传递一个对象给C r e a t e M a z e作参数来创建房间、墙壁和门，那么你可以传递不同的参数来改变房间、墙壁和门的类。这是Abstract Factory模式的一个例子。 ? 如果传递一个对象给C r e a t e M a z e，这个对象可以在它所建造的迷宫中使用增加房间、墙壁和门的操作，来全面创建一个新的迷宫，那么你可以使用继承来改变迷宫的一些部分或该迷宫被建造的方式。这是B u i l d e r模式的一个例子。 ? 如果C r e a t e M a z e由多种原型的房间、墙壁和门对象参数化，它拷贝并将这些对象增加到迷宫中，那么你可以用不同的对象替换这些原型对象以改变迷宫的构成。这是P r o t o t y p e模式的一个例子。 剩下的创建型模式， S i n g l e t o n，可以保证每个游戏中仅有一个迷宫而且所有的游戏对象都可以迅速访问它—不需要求助于全局变量或函数。S i n g l e t o n也使得迷宫易于扩展或替换，且不需变动已有的代码。 第15章 BUILDER（生成器） —对象创建型模式 1. 意图 将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。 2. 动机 一个RT F（Rich Text Format）文档交换格式的阅读器应能将RT F转换为多种正文格式