这两天,看见 csdn,第二书店对Martin Fowler. 一查资料,才知道他居然是面向对象的教父级人物.
顿时肃然起敬.让我们来看看大师的著作吧.
现任Thought Works(思特沃克)公司首席科学家的Martin Fowler先生是当今世界软件开发领域最具影响力的五位大师之一。
作为一位敏捷软件开发方法的早期开拓者，Martin Fowler对IT 业的影响是不可估量的。
福勒先生的著作精品包括:
《重构－改善既有代码的设计》(Refactoring: Improving the Design of Existing Code) ，
《UML精粹：标准对象建模语言简明指南》(UML Distilled：A Brief Guide to the Standard Object Modeling) 第二版、
《分析模式：可重用的对象模型》(Analysis Patterns：Reusable Object Models) 、
《规划极限编程》(Planning Extreme Programming)、
《企业应用架构模式》(Patterns of Enterprise Application Architecture)。
据说有位先生曾在一个技术研讨会的午餐时间与他的邻桌讨论OO技术，当他得知对方是Thought Works的员工时，立刻懊恼地说：“我竟然试图教Martin Fowler的同事OO技术，这简直就是木匠门前玩斧头、大江边上卖水了。”作为这个圈子里最著名的“传教士”，MartinFowler有一种常人所不及的归纳总结、提纲挈领的能力。很多“古已有之”的技术都是经过了他的点石成金，才真正在开发者的芸芸众生中流行起来———重构技术就是一个最好的例子，而最近的例子则是Dependency Injection模式。
从他的作品中，我们可以明显地看出：Martin Fowler一直致力于为企业级应用开发者提供一套完备、自足的话语系统，一个理型的世界。Analysis Patterns告诉我们如何分析用户需求，Refactoring告诉我们如何改善代码质量，Planninge Xtreme Programming告诉我们如何规划敏捷的开发过程。这本PoEAA恰好是拼图的最后一块，它所记录的47个模式直指架构企业级应用时无法回避的那些问题。现在，Martin Fowler的信徒们可以完全用自己的一套话语来谈论企业级应用开发了。
面对这本PoEAA，或许不少读者会冒出这样一个念头：为什么我要使用这些模式？——这个问题从前的版本是“为什么要重构”、“为什么要采用多层结构”，它们背后的潜台词是“为什么我要给自己增加这些麻烦”。实用主义的陈词滥调我们已经听得太多了：优雅的设计提升灵活性和复用性、使系统便于维护……噢，一边做着设计，一边还要考虑“这里是否需要灵活性”，我不认为自己有那么好的精力。在我看来，这里只有一个问题：系统是否呈现出一种内在的美。在我的系统中采用Transaction Script模式让我感到缺乏美感，所以我把它重构成Domain Model模式，这就是我的方式。
我提到了“美感”，这是一种形而上学吗？软件开发的全部艺术就是权衡：在简单与复杂之间权衡，在一种方案与另一种方案之间权衡。如果把每个问题、每个权衡的利弊都考虑得清清楚楚，恐怕开发一个应用程序的成本会高得惊人。所以，很多时候我们更依赖自己的审美眼光，用平静的心去设计一个赏心悦目的系统。缺乏美感的程序通常也同时缺乏质量，从前曾经流行的“万能JSP”就已经充分证明了这一点。这本PoEAA就像一幅画卷，它向我们展示了具有美感的架构方案。如果能暂时抛开实用主义的立场，用审美的眼光去浏览这幅画卷，或许能引起你更多的共鸣。
但是，请不要忘了，MartinFowler同时也是一位敏捷方法的鼓吹者。在他看来，过度设计、堆砌模式的系统同样是缺乏美感的。就像这本PoEAA，如果把这47个模式全部用在一个系统里，最终得到的只能是一堆臃肿不堪的垃圾。于是，我只好不时看看自己脚上的鞋子，在心里默念“KISS”、“YAGNI”，然后继续在完美与简单之间权衡。PoEAA给了我们优雅的设计方案，但它并不保证用这些方案能够得到具有美感的架构设计，你仍然必须不断地选择、权衡。在这个领域里，没有银弹。不然，还要我们程序员干什么？
------
导读:
先看 《重构－改善既有代码的设计》
后看 《设计模式》,《分析模式：可重用的对象模型》
