《GOF设计模式》—创建型模式—Delphi源码示例：基于创建型模式的迷宫

示例：基于创建型模式的迷宫

实现：

考虑到MazeGame的成员函数CreatMaze所做的仅是创建一个有两个房间的迷宫，它是相当复杂的。显然有办法使它变得更简单。例如，Room的构造器可以提前用墙壁来初始化房间的每一面。但这仅仅是将代码移到了其他地方。这个成员函数真正的问题不在于它的大小而在于它不灵活。它对迷宫的布局进行硬编码。改变布局意味着改变这个成员函数，或是重定义它—这意味着重新实现整个过程—或是对它的部分进行改变—这容易产生错误并且不利于重用。

创建型模式显示如何使得这个设计更灵活，但未必会更小。特别是，它们将便于修改定义一个迷宫构件的类。

假设你想在一个包含（所有的东西）施了魔法的迷宫的新游戏中重用一个已有的迷宫布局。施了魔法的迷宫游戏有新的构件，像DoorNeedingSpell，它是一扇仅随着一个咒语才能被锁上和打开的门；以及EnchantedRoom，一个可以有不寻常东西的房间，比如魔法钥匙或是咒语。你怎样才能较容易的改变CreateMaze以让它用这些新类型的对象创建迷宫呢？

这种情况下，改变的最大障碍是对被实例化的类进行硬编码。创建型模式提供了多种不

同方法从实例化它们的代码中除去对这些具体类的显式引用：

•如果CreateMaze调用虚函数而不是构造器来创建它需要的房间、墙壁和门，那么你可以创建一个MazeGame的子类并重定义这些虚函数，从而改变被例化的类。这一方法是FactoryMethod模式的一个例子。

•如果传递一个对象给CreateMaze作参数来创建房间、墙壁和门，那么你可以传递不同的参数来改变房间、墙壁和门的类。这是AbstractFactory模式的一个例子。

•如果传递一个对象给CreateMaze，这个对象可以在它所建造的迷宫中使用增加房间、墙壁和门的操作，来全面创建一个新的迷宫，那么你可以使用继承来改变迷宫的一些部分或该迷宫被建造的方式。这是Builder模式的一个例子。

•如果CreateMaze由多种原型的房间、墙壁和门对象参数化，它拷贝并将这些对象增加到迷宫中，那么你可以用不同的对象替换这些原型对象以改变迷宫的构成。这是Prototype模式的一个例子。

剩下的创建型模式，Singleton可以保证每个游戏中仅有一个迷宫而且所有的游戏对象都可以迅速访问它—不需要求助于全局变量或函数。Singleton也使得迷宫易于扩展或替换，且不需变动已有的代码。

代码：

略