基本信息
- 作者： [美]约翰·威利斯迪斯（John Vlissides)
- 译者： 葛子昂
- 出版社：人民邮电出版社
- ISBN：9787115367211
- 上架时间：2015-8-11
- 出版日期：2015 年8月
- 开本：16开
- 页码：156
- 版次：2-1
- 所属分类：计算机 > 软件工程及软件方法学 > 设计模式
编辑推荐
GoF成员、《设计模式》一书作者之一John M. Vlissides作品。
进一步阐述了23种设计模式。
揭开模式开发的神秘面纱，破除模式十大误解。
养成七种习惯，成为模式设计高手。
作者John Vlissides是设计模式“四人组”（GoF）成员。在本书中，他不仅通过一些通俗易懂的实例对如何运用设计模式进行了深入的讲解，还介绍了一些新的设计模式。此外，他还讲述了模式背后鲜为人知的一些故事，让读者领略其中的苦与乐。
本书帮助读者在面向对象设计的基本原则下，将设计模式运用到合适的地方。它道出了虽然不正式但却严格的标准，《设计模式》中的23个模式正是基于这样的标准，经历了这样的迭代过程产生的。理解了这一点将有助于读者把模式应用到讲究实用的日常工作中，让读者认识到必须根据手头的问题来对模式进行调整，并加入自己的思考而不仅仅是盲目地遵循书本中的规定。通过反复品味，读者有朝一日终能编写出自己的模式！
内容简介
作译者
作者介绍
John Vlissides（1961—2005） GoF成员，《设计模式》一书作者之一。曾在斯坦福大学工作，自1991年起任IBM T. J. Watson研究中心的研究员。他还曾是《程序设计的模式语言》的编辑，Addison-Wesley“软件模式”丛书的顾问。因患脑瘤于2005年感恩节病故。为纪念他的贡献，ACM SIGPLAN特设立了John Vlissides奖。
译者介绍
葛子昂，时任微软中国研发集团服务器及开发工具事业部的软件开发主管，从事WF的相关开发，致力于为WF开发人员提供方便高效的开发工具。之前曾长期从事WCF产品的相关研发，具有丰富的开发经验。出版译作有《.NET设计规范（第2版）》、《Windows核心编程（第5版）》。
John Vlissides（1961—2005） GoF成员，《设计模式》一书作者之一。曾在斯坦福大学工作，自1991年起任IBM T. J. Watson研究中心的研究员。他还曾是《程序设计的模式语言》的编辑，Addison-Wesley“软件模式”丛书的顾问。因患脑瘤于2005年感恩节病故。为纪念他的贡献，ACM SIGPLAN特设立了John Vlissides奖。
译者介绍
葛子昂，时任微软中国研发集团服务器及开发工具事业部的软件开发主管，从事WF的相关开发，致力于为WF开发人员提供方便高效的开发工具。之前曾长期从事WCF产品的相关研发，具有丰富的开发经验。出版译作有《.NET设计规范（第2版）》、《Windows核心编程（第5版）》。
目录
第1章 介绍 1
1.1 对模式的十大误解 2
1.2 观察 9
第2章 运用模式进行设计 11
2.1 基础 12
2.2 孤儿、孤儿的收养以及代用品 16
2.3 “但是应该如何引入代用品呢？” 22
2.4 访问权限 27
2.5 关于Visitor的一些警告 35
2.6 单用户文件系统的保护 37
2.7 多用户文件系统的保护 44
2.8 小结 56
第3章 主体和变体 59
3.1 终止Singleton 59
3.2 Observer的烦恼 70
3.3 重温Visitor 77
3.4 GENERATION GAP 82
3.5 Type Laundering 98
3.6 感谢内存泄漏 106
3.7 推拉模型 111
1.1 对模式的十大误解 2
1.2 观察 9
第2章 运用模式进行设计 11
2.1 基础 12
2.2 孤儿、孤儿的收养以及代用品 16
2.3 “但是应该如何引入代用品呢？” 22
2.4 访问权限 27
2.5 关于Visitor的一些警告 35
2.6 单用户文件系统的保护 37
2.7 多用户文件系统的保护 44
2.8 小结 56
第3章 主体和变体 59
3.1 终止Singleton 59
3.2 Observer的烦恼 70
3.3 重温Visitor 77
3.4 GENERATION GAP 82
3.5 Type Laundering 98
3.6 感谢内存泄漏 106
3.7 推拉模型 111
媒体评论
“本书将帮你理解如何将《设计模式》——其实是任何关于设计模式的书籍——当作一本珍贵的指南，而不是当作一些累赘的规定。”——James O. Coplien，朗讯科技公司，贝尔实验室
“这本技术书的文风非常吸引人，我从未读到过这么精彩的技术书。John真的已经炉火纯青，游刃有余：他对技术主题的把握如此坚实、准确又引人入胜。”——Frank Buschmann，西门子公司
“这本技术书的文风非常吸引人，我从未读到过这么精彩的技术书。John真的已经炉火纯青，游刃有余：他对技术主题的把握如此坚实、准确又引人入胜。”——Frank Buschmann，西门子公司
书摘
让我们再看一下对mkdir的递归调用。传给它的是Node*，而不是所需的Directory*。问题在于，当我们深入访问文件系统的层级时，我们并不知道一个子节点到底是文件还是目录。一般来说，只要客户代码不关心这种区别，这就是一件好事。但在目前的情况下，看起来我们确实需要关心这种区别，因为只有Directory才定义了用来收养子节点和遗弃子节点的接口。
但我们真地需要关心这一点吗？或者更进一步说，客户代码（mkdir命令）需要关心这一点吗？不一定。它的任务是要么创建一个新目录，要么向用户报告错误。因此让我们假设，只是假设一下，我们对所有的Node类都以统一的方式来处理adopt和orphan。
好了，好了。我知道你在想，“天啊！这些操作对File之类的叶节点来说毫无意义。”但这样的假设是不是切合实际呢？如果今后有人想定义一种新的类似垃圾箱（说得更准确一些，是回收站）的叶节点，它可以销毁它收养的所有子节点，那么这种情况该怎么处理？如果想在叶节点收养子节点时产生一条错误消息，那么这种情况又该怎么处理？我们很难证明adopt对叶节点来说绝无意义，orphan同样也是如此。
另一方面，有人可能会争辩说一开始就没有必要把File类和Directory类分开——所有的东西都应该是Directory。这样的论点是合理的，但是从实现的角度来说，它存在一些问题。一般来说，Directory对象中的许多内容对大多数文件来说是不必要的，比如用来存储子节点的数据结构、用来对子节点信息进行高速缓存以提高性能的数据结构，等等。经验表明，在许多应用程序中，叶节点的数量通常要比内部节点的数量多得多。这也是为什么COMPOSITE模式要把Leaf和Composite类分开的原因。
让我们来看一看，如果我们不仅仅只在Directory类中定义adopt和orphan，而是在所有的Node类中定义adopt和orphan，那将发生什么情况。我们让这些操作在默认的情况下产生错误消息。
但我们真地需要关心这一点吗？或者更进一步说，客户代码（mkdir命令）需要关心这一点吗？不一定。它的任务是要么创建一个新目录，要么向用户报告错误。因此让我们假设，只是假设一下，我们对所有的Node类都以统一的方式来处理adopt和orphan。
好了，好了。我知道你在想，“天啊！这些操作对File之类的叶节点来说毫无意义。”但这样的假设是不是切合实际呢？如果今后有人想定义一种新的类似垃圾箱（说得更准确一些，是回收站）的叶节点，它可以销毁它收养的所有子节点，那么这种情况该怎么处理？如果想在叶节点收养子节点时产生一条错误消息，那么这种情况又该怎么处理？我们很难证明adopt对叶节点来说绝无意义，orphan同样也是如此。
另一方面，有人可能会争辩说一开始就没有必要把File类和Directory类分开——所有的东西都应该是Directory。这样的论点是合理的，但是从实现的角度来说，它存在一些问题。一般来说，Directory对象中的许多内容对大多数文件来说是不必要的，比如用来存储子节点的数据结构、用来对子节点信息进行高速缓存以提高性能的数据结构，等等。经验表明，在许多应用程序中，叶节点的数量通常要比内部节点的数量多得多。这也是为什么COMPOSITE模式要把Leaf和Composite类分开的原因。
让我们来看一看，如果我们不仅仅只在Directory类中定义adopt和orphan，而是在所有的Node类中定义adopt和orphan，那将发生什么情况。我们让这些操作在默认的情况下产生错误消息。
