20世纪90年代初，我（Bob）写了一本名为Designing Object-Oriented C++ Application using the Booch Method的书。它曾是我的代表作，其效果和销量都让我非常高兴。
这本书最初想作为Designing一书的第2版，但是结果却并非如此。书中所保留的原书内容非常少，只有3章内容，即便这3章也进行了大量的修改，但书的意图、精神以及许多知识是相同的。自Desinging出版10年以来，在软件设计和开发方面我又学到了非常多的知识，这些将在本书中表现出来。
10年过去了！Designing刚好在因特网大发展之前出版。从那时起，我们使用的缩略词的数量已经翻了一倍，诸如EJB、RMI、J2EE、XML、XSLT、HTML、ASP、JSP、ZOPE、SOAP、C#、.NET以及设计模式、Java、Servelet和应用服务器。我要告诉你，要使这本书的内容跟得上最新技术潮流非常困难。
与Booch的关系1997年，Booch与我联系，让我帮他撰写其非常成功的Object-Oriented Analysis and Design with____Applications一书的第3版。以前，我和他在一些项目中有过合作，并且是他的许多作品（包括UML）的热心读者和参编者。因此，我高兴地接受了，并邀请我的好朋友Jim Newkirk来帮助完成这项工作。
在接下来的两年中，我和Jim为Booch的书撰写了许多章节。当然，这些工作意味着我不可能按照我本来想的那样投入大量精力写作本书，但是我觉得Booch的书值得我这样做。另外，当时这本书完全只是Designing的第2版，并且我的心思也不在其上。如果我要讲些东西的话，我想讲些新的并且是不同的东西。
遗憾的是，Booch著作的这个版本始终没有完成。在正常情况下已经很难抽出空来写书了，在浮躁的.com泡沫时期，就更加不可能了。Grady忙于Rational以及Catapulse等新公司的事务。因此这项工作就停止了。最后，我问Grady和Addison-Wesley公司是否可以把我和Jim撰写的那些章节包含在本书中，他们很慷慨地同意了。于是，一些案例研究和UML的章节就由此而来。
极限编程的影响1998年后期，极限编程（XP）崭露头角，它有力地冲击了我们所信奉的关于软件开发的观念。我们是应该在编写任何代码前先画许多UML图呢？还是应该不使用任何UML图而仅仅编写大量代码？我们是应该撰写大量描述我们设计的叙述性文档？还是应该努力使代码具有自释义能力以及表达力，免除撰写辅助性文档的必要？我们应该结对编程吗？我们应该在编写产品代码前先编写测试吗？我们应该做什么呢？
这场变革来得正是时候。在20世纪90年代中后期，Object Mentor公司在面向对象设计以及项目管理问题上帮助了许多公司。我们帮助这些公司完成项目，在此过程中，我们慢慢地向这些公司灌输自己的一些观点和做法。遗憾的是，这些观点和做法没有被记录下来，它们只是我们对客户的口述。
到了1998年，我认识到需要把我们的过程和实践写下来，这样就可以更好地把它们传达给我们的客户。于是，我在C++ Report上撰写了许多关于过程的论文1，但这些文章都没有达到目的。它们提供了丰富的信息并且在某些情况下也很引人入胜，但是它们没有系统地反映我们在项目中实际应用的实践和看法，而是对影响我数十年的价值观念的一种不经意的放弃。Kent Beck向我指出了这一点。
与Kent Beck的关系1998年末，当我正为整理Object-Mentor过程烦恼时，我偶然看到了Kent在极限编程（XP）方面的一些文字。这些文字散布在Ward Cunningham的wiki2中，并且和其他一些人的文字混合在一起。尽管如此，通过努力我还是抓住了Kent 所谈论的要点。这激起了我极大的兴趣，但是仍有一些疑虑。XP中的某些东西和我的开发过程观念完全吻合，但是其他一些东西，比如缺乏明确的设计阶段，却令我迷惑不解。
我和Kent来自完全不同的软件环境。他是一个知名的Smalltalk顾问，而我却是一个知名的C++顾问。这两个领域之间很难相互交流。这之间几乎有一个库恩式的（Kuhnian）3范型隔阂。
如果不是看到他的观点，我绝无可能邀请Kent为C++ Report撰写论文。但是我们关于过程认识上的一致填补了语言上的隔阂。1999年2月，我在慕尼黑的OOP会议上遇到了Kent。他在进行关于XP的讲演，而我在进行面向对象设计原则的讲演，我们的会场所正好面对面。由于无法听到他的讲演，我就在午餐时找到了Kent。我们谈论了XP，我邀请他为C++ Report撰写了一篇论文。这是一篇很棒的论文，其中描述了Kent和一位同事在一小时左右的现场系统开发中所进行的彻底的设计改变。
在接下来的几个月中，我逐渐消除了自己对XP的担心。我最大的担心在于所采用的过程中没有一个明显的预先设计阶段，我对此有些犹豫。我不是一直在教导我的客户以及整个行业，设计非常重要，应该投入时间吗？
最后我认识到，实际上我自己也并不真正需要这样一个阶段。甚至在我撰写的所有关于设计、Booch图和UML图的论文以及图书中，总是把代码作为验证这些图是否有意义的一种方式。在我所有的客户咨询项目中，我会先花费1~2个小时帮助他们绘制一些图，然后会使用代码来指导他们考查这些图。我开始明白，虽然XP关于设计的措词有点陌生（在库恩式的意义上），但是这些措词背后的实践对我来说却很熟悉。
我关于XP的另一个担心相对比较容易解决。我私底下实际上一直是一个结对程序员。XP使我可以光明正大地和同伴沉醉于一起编程的快乐之中。重构、持续集成以及现场客户对我来说都非常熟悉。它们都非常接近于我先前对客户建议的工作方式。
有一个XP实践对我来说是新的发现。当你第一次听到测试驱动开发4（TDD）时会觉得它似乎很平常。它只是要在编写任何产品代码前先编写测试用例。编写的所有产品代码都是为了让失败的测试用例通过。对于这种方式编写代码所带来的意义深远的结果，我始料未及。这个实践完全改变了我编写软件的方法，并把它变得更好了。
于是，到1999年秋天，我确信Object Mentor应该采用XP作为自己的过程，并且我应该放弃编写自己过程的愿望。Kent在表达XP的实践和过程方面已经做了一项卓越的工作，相比起来我自己那些不充分的尝试就显得苍白无力了。
.NET在几个大公司之间一直在进行着一场战争。这些公司在为了赢得你的忠诚而战。这些公司相信，如果它们拥有了语言，那么它们将拥有程序员以及雇佣这些程序员的公司。
首先打响这场战争的是Java。Java是第一个由大公司创造的用来赢得程序员的编程语言。结果取得了极大的成功。Java确实深深地扎根于软件开发社团中，并成为现代多层IT应用开发的事实标准。
对此的还击之一来自IBM。IBM通过Eclipse开发环境占领了大部分的Java市场。另外一个对此的重大阻击来自微软的一些追求完美的设计者，他们给我们提供了通用的.NET平台和特定的C#语言。
令人惊异的是，很难对Java和C#做出区分。这两种语言在语义上是等同的，并且语法也非常相似，以至于许多代码片段都可以写得很相似。所有在技术创新上的不足，微软都通过其在能力上的卓越表现进行了超额的补偿，并赶超上来，赢得胜利。
本书的第一版是使用Java和C++作为编程语言编写的。本书使用了C#和.NET平台。不要把这看作是对某一方的支持。我们不会在这场战争中拥护某一方。事实上，我认为当几年后一种更好的语言出现并占领了参与交战的公司花费巨大代价赢得的程序员意向份额时，这场战争就会自行结束。
本书的.NET版本只是为了能够影响到.NET程序员。虽然本书中的原则、模式和实践与语言无关，但是案例研究却与语言相关。正如.NET程序员更加乐于阅读.NET案例研究一样，Java程序员则更加乐于阅读Java示例。
尽在细节中本书包含了许多.NET代码。希望你能够仔细阅读它们，因为在很大程度上，代码正是本书的精髓。代码是本书所讲内容的实际体现。
本书采用重复讲解的方式，由一系列不同规模的案例研究组成。有些案例非常小，有些案例则需要用几章来描述。每个案例研究之前都有一些预备材料，其中讲述了在该案例研究中将用到的面向对象设计原则和模式。
本书首先讨论了开发实践和过程，其中穿插了许多小的案例研究以及示例。然后，我们转移到设计和设计原则的主题上，接着是一些设计模式、更多管理包的设计原则以及更多的模式。所有这些主题都附有案例研究。
第一部分 敏捷开发第1章 敏捷实践1.2 原则1.3 结论 1.4 参考文献第二部分 敏捷设计第2章 极限编程概述2.1 极限编程实践2.2 结论2.3 参考文献第3章 计划第4章 测试第5章 重构第6章 一次编程实践第7章 什么是敏捷设计第8章 SRP：单一职责原则第9章 OCP：开放－封闭原则第10章 LSP：Liskov替换原则第11章 DIP：依赖倒置原则第12章 ISP：接口隔离原则第13章 写给C#程序员的UML概述第14章 使用UML第15章 状态图第16章 对象图第17章 用例第18章 顺序图第19章 类图第20章 咖啡的启示第三部分 薪水支付案例研究第21章 COMMAND模式和ACTIVE OBJECT模式：多功能与多任务第22章 TEMPLATE METHOD模式和STRATEGY模式：继承和委托第23章 FACADE模式和MEDIATOR模式第24章 SINGLETON模式和MONOSTATE模式第25章 NULL OBJECT模式第26章 薪水支付案例研究：第一次迭代开始第27章 薪水支付案例研究：实现第四部分 打包薪水支付系统第28章 包和组件的设计原则第29章 FACTORY模式第30章 薪水支付案例研究：包分析第31章 COMPOSITE模式第32章 OBSERVER——演化至模式第33章 ABSTRACT SERVER模式、 ADAPTER模式和BRIDGE模式第34章 PROXY模式和GATEWAY模式：管理第三方API第35章 VISITOR模式第36章 STATE模式第37章 薪水支付案例研究：数据库第38章 薪水支付系统用户界面：Model-View-Presenter附录A 双公司记附录B 什么是软件索引
相关资源：敏捷软件开发：原则、模式与实践(带书签高清C#版).pdf