学习笔记

DataSet点滴

Abbey的小匣子 — Wed, 28 Feb 2007 13:16:00 GMT

DataSet是ADO.Net中相当重要的一个类。最近在学习Duwamish的过程中，自己也尝试着利用强类型的DataSet进行数据封装和传递。其间遇到了一些小问题，小结如下：

将数据封装入一个DataSet对象的典型过程，先New再Add

MyDataSet ds = new MyDataSet();
MyDataSet.MyTableRow row = ds.MyTable.NewMyTableRow();

row.ID = 1;
row.Name = "Mike";
row.Birthday = new DateTime(1985,1,20);
row.Address = "Road 14 in Beijing";

ds.MyTable.AddMyTableRow(row);

数据按上述形式进行封装后，这个row便已属于该DataSet与Table，因此不能通过dsAnother.AddRow()或以其他方式与其他DataSet建立关联，否则会触发一个异常。

在DataSet的Table类中有一个Select()方法，该方法返回与指定条件匹配的Row的数组DataRow[]。这个条件用一个字符串表示，形式与Trans-SQL的查询条件构造一致，比如：Name = 'Mike'这样的一个串。Select()有4种重载形式，支持排序条件。使用Select()时需要注意的有几点：

1. Select()在没有匹配Row时，仍返回一个空的DataRow[]，而不是null。

MyDataSet.MyTableRow[] result = (MyDataSet.MyTableRow[]) ds.MyTable.Select("Name = 'Mike'");

//错误的检查方式
if (result == null)
    MessageBox.Show("No match record");
else
    //

//正确的检查方式
if (result.Length == 0)
    MessageBox.Show("No match record.");
else
    //

2. 传递给Select()的查询条件字符串如果不符合语法结构或者无法被解释，会触发两类异常：System.Data.EvaluateException 与 System.Data.SyntaxErrorException。

你可以试试将上述示例代码中的“Name = 'Mike'“改为“Name = Mike“(删除Mike两边的单引号)试试。

3. Select()返回的DataRow[]，其中每个元素Row，仍旧属于该方法所属的DataSet，而不是一份拷贝。因此对这些元素的操作仍旧会改变其源DataSet中的相应内容。MSDN里对这部分没有阐述，害我以为是一份拷贝，瞎折腾了半天。

利用DataSet读写XML文件时，要注意：

1. 尽量保证ds.ReadXml()与ds.AcceptChanges()、ds.WriteXml()配对使用。否则重复地使用ds.ReadXML()读入数据会触发一个异常。

我的异常是在这样的情形下发生的：在Constructor中调用了一次ReadXml()将已有数据读入一个DataSet，之后在一个方法内部的一开始又不小心调用了一次ReadXml()。

2. 如果是要利用一个XML文件保存数据，第一次添加数据时，不用ReadXml()，而应直接WriteXml()生成.xml文件。不要尝试自己手工建立一个空白的.xml文件，这可能会触发异常System.Xml.XmlException。

这些是我在做练习用的例子时遇到的问题，在本机MSDN中又没有这些提示，都是自己一步步摸索出来的，虽然方法笨了点，不过能省下买什么ADO.Net大全之类书的银子未尝不是件好事。

*20070807 更新

四个月的今天晚上，正是老婆在产床上挣扎的时候，回头想来真是百般滋味。这周放假，于是忙里偷闲，又来鼓捣DataSet。在强类型的DataSet里，遇到要访问某一行中某一字段的值时，应该是这样的表达式：DataSet.DataTable[index].ColumnName;可别象我，傻傻的还用类型转换：((DataSet.DataRow)(DataSet.DataTable.Rows[index])).ColumnName;

还有就是在利用DataAdapter进行Fill时，要Fill表，而不是DataSet。即: adapter.Fill(dataset.DataTable); 而不能是 adapter.Fill(dataset);

Duwamish 7.0析要

Abbey的小匣子 — Mon, 26 Feb 2007 05:27:00 GMT

VC++6.0企业版提供的多层设计范例Hopper Island News，不知有多少人认真看过，当时正在学习ADO和COM的我，还为此整理了几篇译文。进入了.Net时代，Microsoft出于各种目的，又向我们提供了一个叫做Duwamish的经典示例。这个模拟网上书店的Duwamish历经了多个版本更迭，现在的最新版本是7.0。其架构模式是典型的B2C模式，UI采用Web，后台的数据库用SQL Server作支持。

Duwamish 7.0源代码提供了Visual Basic.Net与Visual C#两个版本。要阅读其源码，需要操作系统提供IIS和ASP.Net服务，Visual Studio.Net也需要安装相应的Web开发组件。Duwamish 7.0的安装包在Visual Studio.Net企业版安装目录中下的Enterprise Samples目录中，直接运行后会将源码解压在该目录中。

安装解压后Duwamish的源码主要分布在Web、SystemFramework、Business\Facade、Business\Rules、Common、Common\Data、DataAccess这几个目录中，其完整的解决方案也是完全按这个目录结构搭建的，在IDE中即可一目了然。DataBase中是安装SQL数据库的脚本文件等。

在MSDN上有一篇相关的文章，可以对阅读和理解Duwamish的源码有些帮助—《Duwamish深入剖析-结构篇》

学习Duwamish，我只选择了其中的Customer（顾客）管理作为目标，故以下都以其为表述的重心。

Duwamish的分层

--UI层（Web）
--->Business层（含Facade、Rules、Common、SystemFramework等）
   --->DataAccess层（DataAccess）

同时为了在各层间交换顾客数据，建立了一个强类型的DataSet——CustomerData。

---------------------

1. 在最底的DataAccess层，使用了一个类Customers，该类包含一个SqlDataAdapter dsCommand。利用这个Adapter，数据访问对象Customers在取得与数据库的连结后，利用内部生成的若干SqlCommond，调用数据库的存储过程完成数据更新和查询。

Customers的主要接口：LoadCustomerByEmail()、UpdateCustomer()、InsertCustomer()

---------------------

2. 在Business层中，又细划了几部分：

(1)直接与UI层Web交互的是BusinessFacade层，BusinessFacade应该说是实质意义上的承上启下的Business层，因为由它负责将UI请求分派给Rules、DataAccess层去实现。

而Duwamish的主要业务规则放到了BusinessRules层。Rules层的类是Customer，它要负责检查传递给它的参数是否符合业务规则中的形式要求，以及参数的有效性。当然Customer仍是将数据访问工作交给了DataAccess层的Customers去完成。

Customer的主要接口：Insert()、Update()

(2)Facade层的类是CustomerSystem，它从Web层接收用户输入的数据或者请求，在其内部进行分类：

    i)查询类操作，直接调用DataAccess层Customers的接口实现。比如GetCustomerByEmail()就调用了Customers.LoadCustomerByEmail()；

    ii)更新、插入类操作，调用Rules层Customer的接口实现。比如CreateCustomer()调用了Customer.Insert()。

CustomerSystem的主要接口：GetCustomerByEmail()、UpdateCustomer()、CreateCustomer()

在Business层中，还有Common与SystemFramework两个部分。上文中的强类型DataSet——CustomerData就定义在Common中。同时，Common与SystemFramework为保证Duwamish的灵活性以及调试的方便，提供了ApplicationLog、ApplicationAssert、ApplicationConfiguration、DuwamishConfiguration等类，我还未细究。

---------------------

3. 作为UI层的Web，自己去看吧。

毕竟UI要做成什么样的，纯属个人喜好。（老实说，是我看得头疼了，不知该怎么写这部分）

Duwamish中的数据传递与异常处理

在Duwamish各层穿梭的数据，主要以CustomerData形式存在。CustomerData既对应了数据库意义上的DataSet，也反映了问题域上的一个实体。回想自己曾经的设计，经常要在一个问题域对象与数据库对象间建立相互的转换映射，真是汗颜。

需要注意的是，UI层向其下层传递的参数仍是对应DataSet各字段值的string、int等类型，而不是一个构造好了的DataSet对象。另一方面，UI层却必须要知道如何从下层返回的DataSet对象中提取信息，即UI层对DataSet的结构必定是清楚的。

---------------------

在Duwamish的各层，我并没有看到太多的try-catch处理，这与曾经的Hopper Island News有着很大的不同。

1. DataAccess层的Customers自己负责处理数据库异常，向上层调用者返回象征操作成功与否的true/false，或者CustomerData/null（以下均以bool/null进行表达）。

2. Business的CustomerSystem、Customer也采用了类似的bool/null方式向上层返回操作结果。但为了提供更丰富的错误信息（不是异常），比如Email地址不唯一等，Rules层的Customer通过设置CustomerData中Row的RowError、ColumnError参数向上层反馈。

*20070811更新

无意间在网上找到了Rickie Lee的Blog，在那里找到了他写的一系列深入剖析Duwamish的文章，有空好好看看。

链接：http://www.cnblogs.com/rickie/category/12456.html

对Flyweight的认识

Abbey的网络日志 — Fri, 08 Sep 2006 11:00:00 GMT

Flyweight本来是不太复杂的一个Pattern，却因为我看的几本书中都没有详尽的范例，一直不得其解。今天在ProgrammerHeaven上下载了一个示例程序，才恍然大悟。

Flyweight Pattern是用来有效减少重复性对象的。按我现在的理解，Flyweight Pattern就象是Cache的工作方式，或者说Cache正是Flyweight Pattern的典型应用。

CPU Cache相信很多人都了解的，包括一些硬件DIYer，而不仅仅是我们这些“软蛋”。Cache的工作原理可以简单表述为：CPU需要读取数据Data；CPU首先在Cache中寻找Data；Cache中有Data（被称为“命中”），于是Cache将Data传递给CPU；Cache中没有CPU要的Data，Cache从外部存储设备获取Data，并更新Cache本身，将Data存入Cache内部，等待下一次命中。

对应于Flyweight Pattern（自己找张Flyweight Pattern的结构示意图吧）：

* CPU是Client；

* Cache是FlyweightFactory；

* Data是Flyweight。

Flyweight Pattern中，Flyweight包括可共享的与不可共享的两类对象。套用关系数据库中的术语，可以这么说：

* 对于可共享的Flyweight，其内部的数据与状态应当是符合第三范式的（3NF）的，其表达不依赖于其他对象或上下文。

* 对于不可共享的Flyweight，它则通常是依赖于一个可共享的Flyweight来完成一个更丰富、更完整的表达的。

我当时之所以对Flyweight Pattern百思不得其解，是错误地将注意力放到了GoF中可共享的Character对象及存储其字体信息的GlyphContext上了。

对Strategy、Template、Bridge的认识

Abbey的网络日志 — Wed, 06 Sep 2006 12:52:00 GMT

Strategy在GoF等人的书中，被阐述为针对同一问题的若干种算法的独立封装。对于Bridge，则被表述为将若干对象方法的实现与对象本身分别封装。

Strategy、Bridge看似风马牛不相及的两种Pattern，却正是由于二者均表现为将方法的实现与方法所属的对象分别进行封装，而让我迷惑了许久。

（一）Strategy

现在，我理解的Strategy更象是C/C++语言中的头文件.H与库文件.LIB的关系。比如.H中声明的同一个方法malloc()，可能会因为编译模式的选择（Tiny/Small/Large），使malloc()的编译依赖指向不同的.LIB中malloc()的实现，比如malloc_tiny()、malloc_small()、malloc_large()。

Strategy或者也可以用一个参加宴会的人如何使用餐具作比：参加中式宴会时，使用筷子；参加西式宴会时，使用刀叉。

在这两个例子里，“malloc()”与“使用餐具”是Strategy中要被抽象的那个方法；“编译模式”与“宴会类型（中/西）”是Strategy中的Configuration对象；malloc_tiny()、“使用筷子”、“使用刀叉”则分别是派生的ConcreteStrategy对象。最后由“参加宴会的人”根据自己参加的是中式亦或西式的宴会（获取Configuration对象），决定是“使用筷子”还是“使用刀叉”（创建对应的ConcreteStrategy对象）。

在Strategy Pattern中，一个Strategy对象总是与一个方法Method()对应的，若干个派生的Strategy对象间是互斥的，所有的ConcreteStrategy对象都只能属于同一个Method()。换句话说，任一时刻Method()只能是指向其中的一个Strategy对象。

（二）Template

Template也是将方法与其实现相剥离的一种Pattern，它只是在Strategy的基础上作出了更多的限制——预定义了方法的具体实现步骤。可以理解为，Strategy只是将Method()与Method_Imp()进行了剥离，而Template是将Method()表示为Method_Imp()后，继续将Method_Imp()割裂为Method_Imp_Step1()、Method_Imp_Step2()、Method_Imp_Step3()等。

在Martin的Head First一书里，用泡咖啡与泡柠檬茶对Template Pattern做了最形象的比喻。泡咖啡或是泡茶，都要经过几个步骤：烧水->放入咖啡/茶叶->把泡好的咖啡/茶盛入杯子->加奶/柠檬。于是在Template中，他定义了BoilWater()->Brew()->PourInCup()->AddCondiments()这么一个顺序，构成一个完成的泡制饮品的方法，区别的只是泡茶时Brew()放的是茶，AddCondiments()时放的是柠檬。

我时常在想，为什么国内的专家们就不能举出这么简单的例子，让我们一下就明白Pattern是什么呢？他们要不把简单的问题复杂化，要不就照抄别人的例子。

（三）Bridge

曾经以为自己对Bridge的理解是最为深刻的，因为这是《Design Pattern Explained》奉上的第一个颇具挑战性的Pattern。直到学习了Strategy之后，我才发现之前的认识是错误的——我混淆了Bridge与Strategy。现在，我认识到：

1. Bridge反映的是一组对象Abstraction与另一组对象Implementation之间的关系，Abstraction与Implementation分别有若干个派生类。

　Strategy反映的是一个方法Method()与一组ConcreteStrategy对象之间的关系，这种关系需要Configuration对象的介入。

2. Bridge中Abstraction.Method()对应的可能是Implementation.Method_1()一个方法，也可能是Implementation.Method_1()+Implementation.Method_2()这样的组合；Implementation为Abstraction提供“方法的实现素材”，Abstraction.Method()不是简单地调用Implementation.Method()，Abstraction.Method()中可能还包括自己的一部分实现。

　Strategy中Method()只能是对应某一个ConcreteStrategy.Method()。

3. Bridge中Abstraction.Method()与Implementation.Method()的对应关系是在设计时就确定了的。即假设派生于Abstraction的A.Method()被确定利用Implementation.Method_A()来实现其操作，那么无论这个Implementation是具体的Imp_One还是Imp_Two对象，A.Method()中都只能使用Imp_One或者Imp_Two的Method_A()，尽管Imp_One、Imp_Two可能还包括Method_B()之类的方法。

　Strategy中Method()究竟与哪一个ConcreteStrategy.Method()对应是可以在运行时利用Configuration对象来改变映射关系的。

《Design Pattern Explained》一书中，使用不同版本的绘图设备Drawing（Implementation）绘制各种Shape（Abstraction）是理解Bridge Pattern很好的一个例子，作者也有很详尽的讲解。

对State Pattern的认识

Abbey的网络日志 — Fri, 01 Sep 2006 10:39:00 GMT

State Pattern的作用，主要是将对象的状态抽象出来，避免状态与对象的紧耦合。还是看一个很简单的例子吧。

这是一台Machine，假设有Running、Paused、Stopped三种状态，这三种状态间由Machine的Start()、Pause()、Resume()、Stop()这几种方法进行改变。

以下是这个示例的C#代码，同样的，我又省略了许多。这个例子真的简单，仔细理解注释以及整个类与类形成的State Pattern的结构是关键。

public interface State
{
    //导致状态改变的所有方法
    void Start();
    void Pause();
    void Resume();
    void Stop();
}

//每一个状态对应一个State的派生类，在该类中以其对应状态为源点，实现转换至其他状态时的方法
public class Running : State
{
    private Machine m_machine = null;

    public Running(Machine mac)
    {
        m_machine = mac;
    }

    //以Running为源点的方法，只有Pause()、Stop()
    public void Start()
    {
        ;//在Running状态下，不支持Start()方法
    }

    public void Pause()
    {
        Console.WriteLine("Paused.");
        m_machine.SetState(m_machine.Paused);
    }

    public void Resume()
    {
        ;//在Running状态下，不支持Resume()方法
    }

    public void Stop()
    {
        Console.WriteLine("Stopped.");
        m_machine.SetState(m_machine.Stopped);
    }
}

public class Paused : State
{
    //需要实现Resume()、Stop()
}

public class Stopped : State
{
    //需要实现Start()
}

public class Machine
{
    //为每一种状态准备一个State对象，需要为这些对象都提供一个Property
    private Running m_running   = new Running();
    private Paused m_paused    = new Paused();
    private Stopped m_stopped = new Stopped();

    public State Running
    {
        get
        {
            return m_running;
        }
    }

    //还有Property Paused与Stopped在此定义

    //初始状态为Stopped
    private State m_state = m_stopped;

    public void SetState(State st)
    {
        m_state = st;
    }

    public void PressStart()
    {
        m_state.Start();
    }

    private bool m_pausedown = false;
    public void PressPause()
    {
        if (m_pausedown == false)
            m_state.Pause();
        else
            m_state.Resume();

        m_pausedown = ~m_pausedown;
    }

    public void PressStop()
    {
        m_state.Stop();
    }
}

本文到此结束

对Command Pattern的认识

Abbey的网络日志 — Wed, 30 Aug 2006 14:48:00 GMT

对创建型Design Pattern的认识

Abbey的小匣子 — Wed, 30 Aug 2006 14:30:00 GMT

最近在学习Design Pattern，主要阅读的书包括：

GoF，Design Patterns: Elements of Reusable Object-Oriented Software
Shalloway，Design Patterns Explained: A New Perspective on Object Oriented Design
Freeman，Head First Design Patterns
Martin，Agile Software Development: Principles, Patterns, Practices

为什么会同时读这几本书？原因很简单——因为上述任一本书都没有能把常见的Design Pattern讲清楚。

GoF的那本失于晦涩难懂，缺乏阐述，对于入门者实在不合适。我一直在想，为什么该书没有先讲解各种Design Pattern的结构和适用场景，而先是引入了一个Solution，看得我云里雾里的。
Shalloway的写得不错，结构安排也合理，但是介绍的Design Pattern少了点，书中大量充斥的笔误和错误代码也使之减色不少。
Freeman的是本很有趣的书，文笔也很俏皮。这是一本适合初学者的书，书中的每个Design Pattern都由一个很简单的实际应用逐渐引入，并且每章都有练习题（包括填字游戏）。不过我认为300页就能完成的书也因此用了近700页，看得有点累。
Martin的书是一本中级以后可以阅读的书，前面几章的内容略显枯燥，但仔细的阅读可以让你重新认识Object-Oriented Design，对提高自己对问题域的分析能力以及与团队的沟通能力会有一定的帮助。

回到正题，在GoF的书中，列出了以下几种创建型的Design Pattern：

Factory Method
Abstract Factory
Builder
Prototype
Singleton

对于创建型的Pattern，我们可以这样理解。假设Client（顾客）需要获取一个Shoe（产品）对象，通常的方式是这样的：

Shoe shoe = new Shoe();

而Pattern的引入，就是在Client与Shoe之间插入一个生产者（创造者、工厂）Factory，于是上述的一个new操作变成了一系列的调用过程：

//Client中
Factory fact = new Factory();
Shoe shoe = fact.CreateShoe();

//Factory中
public Shoe CreateShoe()
{
return new Shoe();
}

上述代码表现出来的Client--->Factory--->Shoe之间的关系，正是这些Pattern要实现的，只是各自实现的细节和方法不一样而已。

（一）Singleton

Singleton是比较简单的，其作用就是保证对象的全局性唯一，即任一时刻只有一个实例对象存在。由其引申出的还有适用于多线程的Double-Checked Locking Pattern。下面这段C#代码是Singleton的一个典型实现：

public class Singleton
{
    private static Singleton m_Instance = new Singleton();

    private Singleton()
    {;}

    public static Singleton GetInstance()
    {
        return m_Instance;
    }
}

有意者请参阅此文：Double-checked locking and the Singleton Pattern

（二）Factory Method

在Factory Method中，Factory与Shoe存在一一对应的关系。这次复杂点，假设Client要获取男鞋ShoeForMale与女鞋ShoeForFemale，则必定存在均派生于Factory的FactoryMale与FactoryFemale两个工厂，其中FactoryMale为Client创建ShoeForMale对象，FactoryFemale为Client创建ShoeForFemale对象。

至于选择FactoryMale亦或FactoryFemale，则是由Client负责并选择的。一旦选定了某一Factory，就可以调用一致的factory.CreateShoe()方法来创建Shoe对象了。

（三）Abstract Factory

理解了Factory Method，我们可以把Abstract Factory看作其扩展的结果，或者说Factory Method是Abstract Factory退化的结果。与Factory Method不同的是，Abstract Factory能为Client返回的，总是多种不同的对象，同时这些对象之间总是存在Family（族）的关系，这些对象总是“同生共死”，只能生活在“同一片天空下”。这样说可能不太好理解，还是用一个通俗的例子进行说明吧。

假设这一次Client需要的是Shoe与Socks，那么Factory肯定要提供CreateShoe()与CreateSocks()两个方法为之服务。但是想想，一位男士也许不会愿意去穿一位女士的鞋或袜子吧，呵呵。所以这回对Factory得有一定的限制了，因此FactoryMale生产ShoeForMale，那么它能生产的Socks也只能是SocksForMale。同样的，FactoryFemale能生产的也只能是ShoeForFemale与SocksForFemale。

在上面这个Shoe与Socks的例子中，我们也许发现了ShoeForMale、ShoeForFemale均派生于Shoe，而SocksForMale、SocksForFemale则派生于Socks。于是我们可能会认为，Abstract Factory为Client返回的，只能是A1+B1或者A2+B2这样的产品配对，即必有A<->B这样的对应关系。而这也正体现了Abstract Factory得以适用的主要场景——在不同平台间进行移植。

但是，在GoF的书中为我们提供的例子，却出现了A1+B1、A1+C1、A2+B1这样的一些配对。即出现了Client要求A、B、C对象，而有的Factory只返回A与C，而没有B的现象。

在他的例子里，MazeFactory通过MakeMaze()、MakeRoom()、MakeWall()、MakeDoor()等接口方法能为Client提供Maze、Room、Wall与Door对象。要注意的是，Wall、Door是Room对象的组成部分，Room又成为Maze的组成部分。正是这种彼此包含的关系，体现在派生的BombedMazeFactory中后，就只实现了MakeMaze()、MakeWall()与MakeRoom()方法，而没有Door对象向Client提供。

他为什么可以这样做？或者说为什么要这样做呢？这是因为存在前述对象间的包含关系，使得Client要负责用获取的Door、Wall对象去构造Room对象，然后再用构造好的Room对象去构造Maze对象。而我之前理解的，则是认为既然是MazeFactory，必定是为Client返回好一个构造好了的Maze。正是这样的矛盾让我困惑了许久，那段时间确实很痛苦。所以就我个人认为，GoF书中这样应用Abstract Factory即便能体现Pattern适用的灵活性，却也是不严谨的。

（四）Prototype

这是一个比较简单的创建型Pattern。它就象一个仓库，里面已经有了我们需要的产品样本，我们要做的只是Clone或者说Copy一个。所以应用这个Pattern的关键，在于设计好这个样本，包括这个样本的各种Property、状态等等。然后为其设计一个恰当的接口方法Clone()。

每当Client要获取一个Shoe对象时，由于Shoe的每个实例对象已经定义好了，所以要做的只是简单地调用Shoe.Clone()而已。这有点类似于C#或者说.NET Framework下提到的“Deep Copy”（深拷贝）。

（五）Builder

个人认为，就GoF书中Maze的例子，适用Builder是最为恰当的。Builer的使用更象是搭积木，要搭的房屋是Client要的对象，其中的每一个积木块是部件对象。Builder Pattern的适用场景可以做如下模拟：

1. 有一个需要Shoe的Client；
2. Shoe是可以定制的；
3. Shoe可供定制的部件包括鞋底Tread、鞋面Vamp、鞋带Lace（甚至还有更多的可供定制的部分）；

于是，Builer要做的，就是将部件的构造剥离出来，当部件构造完毕后，再将完整的Shoe交给Client。看看下面这段很简单的代码吧。

public interface Builder
{
    Tread CreateTread();
    Vamp CreateVamp();
    Lace CreateLace();
    Shoe GetShoe();
}

public class BuilderMale : Builder
{
    public Tread CreateTread()
    {
        return new TreadForMale();
    }

    public Vamp CreateVamp()
    {
        return new VampForMale();
    }
    public Lace CreateLace()
    {
        return new LaceForMale();
    }

    public Shoe GetShoe()
    {
        return new Shoe(CreateTread(), CreateVamp(), CreateLace());
    }
}

//在Client里
Builder builder = new BuilderMale();

Shoe shoe = builder.GetShoe();

从某个角度说，Builder很象Factory，即一种Shoe对应一种Builder。同时也很象Prototype，它只是把Clone()换作了GetShoe()。

同样的，在Gof使用Builder构造Maze的示例里，他又将Maze的构造责任交给了Client。换作上述的代码，即CreateTread()、CreateVamp()与CreateBootlace()由Client直接调用。当Client获取了Tread、Vamp、Bootlace对象后，通过调用Shoe的组装函数完成组装，然后调用Builder的GetShoe()获取最后的Shoe对象。不过他的示例里，也演示了如何利用Builder进行对象计数，很是有趣。

2006-9-7修订

最近又在网上找了一些Factory、Builder的例子，发现它们确实都按照GoF的方式，将子部件的构造也交由Client负责，所以开始怀疑自己的理解是否正确。

在GoF的这种方式里，Factory或者Builder在提供了CreateShoe()接口的同时，也要提供Shoe各部件的CreateVamp()、CreateTread()、CreateLace()接口。Client利用CreateShoe()返回一个没有实质意义的Shoe对象，然后再利用CreateVamp()等获取各部件，最后利用Shoe对象的方法完成组装。

2007-2-14修订

因为对上述组装过程究竟应由Client还是Builder负责存在疑惑，我又去找了一些例子和文章。肯定的答案是：Product的组装过程由Client决定，这个组装过程是应用中恒定的内容。变化的是不同种类的Product由不同种类的Builder提供相应的部件。

2007-3-20修订

在MSDN Web Cast 李建忠的系列讲座《C#面向对象设计模式纵横谈》中，给出了Singleton更为简洁的实现方式，很不错：

class Singleton
{
public static readonly Instance = new Singleton();

private Singleton() {;}
}