（已有53条评价）基本信息
- 原书名：Design Patterns Explained
- 原出版社： Addison Wesley/Pearson
- 作者： （美）Alan Shalloway,James R.Trott
- 译者： 熊节
- 出版社：清华大学出版社
- ISBN：7302098417
- 上架时间：2004-12-31
- 出版日期：2004 年12月
- 开本：185×260
- 页码：242
- 版次：1-1
- 所属分类：计算机 > 软件工程及软件方法学 > 设计模式
内容简介
书籍
计算机书籍
本书从一个新的视角描述面向对象设计，将面向中对象编程的原则与运用设计模式力量创建健壮、可靠的软件开发环境结合起来。书中采用实用、恰当的例子，指导读者用模式解决普通的编程问题，并且解释现代软件设计模式的优越性。本书适用于学习面向中对象设计和设计模式的学生、程序员以及从事软件开发的人士。
本书要点包括：
·对象、封装和继承的新观点
·设计模式的思想、起源及其在软件设计学科中的应用
·模式基础以及使用统一建模语言（UML）进行面向对象软件开发
·如何实现关键模式——Strategy（策略）、Observer（观察者）、Bridge（桥接）、Decorator（装饰）等等
·共同点/变化点分析、设计模式以及它们如何帮助理解抽象类
计算机书籍
本书从一个新的视角描述面向对象设计，将面向中对象编程的原则与运用设计模式力量创建健壮、可靠的软件开发环境结合起来。书中采用实用、恰当的例子，指导读者用模式解决普通的编程问题，并且解释现代软件设计模式的优越性。本书适用于学习面向中对象设计和设计模式的学生、程序员以及从事软件开发的人士。
本书要点包括：
·对象、封装和继承的新观点
·设计模式的思想、起源及其在软件设计学科中的应用
·模式基础以及使用统一建模语言（UML）进行面向对象软件开发
·如何实现关键模式——Strategy（策略）、Observer（观察者）、Bridge（桥接）、Decorator（装饰）等等
·共同点/变化点分析、设计模式以及它们如何帮助理解抽象类
作译者
Alan Shalloway是NetObjectives(美国一家咨询／培训公司)的创始人、CEO和资深顾问。计算机科学硕士，具有三十多年的软件开发经验，以及多年的指导和培训经验。他在设计模式、OOA，OOD及其灵活运用方面开设了许多课程，并在为其公司和客户开发高级软件方面作出了很大贡献。
James R．Trott是位于美国Pacific Northwest的一家大型软件公司的资深顾问，此前在一家大型宇航公司任高级工程师。他是应用数学科学硕士，MBA和跨文化研究艺术硕士。他在人工智能、知识模型以及知识管理方面工作了17年，是运用认知设计模式与KADS方法学的专家。
James R．Trott是位于美国Pacific Northwest的一家大型软件公司的资深顾问，此前在一家大型宇航公司任高级工程师。他是应用数学科学硕士，MBA和跨文化研究艺术硕士。他在人工智能、知识模型以及知识管理方面工作了17年，是运用认知设计模式与KADS方法学的专家。
目录
第1篇 面向中对象软件设计简介
第1章 面向对象范式
1.1 概述
1.2 面向对象范式之前：功能分解
1.3 需求的问题
1.4 处理变化：使用功能分解
1.5 处理变化的需求
1.6 面向对象范式
1.7 实践中的面向对象程序设计
1.8 特殊的对象方法
1.9 总结
第2章 UML--统一建模语言
2.1 概述
2.2 什么是UML
2.3 为什么使用UML
2.4 类图
2.5 交互图
2.6 总结
第2篇 传统面向对象设计的局限性
第3章 一个急需灵活代码的问题
第1章 面向对象范式
1.1 概述
1.2 面向对象范式之前：功能分解
1.3 需求的问题
1.4 处理变化：使用功能分解
1.5 处理变化的需求
1.6 面向对象范式
1.7 实践中的面向对象程序设计
1.8 特殊的对象方法
1.9 总结
第2章 UML--统一建模语言
2.1 概述
2.2 什么是UML
2.3 为什么使用UML
2.4 类图
2.5 交互图
2.6 总结
第2篇 传统面向对象设计的局限性
第3章 一个急需灵活代码的问题
译者序
AlanShalloway的《设计模式精解》是一本很好的新书，其中有很多很好的应用模式的例子，尤其适合模式的初学者。
--John Vlissides
这本书(《设计模式精解》)最大的优点之一就是：它用类比的方式将概念解释得非常清楚，而很少使用程序代码。我正在做一套关于OOP和软件开发的录音教材，这本书讲述概念的方式对我非常有启发。
--Bruce Eckel
模式
从去年9月开始翻译《设计模式精解》到现在，已有半年的时间。在这半年里，我很欣喜(同时也很讶异)地看到：在中国的软件开发者里面，有那么多的人爱好设计模式，有那么多的人关注着"模式"这个话题。模式在中国受重视的程度，远远超出了我当初的想象。
但是必须看到，随着"模式"这个词的日益流行，"人们对模式的混淆、惊惶和以讹传讹已经不是一点半点"。就像任何流行的东西一样，人们对模式也存在着各种各样的误解。有人说"模式就是某种编程技巧"，有人说"看了《设计模式》中的几个模式就足够了"，有人说"模式需要有某种工具或者方法学的支持才会有效"，有人说"模式可以保证软件的复用性"，还有一种听得最多的："模式是针对面向对象设计和实现的"。喜欢模式的读者，你可曾意识到，这些都是对"模式"一词的误解呢?
还是模式
究竟什么是模式?按照Christopher Alexander的定义，模式就是"在某一个场景下的问题解决方案"。但是，在John Vlissides看来，连这种观点都是片面的，他认为，除了场景、问题和解决方案之外，一个模式还必须有三个要点：
1．可重复性。解决方案应该对应于外部的场景。
2．可传授性。一个解决方案应该可以移植到问题的不同情况中(绝大多数模式的可传 授性都建立在"约束"和"效果"的基础上)。
3．用来表示这个模式的名称。
而我们经常挂在嘴边的"模式"，常常就是指《设计模式》中的"设计模式"，或者再准确些讲，是"面向对象的设计模式"。顾名思义，它是在面向对象方法基础上发展起来的，它是用于设计阶段的，它是模式的子集，却不是模式的全部。模式是针对特定场景下的特定问题的可重复、可表达的解决方案。它不限于面向对象，不限于设计阶段，甚至不限于软件开发领域。这跟我们这本书没有太大关系，但是记住这一点是有必要的。模式精解
《设计模式》早在1995年就面世了，中译本的出版也是在两三年以前。泰山北斗在前，还需要有这样一本设计模式的书籍吗?我说：需要。为什么会有那么多的误解?为什么会有那么多人抱怨"《设计模式》看不懂"?我想，因为这部经典太过精练又太重理论，再加上陌生的语言、失当的例子、过时的场景，使读者很难对其中的模式形成有感性的认识，更遑论理性的理解了。
请来想想这几个问题：首先，你真正了解面向对象吗?其次，你准确地知道什么是模式吗?最后，你知道应该如何使用设计模式吗?实际上，面对这三个问题，很少有人能够毫不犹豫地连答三个"Yes"。现在，你手上的这本书，就是为了"精解"这些疑惑的。用作者自己的话来说：
也许你使用一种面向对象或基于对象的语言已经有好几年了。但是，你是否已经知道，对象真正的威力不是继承而是"行为封装"?也许你对设计模式很感兴趣，并且发现关于设计模式的专著往往有点过于深奥。如果是这样，这本书便是为你准备的。
读过这本书之后，你将获得对十个最基本的设计模式的全面理解。你将明白：设计模式不是单独存在的，而是需要与其他设计模式协同工作以帮助你创建更健壮的应用程序。你将获得足够的基础以阅读设计模式的专著，并且--如果你愿意--可能发现新的模式。
这就是这本书存在的理由，也就是你读它的理由。
致谢
首先要感谢潘爱民老师。是他的一番教诲让我对模式产生了浓厚的兴趣，并最终决定翻译本书。
--John Vlissides
这本书(《设计模式精解》)最大的优点之一就是：它用类比的方式将概念解释得非常清楚，而很少使用程序代码。我正在做一套关于OOP和软件开发的录音教材，这本书讲述概念的方式对我非常有启发。
--Bruce Eckel
模式
从去年9月开始翻译《设计模式精解》到现在，已有半年的时间。在这半年里，我很欣喜(同时也很讶异)地看到：在中国的软件开发者里面，有那么多的人爱好设计模式，有那么多的人关注着"模式"这个话题。模式在中国受重视的程度，远远超出了我当初的想象。
但是必须看到，随着"模式"这个词的日益流行，"人们对模式的混淆、惊惶和以讹传讹已经不是一点半点"。就像任何流行的东西一样，人们对模式也存在着各种各样的误解。有人说"模式就是某种编程技巧"，有人说"看了《设计模式》中的几个模式就足够了"，有人说"模式需要有某种工具或者方法学的支持才会有效"，有人说"模式可以保证软件的复用性"，还有一种听得最多的："模式是针对面向对象设计和实现的"。喜欢模式的读者，你可曾意识到，这些都是对"模式"一词的误解呢?
还是模式
究竟什么是模式?按照Christopher Alexander的定义，模式就是"在某一个场景下的问题解决方案"。但是，在John Vlissides看来，连这种观点都是片面的，他认为，除了场景、问题和解决方案之外，一个模式还必须有三个要点：
1．可重复性。解决方案应该对应于外部的场景。
2．可传授性。一个解决方案应该可以移植到问题的不同情况中(绝大多数模式的可传 授性都建立在"约束"和"效果"的基础上)。
3．用来表示这个模式的名称。
而我们经常挂在嘴边的"模式"，常常就是指《设计模式》中的"设计模式"，或者再准确些讲，是"面向对象的设计模式"。顾名思义，它是在面向对象方法基础上发展起来的，它是用于设计阶段的，它是模式的子集，却不是模式的全部。模式是针对特定场景下的特定问题的可重复、可表达的解决方案。它不限于面向对象，不限于设计阶段，甚至不限于软件开发领域。这跟我们这本书没有太大关系，但是记住这一点是有必要的。模式精解
《设计模式》早在1995年就面世了，中译本的出版也是在两三年以前。泰山北斗在前，还需要有这样一本设计模式的书籍吗?我说：需要。为什么会有那么多的误解?为什么会有那么多人抱怨"《设计模式》看不懂"?我想，因为这部经典太过精练又太重理论，再加上陌生的语言、失当的例子、过时的场景，使读者很难对其中的模式形成有感性的认识，更遑论理性的理解了。
请来想想这几个问题：首先，你真正了解面向对象吗?其次，你准确地知道什么是模式吗?最后，你知道应该如何使用设计模式吗?实际上，面对这三个问题，很少有人能够毫不犹豫地连答三个"Yes"。现在，你手上的这本书，就是为了"精解"这些疑惑的。用作者自己的话来说：
也许你使用一种面向对象或基于对象的语言已经有好几年了。但是，你是否已经知道，对象真正的威力不是继承而是"行为封装"?也许你对设计模式很感兴趣，并且发现关于设计模式的专著往往有点过于深奥。如果是这样，这本书便是为你准备的。
读过这本书之后，你将获得对十个最基本的设计模式的全面理解。你将明白：设计模式不是单独存在的，而是需要与其他设计模式协同工作以帮助你创建更健壮的应用程序。你将获得足够的基础以阅读设计模式的专著，并且--如果你愿意--可能发现新的模式。
这就是这本书存在的理由，也就是你读它的理由。
致谢
首先要感谢潘爱民老师。是他的一番教诲让我对模式产生了浓厚的兴趣，并最终决定翻译本书。
前言
设计模式和面向对象的程序设计曾经承诺：让软件设计开发者的生活更加轻松。每一天，技术传媒乃至大众传媒都传播着它们的术语。但是，要真正学习它们、精通它们、懂得它们的用途，还是很困难的。
也许你使用一种面向对象或基于对象的语言已经有好几年了。但是，你是否已经知道，对象真正的威力不是继承而是"行为封装"?也许你对设计模式很感兴趣，并且发现关于设计模式的专著往往有点过于深奥。如果是这样，这本书便是为你准备的。
在多年向软件开发者--面向对象领域的老手和新手--传授设计模式的基础上，有了本书的诞生。我们相信--并且我们的经验也证明--如果你懂得了这些概念之下的原则和动机、明白了这些设计模式行为的理由，你的学习过程将会让人难以置信地缩短。并且从我们对设计模式的讨论之中，你将可以明白真正的面向对象思想；只有明白了这些，你才能真正成为一个专家。
读过本书之后，你将获得对十个最基本的设计模式的全面理解。你将明白：设计模式不是单独存在的，而是需要与其他设计模式协同工作以帮助你创建更健壮的应用程序。你将获得足够的基础以阅读设计模式的专著，并且--如果你愿意--可能发现新的模式。
最重要的是，你将变得更加训练有素，将能够创建更加灵活、更加完整、更容易维护的软件。
从面向对象到模式再到真正的面向对象
本书的很多地方都复述了我自己学习设计模式的经验。在学习设计模式之前，我认为自己理所当然是面向对象分析和设计的专家。我曾经为各种行业的客户做过一些还算给人深刻印象的设计和实现。我会使用C++并且已经开始学习Java。我编写的代码中对象格式优美、封装紧密。我可以在继承体系中设计优秀的数据抽象。我想我已经懂得面向对象了。
现在回头看看，我发现那时其实我还根本不知道面向对象设计的全部能力，尽管我一直按照专家建议的方式去做。直到开始学习设计模式，我的面向对象设计能力才得到了扩展和增强。学习设计模式使我成为了一个更好的设计者，甚至是在我还没有直接使用那些模式的时候。
我从1996年开始学习设计模式。当时我正在美国西北部一家大型航天公司担任C++面向对象设计顾问。有几个人劝说我领导一个设计模式学习组。正是在那里我遇到了本书的另一位作者Jim Trott。在那个学习组中发生了几件有趣的事情。首先，我开始对设计模式着迷。我可以把自己的设计和其他更有经验的人的设计相比较，我爱上了这种感觉。另一方面，我发现自己并没有完全做到"针对接口进行设计"，也没有随时注意"一个对象是否可以在不知道另外对象的类型的情况下使用另外对象"。同时我还注意到，那些面向对象的初学者--通常认为他们现在开始学习设计模式是太早了--从这个学习组得到的收益与那些面向对象的专家不相上下。设计模式向学习者展现出优秀的面向对象设计实例并阐述基本的面向对象设计原则，而这些使学习者的设计更快地成熟起来。在整个学习进程结束之后，我确信：设计模式，继面向对象设计的发明之后，将是软件设计领域中最好的东西。
但是，看看那个时候我自己的工作，我发现我根本还没有在自己写的代码中结合任何一个设计模式。
当时我只是认为自己还没有学到足够的设计模式，还需要学习更多。那时候，我只知道六个设计模式。一个偶然的机会，我得到了顿悟。当时我在一个项目中担任面向对象设计顾问，并且要为这个项目做一个高层设计。这个项目的领导人极其聪明，但在面向对象设计领域，他还是一个新手。
这个问题本身并不困难，但需要非常注意确保代码容易维护。和往常一样，在看过问题两分钟之后，我便有了一个设计--采用了我常用的数据抽象的途径。很不幸，显然这不会是一个好的设计。单纯地采用数据抽象途径已经让我尝到过失败的滋味。我必须找到一些更好的设计思路。
两个小时过去了，在使用了我所知道的所有设计技术之后，情况仍然没有好转。我的设计基本上都还是和从前一样。而最让我感到受挫的是，我知道一定有一个更好的设计，但我就是找不到它。更具讽刺意味的是，我甚至还知道四个设计模式就"生活"在我的问题中，但我看不出应该如何使用它们。在这里，我，一个被认为是面向对象设计专家的人，被一个简单的问题困住了!
我实在觉得很难受，于是我停了下来，走出办公室以清醒头脑，并告诉自己：至少10分钟里我不再想这个问题。呵呵，30秒之后，我又开始想它了!但我获得了一种领悟并完全改变了我对设计模式的看法：设计模式无法作为独立的条款使用；我应该把设计模式放在一起使用。
模式是应该被结合在一起来共同解决一个问题的。
以前我曾经听到过这句话，但那时我并没有真正理解它。因为软件开发中的模式往往被介绍为"设计模式"，所以我总是在"模式最主要的贡献是在设计阶段"的假设下努力。我的想法是：在设计世界里，模式就好像是类之间优美的联系。然后，我阅读了Christo-pher Alexander那本令人惊讶的书--The Timeless Way of Building。我学到了：模式存在于所有阶段--分析、设计乃至实现之中。Alexander在书中讨论了如何使用模式来帮助理解(乃至描述)问题领域，而不是仅仅在理解了问题领域后使用模式来创建一个设计。
我的错误是：我尝试先创建问题领域中的类，然后将这些类缝合起来形成最终的系统--Alexander把这样的过程称为"一个坏主意"。我从来没有问过自己：我是否拥有正确的类?仅仅因为这些类看起来如此正确、如此明显。我拥有的，是在开始分析时立刻进入了脑海里的类，是我们的老师告诉我们应该在系统的描述中寻找的"名词"。但是我的错误就是仅仅尝试把它们简单地放在一起。
当我回过头，开始使用设计模式和Alexander的方式来指导自己创建类时，仅仅几分钟之后，一个更优秀得多的解决方案在我的脑海中显露出来。这是一个很好的设计，于是我们把它应用在产品之中。我很兴奋--为我设计了一个好的解决方案，也为设计模式的威力而兴奋。从此，我开始在自己的开发工作和教学中结合设计模式。
我开始发现，那些刚开始学习面向对象设计的程序员也可以学习设计模式。并且他们可以在这个学习过程中为自己的面向对象设计能力打好基础。这对于我以及我的学生都是如此。
想象一下我的惊讶!我读过的设计模式书籍以及与我交谈过的设计模式专家都曾经告诉我：在开始学习设计模式之前，你真的需要认真进行面向对象设计的基础训练。然而，我所见到的，同时学习面向对象设计和设计模式的那些学生，他们掌握面向对象设计的进度比那些只学习面向对象设计的学生更快。甚至他们掌握设计模式的进度看上去几乎和那些有经验的面向对象实践者一样快。
也许你使用一种面向对象或基于对象的语言已经有好几年了。但是，你是否已经知道，对象真正的威力不是继承而是"行为封装"?也许你对设计模式很感兴趣，并且发现关于设计模式的专著往往有点过于深奥。如果是这样，这本书便是为你准备的。
在多年向软件开发者--面向对象领域的老手和新手--传授设计模式的基础上，有了本书的诞生。我们相信--并且我们的经验也证明--如果你懂得了这些概念之下的原则和动机、明白了这些设计模式行为的理由，你的学习过程将会让人难以置信地缩短。并且从我们对设计模式的讨论之中，你将可以明白真正的面向对象思想；只有明白了这些，你才能真正成为一个专家。
读过本书之后，你将获得对十个最基本的设计模式的全面理解。你将明白：设计模式不是单独存在的，而是需要与其他设计模式协同工作以帮助你创建更健壮的应用程序。你将获得足够的基础以阅读设计模式的专著，并且--如果你愿意--可能发现新的模式。
最重要的是，你将变得更加训练有素，将能够创建更加灵活、更加完整、更容易维护的软件。
从面向对象到模式再到真正的面向对象
本书的很多地方都复述了我自己学习设计模式的经验。在学习设计模式之前，我认为自己理所当然是面向对象分析和设计的专家。我曾经为各种行业的客户做过一些还算给人深刻印象的设计和实现。我会使用C++并且已经开始学习Java。我编写的代码中对象格式优美、封装紧密。我可以在继承体系中设计优秀的数据抽象。我想我已经懂得面向对象了。
现在回头看看，我发现那时其实我还根本不知道面向对象设计的全部能力，尽管我一直按照专家建议的方式去做。直到开始学习设计模式，我的面向对象设计能力才得到了扩展和增强。学习设计模式使我成为了一个更好的设计者，甚至是在我还没有直接使用那些模式的时候。
我从1996年开始学习设计模式。当时我正在美国西北部一家大型航天公司担任C++面向对象设计顾问。有几个人劝说我领导一个设计模式学习组。正是在那里我遇到了本书的另一位作者Jim Trott。在那个学习组中发生了几件有趣的事情。首先，我开始对设计模式着迷。我可以把自己的设计和其他更有经验的人的设计相比较，我爱上了这种感觉。另一方面，我发现自己并没有完全做到"针对接口进行设计"，也没有随时注意"一个对象是否可以在不知道另外对象的类型的情况下使用另外对象"。同时我还注意到，那些面向对象的初学者--通常认为他们现在开始学习设计模式是太早了--从这个学习组得到的收益与那些面向对象的专家不相上下。设计模式向学习者展现出优秀的面向对象设计实例并阐述基本的面向对象设计原则，而这些使学习者的设计更快地成熟起来。在整个学习进程结束之后，我确信：设计模式，继面向对象设计的发明之后，将是软件设计领域中最好的东西。
但是，看看那个时候我自己的工作，我发现我根本还没有在自己写的代码中结合任何一个设计模式。
当时我只是认为自己还没有学到足够的设计模式，还需要学习更多。那时候，我只知道六个设计模式。一个偶然的机会，我得到了顿悟。当时我在一个项目中担任面向对象设计顾问，并且要为这个项目做一个高层设计。这个项目的领导人极其聪明，但在面向对象设计领域，他还是一个新手。
这个问题本身并不困难，但需要非常注意确保代码容易维护。和往常一样，在看过问题两分钟之后，我便有了一个设计--采用了我常用的数据抽象的途径。很不幸，显然这不会是一个好的设计。单纯地采用数据抽象途径已经让我尝到过失败的滋味。我必须找到一些更好的设计思路。
两个小时过去了，在使用了我所知道的所有设计技术之后，情况仍然没有好转。我的设计基本上都还是和从前一样。而最让我感到受挫的是，我知道一定有一个更好的设计，但我就是找不到它。更具讽刺意味的是，我甚至还知道四个设计模式就"生活"在我的问题中，但我看不出应该如何使用它们。在这里，我，一个被认为是面向对象设计专家的人，被一个简单的问题困住了!
我实在觉得很难受，于是我停了下来，走出办公室以清醒头脑，并告诉自己：至少10分钟里我不再想这个问题。呵呵，30秒之后，我又开始想它了!但我获得了一种领悟并完全改变了我对设计模式的看法：设计模式无法作为独立的条款使用；我应该把设计模式放在一起使用。
模式是应该被结合在一起来共同解决一个问题的。
以前我曾经听到过这句话，但那时我并没有真正理解它。因为软件开发中的模式往往被介绍为"设计模式"，所以我总是在"模式最主要的贡献是在设计阶段"的假设下努力。我的想法是：在设计世界里，模式就好像是类之间优美的联系。然后，我阅读了Christo-pher Alexander那本令人惊讶的书--The Timeless Way of Building。我学到了：模式存在于所有阶段--分析、设计乃至实现之中。Alexander在书中讨论了如何使用模式来帮助理解(乃至描述)问题领域，而不是仅仅在理解了问题领域后使用模式来创建一个设计。
我的错误是：我尝试先创建问题领域中的类，然后将这些类缝合起来形成最终的系统--Alexander把这样的过程称为"一个坏主意"。我从来没有问过自己：我是否拥有正确的类?仅仅因为这些类看起来如此正确、如此明显。我拥有的，是在开始分析时立刻进入了脑海里的类，是我们的老师告诉我们应该在系统的描述中寻找的"名词"。但是我的错误就是仅仅尝试把它们简单地放在一起。
当我回过头，开始使用设计模式和Alexander的方式来指导自己创建类时，仅仅几分钟之后，一个更优秀得多的解决方案在我的脑海中显露出来。这是一个很好的设计，于是我们把它应用在产品之中。我很兴奋--为我设计了一个好的解决方案，也为设计模式的威力而兴奋。从此，我开始在自己的开发工作和教学中结合设计模式。
我开始发现，那些刚开始学习面向对象设计的程序员也可以学习设计模式。并且他们可以在这个学习过程中为自己的面向对象设计能力打好基础。这对于我以及我的学生都是如此。
想象一下我的惊讶!我读过的设计模式书籍以及与我交谈过的设计模式专家都曾经告诉我：在开始学习设计模式之前，你真的需要认真进行面向对象设计的基础训练。然而，我所见到的，同时学习面向对象设计和设计模式的那些学生，他们掌握面向对象设计的进度比那些只学习面向对象设计的学生更快。甚至他们掌握设计模式的进度看上去几乎和那些有经验的面向对象实践者一样快。
