《软件框架设计的艺术》书评

经典的书籍应该这样读

正如本书作者在序言中问到“仅仅是又多了一本设计书吗？”作者相信本书的存在“自有其必要性”，原因在于本书探讨的设计领域是如此的卓尔不群，却又是Java程序员在开发中必须要面对的问题，那就是框架的设计，API的设计。 我自认为对面向对象设计的掌握已经深入骨髓，对设计模式也算得上了然于胸，可在阅读本书时，我才发现自己所知不过是米粒之珠，对象设计原来还有更加广阔的世界。API设计的不同，已经超出了通常的面向对象设计讨论的范围。API的演化需要考虑的因素，比起一般的接口与类的设计，要更加地复杂与困难。面向对象设计有一个非常重要的原则是“开放-封闭原则（OCP），利用抽象以应对扩展，利用封装以隐藏实现，从而避免修改。这是我们在设计中需要遵循的一条重要法则。但我始终认为，要达成真正的开放与封闭，实则是一种遥不可及的理想，在现实的开发过程中，能做到修改尽量少，扩展尽量容易，就已经不错了。然而，对于一个已经拥有大量用户群体的框架与API而言，则必须追求OCP至极致，否则就会因为实现的不稳定性与版本的不兼容性，而被原有客户抱怨，甚至被抛弃。这正是框架设计与通常的企业应用系统设计最大的不同。托尔斯泰说过：“幸福的家庭总是相似的，而不幸的家庭则各有各的不幸。”设计亦然。好的设计原则可以放之四海而皆准，而设计的缺陷却各有各的表现特征。本书的最大特点是围绕着NetBeans的开发来说事儿，诉说其渊源、演化与设计的过失。这是真实的实践，不是拿着可笑的玩具项目阐释设计原则的方式所能比拟的。也许它失之于晦涩艰深，但只要你愿意仔细研磨，收获定能远超阅读的付出。不过，如果你是一位Java初学者，那就奉劝你远离此书，它会比“云计算”还要让你云里雾里。或许，你的职业发展目标，应以读懂本书为一个重要的里程碑。当你明白本书讲解的知识时，也许你已经可以驾驭面向对象设计与API设计了。阅读本书最好能结合NetBeans的源代码一起分析，如此方能领会设计之妙。其实在我看来，这是本书的硬伤。因为作者在讲解设计问题时，实在太罗嗦了。所谓“一图胜千言”，而对于我们这些代码狂热者而言，代码的清晰度远甚于冗长的描述。书中列出的UML图与代码实在太少了，通篇的文字描述让我们在阅读时感觉有些乏味。以我小人之心，会认为本书作者包藏“祸心”，因为本书可以大肆地推广NetBeans，他好像在说“读不懂吗？不明白吗？那快去下载NetBeans啊！”可惜我们必须接受这样的诱惑，因为读懂这本书的内容绝对能够让你的设计能力登上一个大大的台阶。Rod Johnson的名著Expert One-to-One J2EE Development without EJB，在书名中并未提到Spring，但书中对Spring设计的阐释，也许比任何一本Spring著作都要通透与权威，因为Rod Johnson正是Spring之父。本书的英文名Practical API Design同样没有提到NetBeans，但若要论NetBeans中的设计原则，本书作者Jaroslav Tulach自然是最佳选择，因为他正是NetBeans之父。在JavaLobby对他的采访（人民邮电出版社编辑李松峰在其博客上翻译了这篇采访）中，Jaroslav Tulach提到了写作本书的心路历程：“写这本书的素材我已经收集了10年之久了，因此我知道这本书绝不可能在短时间内写完。自从去年夏天，我表弟促使我下定决心之后，写这本书大概花了整整一年时间，包括整理笔记和修改润色。”可以说，本书事实上是伴随着NetBeans的成长而孕育成熟直至诞生。本书为我们描绘了API设计的壮丽画卷，这里的景色美不胜收，又仿佛如蒙娜丽莎的微笑那般神秘。在设计的旅途中，我们充满敬畏，却又应保持足够的怀疑，这是我一直以来的阅读态度。本书我已经阅读到了第15章。书中提到的许多设计技巧与原则，让我欣喜不已；然而也有许多讲解让我疑惑。当我发现，为了保证API的向后兼容，不得不牺牲设计上的优雅与美时，这让我有些不快，却又必须无奈地接受现实。还有5章的内容，我就要结束本书的阅读了。然而，这仅仅是开始，因为我对书中许多内容依旧抱有困惑，甚至没能明白个中含义。我还需要阅读第二遍，第三遍……经典的书籍就应该这样阅读。摘自：http://www.infoq.com/cn/news/2011/06/practical-api-design

又一本扯淡的书，还可以

以扯淡为主，轻松好看，不要指望是一本很有含量的书，就象闲侃，你不要要求那么多，牛B的人跟你闲侃，不要想从中得到诸多专业的知识字数不够，好吧，总结下：这本书是闲谈某个软件开发的架构的一些问题，相当于论坛帖子集合 够了吗？

为啥评价这么高呢

大部分的篇幅在扯淡，感觉整个书的主题是如何设计前后兼容的API。大部分在讲一些设计API的小技巧，基本没有涉及到如何设计完整的软件框架。没看过的没必要花时间看了，还不如看看这个：Java API Design Checklist，http://dongxi.net/b14gn。

中文书名坑爹

英文书名是：Practical API Design: Confessions of a Java Framework Architect。Practical API Design这个才是真正的书名。

不仅仅适合API设计的书籍

本书的作者是NetBeans的创始人，而我和NetBeans结缘始于2011年ACM的东北赛区竞赛。当时竞赛方东北大学给我们提供的是Ubuntu + Eclipse + NetBeans，其中Eclipse没有挂CDT，而我当时不知到NetBeans已经支持C++了，所以看见这个配置非常纠结，差点就有用Make的冲动了。可以说这是我第一次用NetBeans，不过和NetBeans至此结缘，我现在无论在Linux还是Windows上都是用的NetBeans写C++，至于VS 2010只是在做相关的平台移植的时候用来测试。可以说使用NetBeans去写程序非常舒服而且在做测试，集成，版本控制等方面非常好，其对CVS/SubVersion/Git的无缝集成非常好，除了配置CVS的ROOT以外，我现在不会手动写CVS命令。而通过阅读这本书，我看到了NetBeans作为一个开源框架的另外一面，看到了设计背后的哲学与取舍，这不仅仅是设计API的哲学，我们自己在编写代码的时候不是也可以使用这些哲学吗？这本书JAVA描述，对于我这个标准的C++控来说还是很纠结的，对于package、反射、配置文件解析。。。这些东西，虽然能理解，但是想应用到C++里面可谓难上加难，并不是技术原因，而是因为设计哲学不一样，就像C++中设计模式的运用远没有JAVA来的广泛，更不用说C++不支持jar这样的灵活性了。。。不过本书讲解的很多东西不仅仅只能用在JAVA上，在其他的语言上也能给读者带来启迪。另外，不得不说一下，知道这本书是先从英文版知道的。。。后来才知道这本书的中文名。。。我只能说中国的出版商对于图书命名“创意无限”。。。

评软件框架设计的艺术

不知有多少人和我一样，对自己日常使用的开发框架和IDE的作者充满敬意，对它们的开发过程充满好奇。如果你也使用过NetBeans，曾把它当作日常IDE，那么你应该会对《软件框架设计的艺术》感兴趣，因为其中包含了NetBeans创始人Jaroslav Tulach在设计NetBeans过程中总结出来的经验教训，设计心得，同时，这也是NetBeans的一部备忘录。 首先，如果你还未阅读本书，或者还未购买本书，我希望你能够做好心理准备，本书并不是为初学者所准备的。俗话说的好，没有金刚钻别揽瓷器活，要是没有一些相关的实践经验，阅读本书会有一定的困难，至少会浪费你的时间和金钱。这里我所说的相关经验并不是简单地开发一些小型网站。开发一个框架或API和开发应用系统还是有很多不同的。 全书分为三个部分——理论与理由、设计实践与日常生活，阅读指南给出了一个很好的建议，如果你对那过于理论充满哲学论调的第一部分不感冒，不妨先从第二部分开始，之后再来阅读开头的理论部分。但我的建议还是按照顺序阅读吧，至少从一开始你就能知道我们和自己的前辈所处的环境不同，几何学是多么的纯粹，什么才是优雅的程序语言，为什么说现在的程序员中有一大部分是在“针对性无绪”(这里作者并没有贬低不深入了解很多内容也可以完成任务的意思)，好歹你可以知道什么是API，什么是SPI，光这些知识就可以让你受益匪浅了。再不然，那张Will Code HTML For Food的插图也能博你一笑，不要把自己看得太高了。 “博学”一词似乎总与“大师”行影不离，不少人虽然从事IT行业，但却拥有艺术学位，有的在物理化学方面颇有造诣。Jaroslav在序言中就用他的天体物理和历史知识将我折服了，通过那个恒星的比喻，让我对API的设计有了新的认识。 在设计实践部分中，你会读到很多技巧性的内容，有些是你了解的，有些是你知其然不知其所以然的，有些是你所未曾了解过的，更有一些是与你理解中的知识所冲突的……这也就是为什么说开发一个框架不同于开发一套应用系统。知道设计模式的人都可以说出如何实现工厂模式，但又有多少人可以说清楚工厂方法优于构造方法的？用过Sonar等类似工具的人都会知道，它们会提示你将一些类声明为final的，但你又可曾想过其中的原因？整天把“面向接口编程”挂在嘴边，那究竟什么是接口？不要狭义地认为这个接口就是Java中的interface，它的含义远不局限于此，设计一个好的接口也是有讲究的。这些问题的答案都可以在设计实践部分里找到。 现在Spring基本成为了多数Java应用系统开发中的标配，谈及框架几乎必定会涉及到它，它把依赖的概念带给了大家，也提供了组件和服务等模块化的思想（当然和OSGi还是有所区别的）。在“模块化架构”一节中，Jaroslav专门介绍了NetBeans的Lookup机制、Java 6的ServiceLoader和Spring提供的依赖注入，可以让人更好地理解组件注入和服务定位，至少可以更好地理解Spring的依赖注入机制。本节还提及了扩展和扩展点，关于这个概念我在初次接触时也曾有过怀疑，真的很有用么，不用也挺好啊，但只有真的遇到了特定的场景才能体会到设计扩展点的用意，读到这段真的让我深有感触。 作为一本翻译的技术书籍，其翻译质量也会影响读者的阅读体验。我可以感受到译者在翻译过程中下了很大的功夫，从书中大量的译者注就可以体现出译者的敬业精神，甚至可以看得出他专门读过NetBeans的源码。本书的内容丰富，对学习如何设计一个好的框架很有指导意义，有兴趣的读者不妨自己去品味一下。 摘自http://www.infoq.com/cn/news/2011/06/practical-api-design

很实用

学习就好比打仗，如果《XX之美》相当于纸上谈兵，《XX架构模式》相当于冲锋陷阵，那么这本书就是战后修整。能够规范你的设计，让你少走弯路，让你不至于迷失在模式和新技术中。＝＝＝＝＝＝＝＝＝＝＝抱歉，你的评论太短了＝＝＝＝＝＝＝＝＝＝＝

排版相当差，翻译很一般，不建议购买

买之前先到豆瓣来看了看，发现有位“胖子”同学的评论说翻译的好。于是下决心买了。不过……1. 排版问题。书到手打开一看，晕，满页满页的黑块。 你388页的书卖75，就不能把版面好好整整么？至于这样省纸啊？2.翻译问题。不能说译者不认真，但我个人感觉是译者因为技术水平的局限，并不知道本书的作者在谈什么问题，翻译过来的东西读起来很别扭。就好比作者在原著上画的是个美女，而翻过来的东西就变成了说有个女人胸大屁股大，给读者毫无美感。

这本书很赞

早在英文版还没有翻译的时候就关注这本书，对于书中所立足的角度实在是非常的难能可贵的，软件开发领域一直存在着很多所谓下意识的，凭感觉的，不可捉摸的工作内容，就像api的设计，要把这样的问题阐释清楚实在不是易事。是原作者对于探索问题的热忱才使得那些模糊难以描述的问题得以清晰明了，感谢原作者。同样也要感谢译者，读了不到一章译者的用心早就跃然纸上，特此对王小磊和朱小兴表示深深的致敬

除了书名，其它都好

先不论作者的文章如何，就译者的认真和努力，就值得看，对于原作者的一些内容，译者都增加了自己的说明，书整体阅读非常流畅，在看过的翻译的书，这个算得上是上乘之作了。抱歉，你的评论太短了好吧，其实我想称赞的译者，如果有一些java基础或设计模式的基础，看这本书会流畅一些，理解起来也会容易一点，最好还有面向对象的思想。

思想未必是最新、最独特的，但一定是有用的

正如该书“阅读指南“中所说，该书比较啰嗦。不过，老外有此风格的不是一个、两个，忍了。全书的主题紧紧围绕”无绪“的概念进行，所谓”无绪“，就是指某些事情并不需要对背后的原理、规则有深刻的理解，就可以使用。典型的，不懂得汽车的原理，但我们照样开车，而且开得还不错。当今，软件开发世界中，更多的应用往往只是将不同的框架、组件进行集成，以满足自身的业务需求，而对这些被集成的”部件“并不一定需要深入了解其背后的细节、原理。这也导致了软件开发从严谨的结构化设计（一步步分解、整合设计出全新的系统）向如何更好的”集成与拼装“设计转化，也是敏捷开发得以盛行的基础，因为不需要从无到有的进行创造。当然也有不好的后果，更多的分不清需求和设计之间的界限，系统设计和详细设计之间的界限，也不想分清。其实这本书，最吸引我的还是作者本身提供的很多自身案例，对我们自身的工作方式有很多启发，摘录一些分享：知识传递的困难：”想要将知识传授给其他人的时候，就会因为他们没有类似于我们的经验，也就很难说服他们接受我们的知识“程序员的骄傲：”P2 一年后，我证明了当时的这一猜测。因为Netbeans是一个开源项目，有一个API吸引了一个外部的开发人员。开始的时候，这位外部代码贡献者主要是做一些修复Bug的工作。随后，他开始单独负责一个子项目，并设计相关的API。原先负责设计这个API的人说他发现这个子项目的API变得越来越差，但他找不出原因，希望我帮一手。他说：非常不喜欢这些新的API，更不想把它们集成到他负责的项目中。但他也同样说不清楚这些新的API到底有什么问题。最后，他说这些新的API看起来和他原来的设想不一致。我曾经也对他说过类似的话。以我的标准来评价的话，他所编写的API与NetBeans的API的设想不一致！“Java世界的”迷炫“：P111 2001年，我们给JavaOne大会提交了一份名为“组件定位与协作”的议题，该议题中的内容与本章多少有些关系，我们认为该议题涉及的内容对于所有的模块化程序都很重要。然而，当时的JavaOne会议的组委会可能仅仅因为觉得这个议题的名称不够酷，或者可能因为他们觉得组件这个词用得太滥了，要知道“组件”这个词几乎包含了所有可以想象的内容，所以没有接受该议题。直到2006年，我和同事Tim Boudreau又提交了一份类似的议题，名为“模块化架构中那些发现注入和依赖注入的模式”。果然，如我们所料，议题被组委会接受了。这说明一定要找到能够贴近目标人群的术语才能打动他们。一旦听到“依赖注入”这个词，他们的心就被打动了。就像API这个词一样，恰当的名称有益交流。对于用户来说，他们越容易理解API这个词，就越容易接受API的相关内容。留一条路给自己，扁鹊的大哥没那么好做：开发人员抱怨的事项总是不断，如评审、编程规范，等等。但API监护人需要时刻保持警醒的状态，否则就可能因为一个小小的疏忽而引发问题。另一方面，不是出个小问题，至少说明了你所做的工作确实很有用。