《Delphi模式编程》是一本Delphi程序员的模式入门和实践读物。该书用最通俗易懂的语言和最明白实用的范例解说深奥睿智经典著作《设计模式》。该书不但围绕23个经典的设计模式进行解说，介绍其结构和用法，并给出模式编程的实践范例；还进一步阐述了模式的概念，深入讨论了Delphi的模式编程机制和模式编程法则。
该书适合有编程经验的Delphi程序员，以及有志从事系统设计和架构，不断挑战自我发展空间的软件开发人员阅读。该书还可以作为研究生和高级开发人员的培训教材。当然也可以将此书作为一本模式编程参考手册，便于读者在项目开发中遇到实际的设计问题时直接查阅。
本书的其它相关资源和技术支持，可以在作者的个人网站http://www.liu-yi.net上获得。
无
《Delphi模式编程》经过多年的酝酿和一年多的艰难写作终于完稿了。这本书最初仅仅是我本人学习模式的一个私人笔记，所以使用《Thinking in Patterns with Delphi》的英文名称可能更为准确。
本书第一部分“模式编程原理”，阐述了模式的概念，深入讨论了Delphi的模式编程机制和模式编程法则；后面各部分则分别围绕23个经典的设计模式进行解说，介绍其结构和用法，并给出模式编程的实践范例。
对于有编程经验的Delphi程序员来说，阅读这本书并不困难。书中的例子他们大都很熟悉，只不过以前可能没有用模式编程的方式实现过。在比较不同的思考问题的方法和解决问题的途径后，我相信他们会有“于我心有戚戚焉”的感受。在理解模式的基础上，如果进一步深入阅读本书的“Delphi的模式编程机制”和“模式编程法则”两章将会有更高层次的收获。
诚恳地讲，这部书并不适合初学者阅读，甚至不适合没有建立面向对象概念和不了解面向对象编程的读者阅读。不过初学者可以先积累一些编程实践经验，并通过阅读本人的《Delphi面向对象编程思想》来建立面向对象的思维方式。然后，尝试阅读本书的一些较为简单和常用的模式，例如：Factory Method模式、Strategy模式等。
本书的结构是松散的，各个模式相对独立，自成一章。强烈建议读者在阅读时，先跳过那些你们认为难读的章节和暂时用不上的模式。我并不是说这些章节不重要，而是说最后再回过头来阅读这些章节效果会更好！
当然也可以将此书作为一本模式编程参考手册，便于读者在项目开发中遇到实际的设计问题时直接查阅相关章节，而不需阅读全书。
本书的光盘中包含了书中绝大多数示例程序的源代码，并在Delphi7上调试通过。
本书的其它相关资源和技术支持，可以在我的个人网站和博艺论坛上获得：http://www.liu-yi.net 。另外，感兴趣的个人和单位亦可直接和我本人联系相关的培训。
由于本人水平有限，加之可能的打字笔误，书中难免会有疏漏之处。为此我在博艺论坛（http://www.liu-yi.net/bbs/index.asp）上开辟了《Delphi模式编程》讨论版，欢迎大家及时把勘误意见贴在上面，以便在重印时修订。
最后要感谢邵印中为本书所做的校对工作，感谢周赛锋为本书提出了很好的建议，感谢段立、罗宾、李启元、洪蕾、吴永逸、吴英在本书写作中给予的支持。如果没有家人、朋友、读者的厚爱，本书可能永远无法完成。
还要衷心感谢多年来不断支持我技术写作的机械工业出版社华章分社，与他们合作是令人愉快的！同样他们在计算机图书出版界的成绩也是有目共睹的。
刘 艺
www.liu-yi.net
2004年7月5日于南京
“Design patterns help you learn from others' successes instead of your own failures.”
——Mark Johnson
《设计模式》 的作者在该书的开篇感叹道：“设计面向对象软件比较困难，而设计可复用的面向对象软件就更加困难”。的确，软件开发是一项极具挑战性的工作。对于编程人员而言，要做出一个良好的设计往往需要经过数次探索和反复尝试，并在大量的经验和教训之中才能找到一个较好的解决方案。尽管以编程为艺术的执着追求者们力求使面向对象设计更加灵活、优雅、健壮，但为这一目标所付出的辛苦代价同样惊人。
好在软件业经过多年的发展已经从崇尚个人软件英雄的手工劳作时代进入了以软件工程为指导崇尚团队合作的软件大生产的工业时代。这就是说，通过集体的贡献，一个系统可以由一些可复用的软件实体（例如：组件、类等）来架构，而无需一切从头开始。
同样，在软件设计中也是如此，通过设计模式，我们可以针对一些特定的问题和场景使用一些现成的固定的模式，而不必为找到一个好的方案做重新的探索。模式，实际上就是前人积累的一些宝贵经验的抽象和升华。这些宝贵的经验得以用文字等有效的形式记录下来，为我们学习和应用提供了极大的方便。
所谓模式，简单地说就是从不断重复出现的事物中，发现和抽象出的规律，是解决问题经验的总结。只要是一再重复出现的事物，就可能存在某种模式。例如：小桥流水、曲径通幽的中国园林模式；柳眉杏眼、巧笑倩兮的古典美女模式；枕山环水、背水面街的吉祥风水模式；飙车枪战、美女英雄的007电影模式；花言巧语、死缠烂打的泡妞追女模式。
受模式社区推崇的建筑学家Christopher Alexander说：“每一个模式描述了一个在我们周围不断重复发生的问题，以及该问题的解决方案的核心。这样，你就能一次又一次地使用该方案而不必做重复劳动”。尽管他所指的是城市和建筑模式，但他的思想也同样适用于软件模式，只是在面向对象编程的解决方案里，我们用对象和接口代替了墙壁和门窗。两类模式的核心都在于提供了相关问题的解决方案。
大凡讲述软件模式的文章和书籍，总少不了把模式的源头追溯到Christopher Alexander，广大软件开发者也因此熟悉了这位模式思想的先驱，许多人逐渐成为他的思想信徒，并把他的《建筑的永恒之道》和《模式语言》奉为经典。
图 1Christopher Alexander的《建筑的永恒之道》
其实，最早把模式的思想应用于城市和建筑中的不是Christopher Alexander，而是中国人。模式的源头应该在中国！
早在2千多年以前，中国就形成了自己的城市建设模式，《周礼·冬官考工记第六》里记载有古代都城建设模式：“匠人营国，方九里，旁三门，国中九经九纬，经涂九轨，左祖右社，面朝后市，市朝一夫。”就是说，城市应该呈方形，每边九里，四边城墙上各设有三座城门，城内有九条直街与九条横街(或者理解为横竖各为三条街，而每条街都由三条并列 的道路组成)，街道之宽为车轨的九倍。城市中前面为朝廷部分（政治中心），后面为商市部分（商业中心），朝、市每边均为百步之宽。城市的左方有祖庙，右方为社稷坛。这种方整有序的城市规划一直为中国历代的封建王朝所依循并得到进一步的发展，我们从汉末三国时期的邺城、唐长安、宋汴梁一直到明清的北京，都可以见到这种城市模式。
北宋时期，李诫编修的我国古代建筑学经典著作《营造法式》体现了中国人在建筑模式方面的智慧，该书1068年开始编修，1100年成书，1103年刊行，历时30多年。比Christopher Alexander的《建筑的永恒之道》要早900年。全书共34卷，其内容来自熟练工匠的经验，总结了官式建筑的模式和规范。
十分有趣的是GoF在《设计模式》一书中归纳出模式的四个基本要素为：模式名称（pattern name）、问题（problem）、解决方案（solution）、效果（consequences）；而李诫的《营造法式》则分为释名、各作制度、功限、料例和图样5部分。通过对比我们不难发现，其中释名相当于“模式名称”，给出模式的定义，便于交流和记忆。各作制度相当于“问题”，描述了应该在何时使用模式。它解释了设计问题和问题存在的前因后果，它可能描述了特定的设计问题。功限相当于“效果”，描述了模式应用的功效及使用模式应权衡的问题。料例和图样相当于“解决方案”，是解决所阐述问题的一个构造或配置。Christopher Alexander 的强调“模式是某种场景下某个问题的解决方案”，所以这种解决方案不是抽象的，必须结合具体的料例和图样。料例和图样相当于《设计模式》中的代码示例和模式的UML结构图。
由此可见，中国人早在古代就已经掌握了认识和应用模式的方法。模式的思维方法更符合中国式的智慧。
图 2 李诫编修的《营造法式》
图 3《营造法式》中的立面处理图样
图 4《设计模式》中的Visitor模式结构图
虽然模式的概念早就有了，但要上升到实用阶段，成为可以定义并广泛接受的模式并不简单。模式的核心就是特定的解决方案，它有效且有足够的通用性，能解决重复出现的问题。模式的另一种视角是把它看成是一组建议，而创造模式的艺术则是将很多建议分解开来，形成相互独立的组，在此基础上可以相对独立地讨论它们。
模式的关键在于其源于实践并指导实践。所以要发现模式，必须观察人们的工作过程，发现其中优秀的设计经验，并找出“这些解决方案的核心”，这并不是一个简单的过程。如果你能发现某个模式，它将是非常有价值的。你不必死背模式，甚至不必通读任何一本有关模式的书，你只需要了解到这些模式都是干什么的、它们解决什么问题、它们是如何解决问题的就足够了。这样，一旦你碰到类似问题，就可以从书中找出对应的模式来解决问题。那时，你再深入了解相应的模式也不迟。所以，很多有丰富开发经验的程序员学习模式时都会有似曾相识、相见恨晚的感觉。他们会说“唉，原来这个问题可以这么解决！”
模式不是什么新鲜概念了。因此，模式并不是那些模式的作者人为“发明”的，而是他们从自己和别人的大量实践经验中“发现”的。他们的职责是记录通用的解决方案，找出其核心，并把最终的模式记录下来，传授给大家。对于一个高级开发人员，模式的价值并不在于它给予你一些新东西，而是在于它能帮助你更好地交流。如果你和你的同事都明白什么是Facade模式，你就可以这样非常简捷地交流大量信息：“这个类是一个Facade模式。”也可以对新手说：“用抽象工厂模式来解决这个问题。”模式为设计提供了一套词汇，这也是为什么模式名字这么重要的原因了。
《设计模式》作者之一的John Vlissides指出模式带来的四大好处是：
1. 它们记录了专家的经验， 并且让非专家也能理解。
2. 它们的名称构成了一份词汇表， 帮助开发者更好的交流。
3. 它们帮助人们更快的理解一个系统——只要这个系统是用模式的方式描述的。
4. 它们使系统的重组变得更容易， 不管原来的系统是否以模式的方式设计的。
John Vlissides 说：“过去， 我一直认为第一项是模式最大的好处。现在我认识到， 第二条起码也同样重要。请想一想，在一个开发项目的过程中， 有多少字节的信息在开发者之间流动（ 包括口头的和电子的）？我猜，就算没有1G 也有好几兆。（在推出了《设计模式》之后，我已经收到了好几十兆给GoF的电子邮件。而且我们所描述的还都是小型到中型的软件开发项目。）由于有如此之大的信息交流量， 所以效率上任何微小的提升都能大量节约时间。在这个意义上， 模式拓宽了人们交流的带宽。我对第三、四条的评价也在逐渐提高， 特别是在项目越来越大、软件生存周期越来越长的今天。 至少在短期内， 模式主要存在于大脑中， 而不存在于工具中。如果有了方法学或自动化工具的支持，应该还有其他的收益， 但是我相信这些都只是蛋糕上的奶油， 而不是蛋糕本身， 甚至都不能算蛋糕的一层。”
由此可见，模式并不依赖于工具或方法学的支持，自动化工具也不能使模式的应用更有效。因为模式本身就很灵活，你不能盲目地使用，一旦需要使用模式，你必须知道如何将它运用于当前的问题。这也是关于模式的自动化工具为什么都遭遇失败的原因。与我们经常使用的组件则正好相反，实际上没有哪个模式是能让你不假思索就使用的规则或现成的程序。模式是一种“半成品”，它仅仅给出了的解决方案，但并不告诉你如何去实施。为了用好它，你还必须在自己的项目中把剩下的那一半补上。我本人每次在使用模式时，都在不断地改动。即使同一个解决方案，但没有一次是完全相同的。虽然每个模式相对独立，但又不彼此孤立。有时候它们相互影响，有时互相配合，在具体实践中，我们还可能将模式混合使用。例如在本书中，我在访问者模式一章中就给出了这样一个模式混合使用的范例。
模式并不代表模式的应用。许多自称精通模式的人，他们也只不过是能把GoF的23种模式背得滚瓜烂熟，并用来开开玩笑而已。我们不难在网上看到诸如：打篮球的模式、泡妞的模式，却很少看到模式在编程上的真正应用。
模式应用要比理解模式本身更加困难。模式的困难在于模式既是一种解决问题的方法，更是解决问题的本身。因为针对同一类问题，站在不同的思考角度会有不同的模式选择。例如，解决去耦合的问题，就有用于前台对象和后台对象之间去耦合的Proxy模式；用于系统去耦合的Observer和Mediator模式；用于请求发送者和接收者之间去耦合的Chain of Responsibility模式；用于抽象部分和实现部分之间去耦合的Bridge模式；等等。同样都是解决去耦合的问题，至于选择哪种模式，如何应用这些模式，就要看你的解决问题的出发点以及对各方面利弊的权衡了。
世界是复杂多变的，软件设计的问题在于明确目标、把握方向是件非常困难的事情。为什么说设计的本质是权衡，就在于你很难只确定一个目标，更难确定一个固定的目标。你要考虑的往往是在多种约束下的多种可能解决方案。实际上没有哪种解决方案是唯一正确的，这就是设计策略和风格的问题。因此模式也不是万能的，模式有时仅可以看作是给你一个解决问题的建议、一个可供借鉴的经验、一个可以探索的方向。不同境界不同水平的人对模式有不同的理解，应用起来效果也不一样。
所以那些认为模式可以保证程序更加简洁、优雅和健壮，模式可以保证软件更好的复用性的想法是幼稚可笑的。道理很简单， 模式什么都不保证，模式无法取代人的位置。那些对模式走火入魔的人，往往对更加简单的代码编写方式视而不见，在编程中盲目使用模式。例如，本来可以用简单的条件表达式就足够解决的两三种不同的计算方法，却非要使用Strategy模式，反而使程序更加复杂难以理解，无异于用大炮打蚊子。
有极端看法的人甚至认为：“水平没到，学也白学，水平到了，无师自通。所以不要学设计模式。”
这种说法虽然有一定的道理，但我并不完全同意。
模式对于初学者虽然很难，但了解和学习模式肯定比不知道模式好。尽管他们 都会经过一个迷信模式、痴迷模式、滥用模式的阶段，但这不可怕，因为有招总比无招好。只要掌握正确的学习方法，活学活用，肯定要比无师自通的人少走弯路。而且随着不断的实践，在模式应用上也会更加自如。
模式正确的学习方法就是在实践和思考中学习模式，Jim Coplien在 《Software Patterns》一书中，写道：
“我更愿意用剪裁衣服的模式为这个定义打比方。我可以通过在布料上以剪裁的角度和长度来定义剪子的路径，以此告诉你如何裁一件衣服。或者，我也可以给你一个模式。你阅读剪裁说明，你可能根本就不知道在做什么，但是如果你以前做过类似衣服，你就能完成。模式预示着产品：它既是制造产品的规则，在很多方面它又是产品本身。”
所以要学习模式，首先要有编程实践经验。对于没有编程实践经验的初学者并没有必要急于学习模式。在初学者获得一定编程实践经验之后，我认为应该让他们先掌握几种常用的模式作为解决方案，然后去努力的在现实中寻找使用这些方案的合适场景。学习模式不要指望能够一口气全部学完所有的23种设计模式。即使你博闻强记，能够学完，如果比较少用，一阵子之后也可能会忘记。通常建议你通读模式书籍时能先大概了解这些模式，并根据自己的编程实践有针对性的选择那些感兴趣的模式进行实践探索。等碰到类似问题，在从书中找出对应的模式来解决问题，深入了解相应的模式也不迟。
近几年来“ 模式” 这个词真是非常流行。就像任何流行的东西一样，GoF的经典著作《设计模式》也一时洛阳纸贵，备受推崇。现在模式对于软件开发的影响越来越大，国内开发人员对模式的了解虽然比国外的开发人员晚了数年的时间，但能如此引起重视的确是一件好事。不过我敢肯定，GoF的《设计模式》并不是一本可以轻松阅读的书。这是因为《设计模式》整理自Erich的博士论文，其论文大约占了整部书的一半。对于程序员或普通读者而言，这本书过强的学术性语言和过于严谨的论述无疑增加了阅读的难度，使得这本薄薄的经典如同阳春白雪，曲高和寡。有程序员甚至抱怨自己用一个多月的时间也啃不下这本两百多页（中译本）的薄薄小书。这也就是为什么会有那么多解释这本经典的书出现的原因。
中国人向来有注疏经典的优良传统。以《周易》（易经）为例，就有朱熹的《周易本义》、王弼的《周易正义》、王夫之的《周易稗疏》、苏轼的《东坡易传》等数百种之多。同样，像《设计模式》这样的软件业的经典著作，通过“注疏”来学习并没有什么不好。既然市面上已经有了《Java与模式》、《Visual Basic设计模式》这样的书籍，为什么不能有一本属于Delphi的模式书籍？
准确地讲，与Delphi有关的模式书籍我们也能找到一些。最早见到的是ModelMaker的《Design Patterns Reference》，里面零星介绍了一些用于Delphi的设计模式，这些模式仅仅当作ModelMaker的商业卖点介绍，而且语焉不详。然后是网上广为流传的一本《设计模式》的Delphi版电子书,这本书是台湾人把《设计模式》中C＋＋的例子翻译成Delphi的翻版，令人遗憾的是这种生搬硬套不但使得Delphi改写的程序难以运行，甚至还存有不同语言之间理解上的谬误。不久前看到李维的《Inside VCL》，但是并不像广告宣传的那样有多少与模式有关的内容，该书仅仅提到了经典模式中的2个，即Facade和Command模式。而在另一本国内作者陈省的《Delphi 深度探索 第2版》中，虽然有一章专门介绍设计模式，但是80页的篇幅似乎过于简洁，而且仅限于“以VCL中的示例来介绍如何使用Delphi应用设计模式的内容”。
我觉得应该有一本能够帮助Delphi程序员比较全面理解和学习模式的书籍。模式的困难在于其很强的实践性，所以写这样一本书有很大的难度。我写这本书的目的并不是为了在GoF的模式上做什么创新，而是为了通过通俗易懂的解说和明白实用的例子来帮助Delphi程序员掌握模式的使用，建立模式的思维。因此，我花费了大量的时间和精力改编和设计了实践模式的Delphi编程范例，其目的是为了让读者看到模式在实践应用中的价值。
可能一些程序员在阅读技术书籍时会固执地说：“别给我们讲大道理，给我们看程序！”
我要说他们的这些要求是对的！很多关于模式的书故作高深，晦涩难懂，其示例代码也是凤毛麟角，让我们看不到任何可以执行的完整代码。我反对这种风格的技术写作。如果我们的目的不是传授制知识，解决问题，又为何要浪费笔墨？
我的这本《Delphi模式编程》（《Thinking in Patterns with Delphi》）可以看成是Delphi程序员的模式入门和实践读物。我的想法是力求用最通俗易懂的语言和最明白实用的范例解说深奥睿智的《设计模式》。
为了让更多的人看懂这本书，我在每个模式的开篇都会用生活中的例子和图示进行形象的模式解说；为了便于套用模式，我为每个模式提供了Delphi的代码模板；为了给程序员看程序，我为每个模式精心准备了最实用的范例程序，附上完整的源代码和代码剖析，保证你能运行这些真正的模式应用程序（而不是一个空壳）。这些范例程序涉及行业应用领域包括：酒店管理系统、银行管理系统（转账系统、信用卡管理系统）、人力资源管理系统（组织机构管理、薪酬福利管理）、地理信息系统、聊天室系统、任务调度系统、项目审批系统等。
当然，书上的范例毕竟只是经过处理的简单的例子，甚至还会有为讲解模式而模式之嫌，离特殊而复杂的实际应用还有距离。就像模式什么都不保证一样，范例程序同样不能保证可以复制到你的项目中取代你自己编程，因此不要指望有太多现成的代码可以拷贝。这本书只是帮你理解设计模式，告诉你这个模式是怎么一回事，大概可以处理什么样的情况，这样处理有什么好处，以及如何用Delphi编程实现。最终的解决方案需要你自己去权衡，模式编程需要你自己去完成。
当你使用模式时请记住，它们只是开始，并非终点。让我们这些作者去囊括项目开发中的所有变化和技术是不可能的。我编写《Delphi模式编程》的目的也只是作为一个开始，希望它能够把我自己的和我所了解的经验与教训传递给读者，你们可以在此基础上继续努力。请读者记住的是，所有模式都是不完备的，如果你们决定进入模式编程的新境界，你们就有责任和兴趣在自己的软件开发中实践它们、完善它们。
刘 艺
www.liu-yi.net
2004年7月2日于南京
刘艺：暂无
目 录
第一部分 模式编程原理 1
第1章 模式概述 1
1.1 模式的概念 1
1.1.1 什么是模式 1
1.1.2 模式可以做什么 3
1.2 模式与架构 4
1.2.1 什么是架构 4
1.2.2 架构和模式的关系 5
1.3 从面向对象编程到模式编程 6
1.3.1 关于封装的哲学 6
1.3.2 利用继承实现变化的封装和简单的复用 7
1.3.3 借助模式封装多个变化 12
1.3.4 模式帮助我们解决问题 19
第2章 Delphi的模式编程机制 20
2.1 对象模型机制 20
2.1.1 对象模型 20
2.1.2 对象建模和模式编程 23
2.1.3 对象关系与复用 24
2.2 动态绑定机制 28
2.2.1 方法绑定 28
2.2.2 虚方法 29
2.2.3 多态 29
2.3 类型转换机制 32
2.3.1 类型 32
2.3.2 向上转型 32
2.3.3 向下转型 36
2.4 接口抽象机制 37
2.4.1 接口的概念 37
2.4.2 抽象类 39
2.4.3 对象接口 40
2.4.4 抽象类与对象接口的比较 42
2.4.5 针对接口而不是针对实现编程 42
第3章 模式编程法则 44
3.1 开闭法则（OCP） 44
3.2 Liskov代换法则（LSP） 47
3.3 依赖反转法则（DIP） 49
3.4 接口隔离法则（ISP） 51
3.5 单一职责法则（SRP） 60
第二部分 创建型模式编程 65
第4章 工厂方法模式（Factory Method） 67
4.1 模式解说 67
4.2 结构和用法 69
4.2.1 模式结构 69
4.2.2 代码模板 70
4.2.3 问题讨论 73
4.3 范例与实践 78
4.3.1 利用工厂方法模式设计可动态切换持久层机制的应用 78
4.3.2 范例小结 84
第5章 抽象工厂模式（Abstract Factory） 85
5.1 模式解说 85
5.2 结构和用法 86
5.2.1 模式结构 86
5.2.2 代码模板 87
5.3 范例与实践 90
5.3.1 用抽象工厂模式动态构造界面风格 90
5.3.2 WebSnap的Web Module架构与抽象工厂模式 98
5.3.3 范例小结 105
第6章 建造者模式（Builder） 107
6.1 模式解说 107
6.2 结构和用法 109
6.2.1 模式结构 109
6.2.2 代码模板 110
6.3 范例与实践 112
6.3.1 一个数据集对象产品的建造者模式 112
6.3.2 范例小结 117
第7章 单例模式（Singleton） 119
7.1 模式解说 119
7.2 结构和用法 121
7.2.1 模式结构 121
7.2.2 代码模板 123
7.2.3 Delphi对象构造机制与单例模式 126
7.3 范例与实践 132
7.3.1 一个共享数据库连接的单例模式范例 132
7.3.2 范例小结 140
第8章 原型模式（Prototype） 141
8.1 模式解说 141
8.2 结构和用法 142
8.2.1 模式结构 142
8.2.2 代码模板 142
8.3 范例与实践 147
8.3.1 Delphi对象的克隆 147
8.3.2 用原型模式克隆字体 149
8.3.3 Delphi对象流化与原型模式 155
8.3.4 范例小结 164
第三部分 结构型模式编程 165
第9章 适配器模式（Adapter） 166
9.1 模式解说 166
9.2 结构和用法 167
9.2.1 类的适配器模式 167
9.2.2 对象的适配器模式 169
9.2.3 问题讨论 170
9.3 范例与实践 171
9.3.1 用适配器模式包装第三方API的范例 171
9.3.2 范例小结 178
第10章 桥接模式（Bridge） 179
10.1 模式解说 179
10.2 结构和用法 181
10.2.1 模式结构 181
10.2.2 代码模板 182
10.3 范例与实践 185
10.3.1 使用桥接模式改进数据持久层的健壮性 185
10.3.2 基于桥接模式的一个数据视图程序 186
10.3.3 范例小结 201
第11章 合成模式（Composite） 203
11.1 模式解说 203
11.2 结构和用法 204
11.2.1 模式结构 204
11.2.2 代码模板 205
11.2.3 问题讨论 208
11.3 范例与实践 210
11.3.1 合成模式在组织机构管理系统中的应用 210
11.3.2 范例小结 220
第12章 装饰者模式（Decorator） 221
12.1 模式解说 221
12.2 结构和用法 223
12.2.1 模式结构 223
12.2.2 代码模板 224
12.2.3 问题讨论 227
12.3 范例与实践 228
12.3.1 装饰者模式在图片观赏器中的应用 228
12.3.2 范例小结 238
第13章 门面模式（Facade） 239
13.1 模式解说 239
13.2 结构和用法 241
13.2.1 模式结构 241
13.2.2 代码模板 243
13.2.3 问题讨论 247
13.3 范例与实践 248
13.3.1 门面模式和分布式系统的设计优化 248
13.3.2 用门面模式设计的COM+银行转账系统 249
13.3.3 COM+银行转账系统实现代码剖析 251
13.3.4 范例小结 268
第14章 享元模式（Flyweight） 269
14.1 模式解说 269
14.2 结构和用法 270
14.2.1 模式结构 270
14.2.2 代码模板 271
14.2.3 问题讨论 275
14.3 范例与实践 276
14.3.1 对象池技术和享元模式 276
14.3.2 享元模式在任务调度系统中的应用 277
14.3.3 范例小结 283
第15章 代理模式（Proxy） 284
15.1 模式解说 284
15.2 结构和用法 286
15.2.1 模式结构 286
15.2.2 代码模板 288
15.3 范例与实践 290
15.3.1 代理模式在数据库程序中的应用 290
15.3.2 范例小结 315
第四部分 行为型模式编程 316
第16章 责任链模式（Chain of Responsibility） 317
16.1 模式解说 317
16.2 结构和用法 318
16.2.1 模式结构 318
16.2.2 代码模板 319
16.2.3 问题讨论 322
16.3 范例与实践 323
16.3.1 责任链模式在项目审批系统中的应用 323
16.3.2 责任链模式对代码的重构 331
16.3.3 范例小结 333
第17章 命令模式（Command） 335
17.1 模式解说 335
17.2 结构和用法 336
17.2.1 模式结构 336
17.2.2 代码模板 338
17.2.3 问题讨论 340
17.3 范例与实践 341
17.3.1 Delphi的Action编程机制与命令模式 341
17.3.2 一个兼有撤销重做功能的文本编辑器范例 351
17.3.3 范例小结 359
第18章 解释器模式（Interpreter） 360
18.1 模式解说 360
18.2 结构与用法 360
18.2.1 模式结构 360
18.2.2 代码模板 361
18.3 范例与实践 364
18.3.1 一个罗马数字到阿拉伯数字的转换器程序 364
18.3.2 范例小结 374
第19章 迭代子模式（Iterator） 375
19.1 模式解说 375
19.2 结构与用法 378
19.2.1 模式结构 378
19.2.2 代码模板 379
19.2.3 问题讨论 384
19.3 范例与实践 385
19.3.1 一个基于迭代子模式的图片播放器 385
19.3.2 范例小结 395
第20章 中介者模式（Mediator） 397
20.1 模式解说 397
20.2 结构与用法 399
20.2.1 模式结构 399
20.2.2 代码模板 401
20.2.3 问题讨论 405
20.3 范例与实践 406
20.3.1 中介者模式在聊天室系统中的应用 406
20.3.2 范例小结 415
第21章 备忘录模式（Memento） 416
21.1 模式解说 416
21.2 结构与用法 416
21.2.1 模式结构 416
21.2.2 代码模板 418
21.2.3 问题讨论 423
21.3 范例与实践 427
21.3.1 备忘录模式在地理信息系统中的应用 427
21.3.2 范例小结 446
第22章 观察者模式（Observer） 448
22.1 模式解说 448
22.2 结构与用法 450
22.2.1 模式结构 450
22.2.2 代码模板 451
22.2.3 问题讨论 457
22.3 范例与实践 458
22.3.1 观察者模式在界面色彩主题中的应用 458
22.3.2 范例小结 475
第23章 状态模式（State） 476
23.1 模式解说 476
23.2 结构与用法 478
23.2.1 模式结构 478
23.2.2 代码模板 479
23.2.3 问题讨论 483
23.3 范例与实践 484
23.3.1 状态模式在信用卡账户管理系统中的应用 484
23.3.2 范例小结 497
第24章 策略模式（Strategy） 499
24.1 模式解说 499
24.2 结构与用法 501
24.2.1 模式结构 501
24.2.2 代码模板 502
24.2.3 问题讨论 506
24.3 范例与实践 506
24.3.1 策略模式在酒店管理系统中的应用 506
24.3.2 范例小结 514
第25章 模板方法模式（Template Method） 515
25.1 模式解说 515
25.2 结构与用法 519
25.2.1 模式结构 519
25.2.2 代码模板 520
25.2.3 问题讨论 522
25.3 范例与实践 522
25.3.1 模板方法在离线数据库系统中的应用 522
25.3.2 范例小结 530
第26章 访问者模式（Visitor） 531
26.1 模式解说 531
26.2 结构与用法 533
26.2.1 模式结构 533
26.2.2 代码模板 535
26.2.3 问题讨论 542
26.3 范例与实践 546
26.3.1 访问者模式在薪酬福利管理中的应用 546
26.3.2 范例小结 563
主要参考文献： 564
