本书围绕5个主题领域来组织本书的内容：概述、企业应用、系统、最终用户应用和编程语言。本书让最优秀的设计师和架构师来描述他们选择的软件架构，剥开架构的各层，展示他们如何让软件做到实现功能、可靠、易用、高效率、可维护、可移植和优雅。
出版本书的想法是在2007年确立的，它是获奖的畅销书《Beautiful Code》（编辑注）的姊妹篇。在这本书中，虽然范围和目的不一样，但关注点是类似的：让最优秀的设计师和架构师来描述他们所选的软件架构，剥开他们作品的各层，展示他们如何让软件实现功能性、可靠性、易用性、高效率、可维护性、可移植性，当然，还有优雅性。
为了编成这本书，我们联系了一些著名软件项目的主要架构师和一些不太著名但高度创新的软件项目的主要架构师。许多人快速回应，将引人思索的想法寄回给我们。有些想法甚至让我们大吃一惊，他们建议不要写具体的系统，而是调查架构在软件工程中产生影响的深度和广度。
当本书的所有作者听说这本书的版税将捐给Med巆ins Sans Fronti`eres（无国界医生组织）时，都感到十分高兴。Med巆ins Sans Fronti`eres是一个国际人道主义援助组织，为困难的人提供紧急医疗救助。
本书的组织
我们围绕5个主题领域来组织本书的内容：概述、企业应用、系统、最终用户应用和编程语言。很明显，缺少有关桌面软件架构的章节，但这不是故意的。我们联系了50多位软件架构师，这个结果让我们吃惊不小。难道真的没有美丽桌面软件架构的漂亮例子吗？或者那些天才的架构师避而不谈架构，是因为忙着应付需求，为应用堆彻更多的功能？我们非常期望听听你对于这些问题的见解。
第一部分：论架构
本书的第一部分探讨了软件架构的广度和范围，以及它对软件的开发和演进意味着什么。
第1章由John Klein和David Weiss编写，他们从架构的品质考虑和架构结构的角度，对架构进行了探讨。
第2章由Pete Goodliffe编写，他写了一篇寓言，揭示了软件架构如何影响系统的演进和开发者在项目中的参与情况。
第二部分：企业级应用架构
企业级系统是许多组织机构的IT支柱，它们不仅巨大，而且常常是度身定制的软件集，一般由许多分散的组件构成。它们服务于大量的、支持事务的工作，必须延伸到它们所支持的企业的各个角落，时刻准备着适应不断变化的业务需求。在为这样的系统设计架构时，可伸缩性、正确性、稳定性和可扩展性是最重要的关注点。本书的第二部分包含了一些企业级软件架构的优秀范例。
第3章由Jim Waldo编写，展示了构建大规模多人在线游戏所需的架构技术。
第4章由Michael Nygard编写，介绍了一个多阶段、多地点的数据处理系统的架构，展示了让系统能工作所必需的折中。
第5章由Brian Sletten编写，讨论了创建数据驱动的应用时资源映射的威力，提供了纯面向资源架构的一个优雅的例子。
第6章由Dave Fetterman编写，他提倡以数据为中心的系统，解释了好的架构如何能够创造并支持应用生态系统。
第三部分：系统架构
系统软件可能是在设计方面要求最高的软件，部分原因是因为高效率地使用硬件是少数人才能掌握的神秘艺术，还有部分原因是因为许多人认为系统软件的架构是理所当然的存在。了不起的系统架构很少是从一张白纸开始的，我们今天使用的大多数系统是基于20世纪60年代的设想。第三部分的这几章介绍了4种创新的系统架构，讨论了架构决定背后的复杂性，这正是它们美丽的原因。
第7章由Derek Murray和Keir Fraser编写，提供了一个例子说明深思熟虑的架构如何能够改变操作系统演进的方式。
第8章由Greg Lehey编写，回顾了Tandem的架构选择和组成部分（包括硬件和软件），正是这些让Tandem成为近二十年的高可用性环境的首选平台。
第9章由Rhys Newman和Christopher Dennis编写，描述了如何通过小心地设计软件和很好地理解领域需求来克服编程系统中那些可以察觉到的不足。
第10章由Ian Rogers和Dave Grove编写，介绍了为高级语言创建自优化的、自支持的运行时环境所需的架构选择。
第四部分：最终用户应用架构
最终用户应用程序是我们每天的计算生活都要使用的那些应用程序，是占据我们最多CPU指令周期的软件。这种软件通常不需要仔细地管理资源，也不需要执行大量的事务。但是，它需要易于使用、安全、可定制和可扩展。这些属性可以导致软件广泛流行和使用，以免费开源软件为例，会有大量的自愿者愿意改进它。在第四部分，作者们分析了两个非常流行的桌面软件包的架构和需要的社区过程。
第11章由Jim Blandy编写，解释了一组非常简单的组件和一门扩展语言如何将一个不起眼的文本编辑器变成了一个操作系统（注），成为程序员工具箱中的瑞士军刀。
第12章由Till Adam和Mirko Boehm编写，展示了冲刺和同级评审这样的社区过程如何帮助软件架构从简单的骨架演变为美丽的系统。
第五部分：语言与架构
正如许多人在他们的著作中指出的那样，我们使用的编程语言影响了我们解决问题的方式。但是编程语言也能影响系统的架构吗？如果是这样，那么是如何影响的？在建筑的架构中，新的材料和CAD系统的采用让人们能够表达更复杂、有时更惊人的漂亮设计。对于计算机编程来说也是如此吗？第五部分包含最后的两章，探讨了我们使用的工具和得到的设计之间的关系。
第13章由Bertrand Meyer编写，比较了面向对象和函数式架构风格的适用性。
第14章由Panagiotis Louridas编写，探讨了现代和经典面向对象软件语言的组件背后的架构选择。
最后，在引人深思的跋中，William J. Mitchell（MIT架构与媒体艺术科学系教授）将真实世界中建筑架构的美丽概念与硅基芯片上软件架构的美丽概念联系在了一起。
原则、特性与结构
在这本书评阅过程的后期，一位审阅者要求我们提供个人的观点作为一种补充，告诉读者可以从每一章中学到些什么。这个想法很有趣，但我们不想再猜测各章作者的意思。要求作者们自己提供他们文章的元分析，就会得到一堆的定义、术语和架构结构，这肯定把读者搞糊涂。我们需要一组通用的架构术语，谢天谢地，我们意识到我们已经有了。
在序中，Stephen Mellor讨论了7个原则，所有美丽的架构都基于这7个原则。在第1章中，John Klein和David Weiss提供了4种架构组件和美丽架构的6种特性。细心的读者会发现，Mellor的原则与Klein和Weiss的特性不是彼此无关的。实际上，它们大多数是一致的，这是因为英雄所见略同。他们三人都是非常有经验的架构师，人们曾多次在实际工作中看到过他们描述的概念的重要性。
我们将Mellor的架构原则与Klein和Weiss合并成为两个列表：一个包含了原则和特性（表P-1），另一个包含了结构（表P-2）。然后我们要求各章的作者标出他们认为适用于自己那一章的术语，得到了每一章对应的说明。在这些表中，你可以看到各章说明中出现的每个原则、特性或架构结构的定义。我们希望这些说明对你的阅读提供帮助，它们清晰地总结每一章的内容。但是我们强烈建议你深入阅读每章的内容，而不只是停留在这些说明上。
表P-1：架构原则与特性
原则或特性 架构能够……
功能多样性 ……提供“足够好”的机制，利用简洁的表达来处理各种问题
概念完整性 ……提供单一的、最优的、无冗余的方式来表示一组类似问题的解决方案
修改独立性 ……保持它的元素的独立性，这样就能够让需要的修改最少，从而适应变化
自动传播 ……通过在模块之间传播数据或行为，保持一致性和正确性
可构建性 ……指导软件进行一致、正确的构建
增长适应性 ……考虑到可能的增长
熵增抵抗力 ……通过适应、限制和隔离变化的影响来保持有序
表P-2：架构结构
结构 结构能够……
模块 ……将设计或实现决定隐藏在一个稳定的接口之后
依赖关系 ……按照一个模块使用另一个模块的功能的方式来组织模块
进程 ……封装并隔离一个模块的运行时状态
数据访问 ……隔离数据，设置数据访问权限
本书体例
我们在本书中使用下面的印刷惯例：
斜体（Italic）
表示URL、邮件地址。
等宽字体（Constant width）
用于程序清单，以及在段落中引用程序元素，如变量名或函数名、数据库、数据类型、环境变量、语句和关键字。
等宽粗体（Constant width bold）
表示命令或其他由用户输入的文本。
等宽斜体（Constant width italic）
表示应该由用户输入的值或上下文相关的值来替代的文本。
使用代码示例
这本书的目的是帮助你完成自己的工作。一般来说，你可以在程序中使用这本书中的代码和文档。你不需要联系我们获得许可，除非你打算复制大量的代码。例如，写一个程序使用本书中的几段代码是不需要获得许可的。销售或发行来自O'eilly书籍的示例光盘需要许可。引用本书来回答问题或引用示例代码不需要许可。在产品文档中包含大量本书的示例代码需要获得许可。
我们希望在引用时说明来源，但这不是必需的。来源说明通常包括标题、作者、出版商和ISBN号。例如：“Beautiful Architecture, edited by Diomidis Spinellis and Georgios Gousios. Copyright 2009 O誖eilly Media, Inc., 978-0-596-51798-4.”
如果你觉得对示例代码的使用超过了这里的许可，请通过permissions@oreilly.com联系我们。
我们的联系方式
请把涉及本书的评论和疑问邮寄至以下地址：
美国：
O'eilly Media, Inc.
1005 Gravenstein Highway North
Sebastopol, CA 95472
中国：
100035北京市西城区西直门南大街2号成铭大厦C座807室
奥莱利技术咨询（北京）有限公司
我们为本书制作了网页，上面列出了勘误表、示例和任何附加的信息。该网页地址为：
http://www.oreilly.com/catalog/9780596517984
http://www.oreilly.com.cn/book.php bn=978-7-111-28356-0
为了评论或获得本书的技术支持，请发E-mail至以下地址：
bookquestions@oreilly.com
info@mail.oreilly.com.cm
欲获得其他图书、会议、资源中心和O誖eilly网络的更多信息，请访问以下网址：
http://www.oreilly.com
致谢
一本书的出版是一个团队努力的结果，一本合集更是如此。我们要感谢许多人。首先， 我们要感谢本书的诸位作者，他们及时地提供了优秀的素材，然后满足了我们多次改动和修订的要求。这本书的审阅者包括Robert A. Maksimchuk、Gary Pollice、David West、Greg Wilson和Bobbi Young，他们给出了许多极好的建议，改进了每一章和整本书。在O誖eilly，我们的编辑Mary Treseler帮助我们联系作者，组织复审过程，高效地管理本书的出版过程。后来，Sarah Schneider作为本书的制作编辑，巧妙地处理了紧张的进度计划和经常发生冲突的要求。文字编辑Genevieve d誆ntremont和编索引者Fred Brown灵巧地理顺了来自世界各地的作者的材料，让它们就像是一个人写出来的那样流畅。插图作者Robert Romano设法将我们提供的各种图像格式（包括一些手绘的草图）变成专业的图表。封面设计者Karen Montgomery设计了漂亮的、让人兴奋的封面，切合本书的内容。版式设计者David Futato设计了创新而实用的布局结构，将每章的说明与图书的设计集成在一起。最后，我们要感谢我们的家人和朋友在我们将精力集中在这本书上时给予的支持，这些时间本应属于他们。
计算机\软件工程
“这本书的作者们在介绍软件架构的基本实践和最佳实践方面干得很漂亮，他们也同样漂亮地介绍了各式各样的现代系统。我特别喜欢他们谈及的架构的广泛性，从Emacs到Facebook，从非常正式的系统到非常有灵气的系统。
简而言之，这是一本非常及时的书，对于软件架构的艺术、科学和实践是非常有益的贡献。”
-- Grady Booch，IBM院士
健壮、优雅、灵活和易维护的软件架构是怎样构成的？《架构之美》通过一系列优秀的文章回答了这个问题，这些文章来自于十几位当今一流的软件设计师和架构师。在每篇文章中，作者向我们展示了一个值得注意的软件架构，并分析了什么让它具有创新性，让它极其符合它的设计目标。
在这本书中，您将看到：
l Facebook的架构如何建立在以数据为中心的应用生态系统之上
l Xen的创新架构对操作系统未来的影响
l KDE项目的社群过程如何让软件的架构从粗略的草图成为漂亮的系统
l 蔓延的特征如何让GNU Emacs获得从未想到过的功能
l Jikes RVM自优化、自支持的运行时环境背后的魔法
这本书的贡献者是：
John Klein and David Weiss Greg Lehey
Peter Goodliffe Rhys Newman and Christopher Dennis
Jim Waldo Ian Rogers and Dave Grove
Michael Nygard Jim Blandy
Brian Sletten Tim Adam and Mirko Boehm
Dave Fetterman Bertrand Meyer
Derek Murray and Keir Fraser Panagiotis Louridas
（美）Diomidis Spinellis & Georgios Gousios 编：暂无简介
王海鹏 等译：暂无简介
架构与美
王海鹏
人们在生活和工作中发现美并创造美，软件开发和架构设计也不例外。
架构之美体现了关注点的分离与结合。在软件设计中，设计师需要考虑多方面的关注点。漂亮的架构设计让这些关注点尽可能分离，然后以最简单的机制结合在一起，从而得到高内聚、低耦合的系统。例如在Darkstar项目中，架构师们考虑的重点就是如何将多人在线游戏的游戏逻辑与系统的可伸缩性分离开来，让游戏的开发者只要遵守少量的规则，就能够像编写单机游戏一样编写大规模多人在线游戏。又如REST架构风格，体现了对资源命名、请求处理和资源物理表现形式的关注点分离。资源的名称与请求资源时服务器的处理方式无关，请求者无需知道服务器端采取的技术，并且请求者本来就不关心服务器端的处理技术。资源的物理表示形式可以通过内容协商来决定，使系统可以支持多种物理表示形式，并可以方便地扩展。
架构之美注重表达的简洁性。“Don誸 Repeat Yourself”，好的架构致力于消除各种类型的信息重复。从结构化程序设计中的子程序和函数，到面向对象程序设计中的继承，无不体现了对表达简洁性的特殊偏爱。在敏捷方法学中，消除重复则是重构的主要目的之一。爱因斯坦说：“让它尽可能简单，但不要过于简单。”我们需要考虑所有必须考虑的关注点，然后用简洁漂亮的架构体现我们的关注。同时，简洁的架构之美也降低了软件的总体成本，从这个意义上说，“简洁性”又可以称为“经济性”。
架构之美需要解决实际问题，它既是艺术，也是生活。软件像建筑一样，它的美不能脱离它的实用价值。Bjarne Stroustrup说，人类文明运行于软件之上。每一个软件都有自己的架构，这些架构有的很美，有的不太美。从艺术的角度来说，美是创造矛盾并解决矛盾。架构的多关注点和表达简洁性就是一种矛盾，美丽的架构提供了这一矛盾的解决方法，让我们的内心产生一种愉快的感觉。
架构之美需要经过专业的学习才能更好地欣赏和创造。和所有的艺术之美一样，不是说不经过专业学习就不能欣赏，但是经过了专业的学习，就能更好地欣赏这种美的种种精妙之处。如果想要创造出这种美，那就必然要经过长期的专业学习。
架构之美经过时间打磨。像Facebook面向数据的Web服务、FQL和FML架构，是在对应不同实际需求的过程中逐渐发展起来。在应用程序架构形成的过程中，设计者不断面对新的关注点需求，不断对已有的架构进行修改，并发展出新的架构组件。这就是所谓的“演进式架构”。只有变化是永恒不变的。在架构设计初期，设计者会将一些关注点有意推迟到将来考虑，例如持久和并发。对于这些暂不考虑的关注点，设计者对它们的实现方式尽可能不做任何假定，从而保留更多的可能性，让不同关注点之间的耦合尽可能小。
架构之美没有定法。虽然有一些法则可供我们参考，却没有非如此不可的。《金刚经》云：“一切贤圣，皆以无为法而有差别。”
参加本书翻译工作的人员还有蔡黄辉、徐锋、王海燕、李国安、周建鸣、范俊、张海洲、谢伟奇、林冀、钱立强、甘莉萍。
在这本书的翻译过程中，我受益良多，因此郑重地向大家推荐它。
推荐序一
如何看到一滴水的美丽
支付宝（中国）公司业务架构师
《大道至简》作者
周爱民（aimingoo）
【一】
架构是一个过程，而非一个结果。
【二】
在大多数人的谈论中，架构是一个目标产物，而作为架构师的责任就是去生产它。所以无论如何，架构是可以“做”出来的，而且也应该有一些“做”的方法、技术、技巧。
有人问过我：架构的最主要产出是什么？我的答案是：图。这里面有两层含义：一层含义是如同建筑师描绘的蓝图一样，用于引导实施者；另一层含义是架构师头脑中清晰的目标系统。如果架构师头脑中没有系统清晰的图像，他是没有办法把它画出来的。
【三】
画家画的无非是物我。画物的画家，最终画的还是我见。所以，画家的笔最终描绘的是他自己心里的映像。
【四】
艺术是不可能被“生产”出来的，生产出来的，叫“艺术品”。
【五】
架构这个过程，是架构师洞见系统内在结构、规律、原则和逻辑的过程。真正的架构师是可以将自己放在系统中去的（例如作为系统中的任何一个角色），只有清晰地理解系统，才能简洁地描述它。而当架构师拿出了他所描述的“作品”的时候，架构这一过程就已经结束了。
【六】
一滴水滴落的过程中，有多少个形态的变化？
推荐序二
架构的架构
北京无限讯奇信息技术有限公司产品技术高级总监
黄冬
从编辑手里拿到厚厚的《架构之美》译稿时，恰巧是我刚刚讲完一场消息系统架构的讲座之后。而正是在昨天，一位想要创业的朋友跟我说要寻找一位懂得“架构”的高人与他一起创业。要知道与代码不同的是，“虚幻”的架构常常让人认为其有很多玄妙之处，只因它大多难以落在纸上。特别是与很多大师谈及架构时，经常落入他们的一些“陷阱”，并往往为自己达不到大师的精明与技巧而叹息。殊不知，被我们所津津乐道的这些架构，是他们在日常工作里经历了大量的错误、重复的尝试、无数的代码、长久的考验所积淀下来的只言片语。
本书将数十人的经历与只言片语，经过深思熟虑后抽象出规律，使之可以不断复用。而另一方面，又将架构的过程娓娓道来，尝试让读者思考架构的过程与思路。在这里，更多的过程与思考被展现出来，更多的原因与为什么让我们了解。
这本书里展现了很多绚丽的故事，犹如士兵阅读将军的传记一样，阅读本书将会让你更鼓起勇气追寻大师们的脚步，但永远要记住，每一滴汗水才真正是你成长路上的每一个记号，要在自己的工作里更深地去理解每一处不同，架构出属于自己的系统。
感谢译者和出版者为我们带来这样一本传奇的架构故事书。
推荐序三
美丽架构的含义
腾讯R&D研发总监 (Tencent Director Of R&D Development)
资深技术专家（Senior Technology Expert）
王速瑜
古人形容美女之美：“……增之一分则太长，减之一分则太短……”，深刻地揭示了“恰到好处”的美丽含义。当我拿到《架构之美》书稿时，我发现美丽的含义如此相似。
美丽至简。美丽的架构应尽可能简单，但不要过于简单。书中通过多种例子表达了这个最基本的道理。我见过很多大型的软件架构，从大型的电信网络管理系统，到大规模应用的互联网架构，以及企业级的ERP软件，系统总是遵循从无到有，从简单到复杂，再到简单这样的过程。最终，支撑这些大型系统稳定可靠运行的就是这个最基本的道理。
美丽的架构应尽可能精益，并且是演进式发展的。当你架构一个亿万人同时在线的大规模网站系统的时候，你无法从一开始就提供最完善的解决方案，它应该是随着用户的增长而可扩展的。精益的思想让你避免了过度设计，也使架构不断演进，趋于完美。书中从企业级应用架构、用户级应用架构等多个角度提供了相应的解决方案，对于架构师无不是一顿美味的大餐。
深夜看完这本书稿后，我发现，架构之美并不简单，它没有定法。但是，它将为架构师们提供一把进入“美丽架构艺术馆”大门的钥匙。拿起它，您将会开启这扇大门！
推荐序四
美丽架构之道
《构建高性能Web站点》作者
Web架构实践者
郭欣
我无法给架构下一个简单的定义，因为任何定义都会束缚你对架构的无限想象。不可否认，架构师早已出现在人类几千年前的各项生产活动中，比如建筑、音乐。而在计算机软件及Web领域，架构的设计直接影响着系统的生产，比如开发过程和效率、代码和组件复用性等，同时也影响着系统的可用性、可伸缩性、性能、容量可预测性等。
本书更加关注架构之美。美丽的架构同样无法定义，可它却一定是自然的、简单的、可复用的、人文的，甚至是外行人也可以细细品味其思想的。当我看到超市的多个收银台排满长队时，便想到服务器并发处理性能和容量；当我看到十字路口的车辆等待转弯时，便想到它通过缓存思想来提高交通吞吐率。
那么如何设计出美丽的架构呢？从代码逻辑到物理网络，从单机到分布式，无数的技术可供架构师选择，如分层、组件化、服务化、标准化、缓存、分离、队列、复制、冗余、代理等，不过它们仍然只是“术”的范畴，而何时何处如何恰到好处地使用它们才是“道”的范畴，比如顿悟变化的道理，在博弈中寻找平衡，以系统化的角度来分析问题，寻找相对与绝对的奥秘、开放的心态……
然而，这个领域实在是太年轻了，我们需要更多的例子和经验，本书将让你大开眼界！
序
前言 5
第一部分 论架构
第1章 架构概述 13
1.1 简介 13
1.2 创建软件架构 19
1.3 架构结构 23
1.4 好的架构 27
1.5 美丽的架构 28
致谢 30
参考文献 31
第2章 两个系统的故事：现代软件神话 33
2.1 混乱大都市 34
2.2 设计之城 40
2.3 说明什么问题 47
2.4 轮到你了 48
参考文献 48
第二部分 企业级应用架构
第3章 伸缩性架构设计 51
3.1 简介 51
3.2 背景 52
3.3 架构 56
3.4 关于架构的思考 61
第4章 记忆留存 67
4.1 功能和约束 68
4.2 工作流 69
4.3 架构关注点 70
4.4 用户反应 90
4.5 结论 90
参考文献 90
第5章 面向资源的架构：在Web中 91
5.1 简介 91
5.2 传统的Web服务 92
5.3 Web 94
5.4 面向资源的架构 99
5.5 数据驱动的应用 102
5.6 应用面向资源的架构 103
5.7 结论 108
第6章 数据增长：Facebook平台的架构 109
6.1 简介 109
6.2 创建一个社会关系Web服务 114
6.3 创建社会关系数据查询服务 121
6.4 创建一个社会关系Web门户：FBML 129
6.5 系统的支持功能 142
6.6 总结 147
第三部分 系统架构
第7章 Xen和虚拟化之美 151
7.1 简介 151
7.2 Xenoservers 152
7.3 虚拟化的挑战 154
7.4 半虚拟化 155
7.5 Xen的变换形式 158
7.6 改变的硬件，改变的Xen 163
7.7 经验教训 165
7.8 延伸阅读 166
第8章 Guardian：一个容错操作系统环境 169
8.1 Tandem/16，将来所有的计算机都会像这样构建 170
8.2 硬件 170
8.3 物理布局 172
8.4 处理器架构 172
8.5 处理器间总线 178
8.6 输入/输出 178
8.7 进程结构 179
8.8 消息系统 179
8.9 文件系统 183
8.10 轶闻趣事 188
8.11 弊端 189
8.12 后继者 190
8.13 延伸阅读 191
第9章 JPC：一个纯Java的x86 PC模拟程序 193
9.1 简介 193
9.2 概念验证 195
9.3 PC架构 198
9.4 Java性能技巧 199
9.5 把4GB放入4GB：这不起作用 200
9.6 保护模式的危险 203
9.7 从事一项毫无成功希望的斗争 206
9.8 劫持JVM 210
9.9 终极灵活性 220
9.10 终极安全性 222
9.11 第二次做会更好 223
第10章 元循环虚拟机的力量：Jikes RVM 225
10.1 背景 225
10.2 与运行时环境相关的传言 227
10.3 Jikes RVM简史 229
10.4 一个自足执行的运行时自举 230
10.5 运行时组件 234
10.6 经验教训 246
参考文献 247
第四部分 最终用户应用架构
第11章 GNU Emacs：滋长的特性是其优势 251
11.1 使用中的Emacs 252
11.2 Emacs的架构 254
11.3 滋长的特性 260
11.4 另外两个架构 262
第12章 当集市开始构建教堂 267
12.1 简介 267
12.2 KDE项目的历史和组织结构 269
12.3 Akonadi 274
12.4 ThreadWeaver 289
第五部分 语言与架构
第13章 软件架构：面向对象与面向函数 299
13.1 概述 299
13.2 函数式示例 302
13.3 函数式解决方案的模块性评价 305
13.4 面向对象视图 313
13.5 面向对象模块性的评价和改进 319
13.6 代理：将操作封装到对象中 323
致谢 328
参考文献 328
第14章 重读经典 331
14.1 所有东西都是对象 335
14.2 类型是隐式定义的 342
14.3 问题 348
14.4 砖块和灰浆建筑架构 352
参考资料 359
跋 漂亮地构建 363
