内容提要
靈活軟體開發：原則、模式與實踐（c#版.修訂版）
享譽全球的面向對象技術大師robert c. martin在本書中深入而生動地使用真實案例講解了面向對象設計的基本原則、重要的設計模式、uml和靈活方法。
本書java版曾榮獲2003年第13屆jolt大獎，是公認的典著作。本書是c#程式員提升功力的絕佳教程，也可用作高校計算機、軟體工程專業大學生、研究所學生的教材或參考書。
版權聲明
authorized translation from the english language edition entitled _agile principles, patterns, and practices in c#, _1st edition, 0131857258 by robert c. martin and micah martin, published by pearson education, inc, publishing as prentice hall, copyright © 2007 pearson education, inc.
all rights reserved. no part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or by any information storage retrieval system, without permission from pearson education, inc.
chinese simplified language edition published by pearson education asia ltd., and posts & telecommunications press copyright © 2012.
本書中文簡體字版由pearson education asia ltd.授權人民郵電出版社獨家出版。未經出版者書面許可，不得以任何方式複制或抄襲本書内容。
本書封面貼有pearson education（培生教育出版集團）雷射防僞标簽，無标簽者不得銷售。
版權所有，侵權必究。
譯者序
2002年10月，“bob大叔”（robert c. martin）終于推出了軟體開發社團期待已久的agile software development, principles, patterns, and practices一書。該書以真實案例為基礎，通過真實開發場景再現的方式對軟體開發中涉及的各種知識及其有效的運用方法進行了講解。這種做法得到了廣大軟體從業人員的一緻認可。該書一出版就好評如潮，并毫無争議地獲得了第13屆軟體開發圖書類的jolt大獎。
次年，“bob大叔”又推出了另外一本書uml for java programmers。該書秉承了上一本書的講解風格，不過其重點在于uml。“bob大叔”在書中介紹了一些常用的uml特性；更為重要的是，他把重點放在了如何在真實的項目開發中，以注重實效的态度來使用uml。對于那些習慣于動辄畫數十頁精美的uml圖，并把這些uml圖當成真正的軟體設計的架構師們來說，該書無疑是對他們的當頭棒喝。
應該說，這兩本書中所教授的内容和思維方法是與具體程式設計語言無關的，但是許多軟體開發人員還是很希望這些知識能夠基于自己特定的語言和開發平台進行講解。作為一名資深的軟體咨詢大師，“bob大叔”當然很清楚這一點。為了讓.net開發社團也能夠像java社團那樣，學習到這些可以改善軟體開發狀況，并讓程式員感受到開發樂趣的靈活開發和靈活設計的權威知識，“bob大叔”于2006年7月推出了一本新書agile principles, patterns, and practices in c#，也就是讀者正在閱讀的這本書。按照“bob大叔”的說法，這本書是他前兩本書的合訂本。
在本書中，“bob大叔”去除了前兩本書中的重複内容，并把它們有機地融合在一起。此外，對于書中的案例也做了相應的調整，去掉了不為大多數開發人員熟悉的氣象站案例以及略顯倉促的ets案例。“bob大叔”對具有典型代表性的薪水支付應用案例進行了增強，使其貫穿全書，并增加了關于資料庫和mvp模式兩章内容使得該案例更加完整。這種做法使得本書讀起來更加順暢。讀者花一本書的價格買到“bob大叔”的兩本經典著作，從某種意義上來講可以看作是“bob大叔”對.net社團作出的補償。
能夠在4年後再次翻譯“bob大叔”的這本新書，對我個人而言，既是一種榮幸，同時也是對這幾年靈活開發實踐的一次難得的反思、總結以及再學習的機會。曾經有讀者認為本書中講的東西太多、太雜，很多内容完全可以獨立成書，放在一起顯得比較散亂。我不認同這種觀點。靈活開發的核心就是以最低的成本，最快速地為客戶提供價值。書中所講述的過程方法、實踐、設計原則、模式以及思考方式看似獨立，其實都圍繞在這個核心周圍，并以互相支援的方式為達成這個核心目标服務。為了能夠快速提供價值，我們應用短疊代、快速傳遞的開發方法；為了保證這些價值是客戶真正需要的，我們和客戶緊密合作并應用回報驅動的方法；為了能夠降低軟體的演化和維護成本，我們應用好的設計原則和模式；為了降低設計成本，我們采用測試驅動、随時重構、演化設計的方法……如果能夠以這個核心為主線去了解和學習書中教授的内容，效果應該會更好一些。我這幾年的實踐經曆也證明了這一點。
軟體開發應該是一項充滿快樂和激情的工作，衷心希望本書能夠幫助國内.net社團的程式員朋友體會到這種快樂和激情。
鄧 輝
靈活宣言遵循的原則
我們遵循以下原則。
我們最優先要做的是通過盡早地、持續地傳遞有價值的軟體來滿足客戶需要。
我們歡迎需求的變化，即使到了開發後期。靈活過程能夠駕馭變化，為客戶創造競争優勢。
經常傳遞可以工作的軟體，從幾個星期到幾個月，時間間隔越短越好。
在整個項目開發期間，業務人員和開發人員必須朝夕工作在一起。
依靠鬥志高昂的人建構項目。給他們提供所需的環境和支援，并且信任他們能夠完成任務。
在團隊内部，最有效率也最有效果的資訊傳達方式，就是面對面的交談。
可以工作的軟體是進度主要的度量标準。
靈活過程提倡可持續開發。出資人、開發者和使用者應該總是保持穩定的開發速度。
對卓越技術和良好設計的不斷追求有助于提高靈活性。
簡單—盡量減少工作量的藝術是至關重要的。
最好的構架、需求和設計都源自自我組織的團隊。
每隔一定時間，團隊都要總結如何更有效率，然後相應地調整自己的行為。
靈活軟體開發宣言
我們正在通過親身實踐以及幫助他人實踐，揭示更好的軟體開發方法。通過這項工作，我們認為：
人和互動 重于 過程和工具
可以工作的軟體 重于 面面俱到的文檔
客戶合作 重于 合同談判
随時應對變化 重于 遵循計劃
雖然右項也有其價值，但我們認為左項更加重要。
kent beck james grenning robert c.martin
mike beedle jim highsmith steve mellor
arie van bennekum andrew hunt ken schwaber
alistair cockburn ron jeffries jeff sutherland
ward cunningham jon kern dave thomas
martin fowler brian marick
chris sells序
在我的職業程式設計生涯中，所做的第一份工作是為一個bug資料庫增加功能。這些功能主要是為明尼蘇達大學農場校區的植物病理系服務的，是以這裡的“bug”指的是真正的bug，比如蚜蟲、蝗蟲以及毛蟲。資料庫的代碼原來是由一位昆蟲學家編寫的，他所掌握的dbase知識僅僅能夠編寫出一種類型的表格，然後就在應用的其餘部分到處複制。在我增加功能時，我把功能盡可能地集中在一起，這樣就可以在一個地方修正代碼的bug，并且也可以在一個地方增加功能。這項工作花費了我整整一個夏天，最終的功能是原來的兩倍，但是代碼規模卻隻有原來的一半。
許多年後，我和我的一位朋友因手邊沒有什麼急迫的工作要做，是以決定一起編一些程式（編寫的要麼是idispatch，要麼是imoniker2，當時我們認為這兩個東西都很重要）。我先編寫一會兒代碼，而他在邊上觀看，并告訴我哪裡寫錯了。接着，他掌控鍵盤，而我在旁邊提建議，然後他把鍵盤的控制權又交給我。就這樣持續了幾個小時，這是我最為滿意的一段編碼經曆。
之後不久，我的朋友就聘用我來擔任他的公司新成立的軟體部門的首席架構師。作為架構工作的一部分，我經常會為一些還沒有存在的對象（我假想它們已經存在）編寫客戶代碼，并把代碼移交給工程師，由他們來繼續實作直到客戶程式能夠工作。
我猜我對靈活開發方法各個方面的實踐體驗并非個例。總的來說，我在靈活方法（比如重構、結對程式設計以及測試驅動開發）方面的實踐是成功的，雖然我對自己所做的還沒有非常清楚的認識。當然，在這之前我是可以擷取一些靈活開發方面的資料的，但是正如我不願意從《國家地理雜志》的過期刊物中學習如何邀請女孩跳舞一樣，我更希望靈活技術能夠适合于我的特定情況，也就是.net。和那些費盡心思去學習學生中間的流行語的中學老師一樣，robert使用.net（即使他很清楚地指出，.net在很多方面并不比java優秀）在講述我使用的語言，但他知道内容本身要比傳達媒體更重要。
除了.net外，我還喜歡在嘗試新東西時，能夠循序漸進、逐漸深入，不至于感到恐懼，但是又可以真正了解所有重要的東西。而這正是bob大叔（robert martin）在本書中所做的。他的介紹性章節講述了靈活運動的基礎知識，但沒有急于向讀者提及scrum、極限程式設計以及任何其他的靈活方法，進而使讀者能夠以一種自己喜歡的方式來逐漸進行了解。更好的是（也是robert寫作風格中我最喜歡的部分），他是通過實踐來展示這些技術的：提出一個問題，分析它，就像發生在真實環境中一樣；展現出錯誤和失策的地方以及如何通過應用他所主張的技術來解決這些問題。
我不知道robert在本書中描述的情況在現實中是否存在。我隻是在自己的經曆中曾經隐約有過這樣的體驗。但是，可以肯定的是，所有比較“酷”的年輕人都在這樣做。請把bob大叔當作自己在靈活世界中的優秀導師，他的唯一目标就是當你想去體驗時，能夠讓你做好，并且保證每個人都享受其中的樂趣。
1chris sells是世界知名的.net技術專家。曾被微軟授予“軟體傳奇人物”（software legend）稱号。代表著作有《windows forms程式設計》（人民郵電出版社，2004）等。——編者注
2idispatch和imoniker都是微軟com模型中的接口名。—編者注
erich gamma序
寫這篇序時，我剛剛傳遞了eclipse開源項目的一個主要版本。我仍然處在恢複階段，思維還有些模糊。但是有一件事情我卻比以往更加清楚，那就是：傳遞産品的關鍵因素是人，而不是過程。我們成功的訣竅很簡單：和那些全心緻力于傳遞軟體的人一起工作，使用适合于自己團隊的輕量過程進行開發，并且不斷調整。
看看我們團隊中的開發人員，他們都将程式設計視為開發活動的中心。他們不僅編寫代碼，還努力參悟代碼，以保持對系統的了解。使用代碼驗證設計，從中得到的回報對于增強設計的信心至關重要。同時，我們的開發人員了解模式、重構、測試、增量傳遞、頻繁建構和其他一些xp（極限程式設計）最佳實踐的重要性。這些實踐改變了我們對開發方法的認識。
對于那些具有高技術風險以及需求經常變化的項目來說，熟練地掌握這種開發方式是取得成功的先決條件。雖然靈活開發不注重形式和文檔，但是非常強調日常開發實踐。讓這些實踐付諸實施，正是本書的中心内容。
robert是面向對象社群的一位活躍分子，對于c++開發、設計模式以及面向對象設計的一般原則貢獻頗多，同時他很早就是一位xp和靈活方法的積極提倡者。本書就以他的衆多貢獻為基礎，全面講述了靈活開發實踐。這真是一項了不起的成就。不僅如此，robert在說明每個問題時，還使用了案例和大量的代碼，這與靈活實踐完全相符。他實際上是在通過實際程式設計來闡述程式設計和設計。
本書中充滿了對于軟體開發的真知灼見。不管你是想成為一位靈活（agile）開發人員，還是想進一步提高自己的技能，它都同樣有用。我對本書期盼已久，它沒有令我失望。
1erich gamma是ibm公司傑出工程師，面向對象技術大師，《設計模式》一書的第一作者。他與kent beck合作開發了測試架構junit。在ibm，他上司了eclipse平台的開發。此外，他還上司團隊協助開發了平台項目jazz。
業界大師鼎力推薦
“本書是對靈活程式設計和靈活原則最全面和最有價值的介紹……本書絕對是所有.net程式員必讀之作。”
—jesse liberty，微軟資深技術專家，programming c#作者
“我最喜愛的技術作家robert martin善于通過實踐展示技術，讓讀者能夠以自己喜歡的方式逐漸了解……請把bob大叔當做你在靈活世界裡的導師。”
—chris sells，.net資深技術專家，微軟“軟體傳奇人物”
“前幾天，我找到了記有我對bob大叔第一印象的備忘錄。上面寫着‘優秀的對象思想’。你手中的這本書就是能讓你受益終生的‘優秀的對象思想’。”
—kent beck，軟體開發大師，極限程式設計之父，設計模式先驅
“我期待這本書已經很久了，關于如何去掌握我們的行業技能，本書作者有非常豐富的實際經驗可以傳授。”
—martin fowler，軟體開發大師，《重構》與《企業應用架構模式》作者
“這本書中充滿了對于軟體開發的真知灼見。不管你是想成為一個靈活開發人員，還是想提高自己的技能，本書都同樣有用。我一直在期盼着這本書，它沒有令我失望。”
—erich gamma，軟體開發大師，《設計模式》作者
“在本書中，bob martin向我們展示了他作為開發大師以及教育家的天賦。書中都是重要的經驗，并且閱讀起來就是一種享受。他以其務實的判斷力和令人愉悅的風格給我們以啟迪。”
—craig larman，《uml和模式應用》作者
“這也許是第一部把靈活方法、模式和最新的軟體開發基本原則完美結合在一起的圖書。當bob martin發言時，我們最好洗耳恭聽。”
—john vlissides，軟體開發大師，《設計模式》作者
“本書作者成功地實作了目标，這要歸功于他三十多年的開發經驗。……本書對設計模式的闡述使我難以釋卷。”
—diomidis spinellis，軟體開發大師，《高品質程式設計藝術》作者
“以我之見，本書不愧為最佳面向對象設計圖書。”
—john wetherbie，javaranch.com
前言
可是bob，你說過去年就能寫完這本書的。
—claudia frers, 1999年uml world大會
bob的引言
離claudia說出這句合情合理的抱怨已經7年了，不過我覺得我已經做出了補償。在這幾年裡，我出版了3本書，對于一個同時經營着一家咨詢公司，并且還得進行大量的代碼編寫、教育訓練、指導、演講的工作，以及撰寫文章、專欄和部落格的人來講，要每隔一年出一本書是一項很大的挑戰，更不要說還得養活并陪伴一個大家庭了。但是，我喜歡這樣。
靈活開發（agile development）就是指能夠在需求迅速變化的情況下快速開發軟體。為了達到這種靈活性，我們需要使用一些實踐提供必要的準則和回報，需要使用一些設計原則使我們的軟體保持靈活且可維護，還需要了解一些已經被證明在特定問題中可以權衡這些原則的設計模式。本書試圖将這3個概念融彙起來，使它們成為有機的整體。
本書首先描述了這些原則、模式以及實踐，然後通過許多案例來示範如何應用它們。更重要的是，案例給出的并不是最終的結果，而是設計的過程。你會看到設計者犯錯誤；你會看到他們如何找到錯誤并最終改正；你會看到他們對問題苦思冥想，面對一些難以權衡的含糊問題的疑惑與探索。是的，你會看到設計的真正曆程。
micah的引言
2005年初，我參與到一個小的開發團隊中，該團隊正準備用c#開發一個.net應用程式。使用靈活開發實踐是團隊的強制性規定，這也是我參與其中的原因之一。雖然我以前曾經使用過c#，但是我的大部分程式設計經驗都是基于java和c++的。我認為.net不會有什麼不同，結果也表明确實如此。
項目開始兩個月後，我們進行了第一次釋出。這是一次部分釋出，其中隻包含了所有計劃特性中的一部分，但卻是完全可用的，并且也确實被投入使用。僅僅兩個月公司就得到了我們開發的軟體帶來的好處。管理層非常興奮，他們要求雇傭更多的人，這樣就可以啟動更多的項目。
我投身到靈活社群已經有幾年了，我認識很多可以幫助我們的靈活開發者。我通知了他們每一個人，請求他們加入到我們中來。結果，沒有一個靈活朋友加入我們的團隊。為什麼？也許最主要的原因是我們是基于.net進行開發的。
幾乎所有靈活開發者都具有java、c++或者smalltalk方面的背景。幾乎從來沒有聽說過有靈活.net程式員。也許，當我說我們正在使用.net進行靈活軟體開發時，我的那些朋友根本就沒當回事，也許他們想避免和.net有什麼瓜葛。這是一個嚴重的問題。我已經不止一次看到這種情況了。
我講過許多為期一周的關于各種軟體主題的課程，有機會見到來自世界各地的具有廣泛代表性的開發者。我曾經指導過的很多學生都是.net程式員，也有很多是java和c++程式員。恕我直言：在我的經曆中，.net程式員常常要比java和c++程式員差一些。當然，也并非總是如此。但是，通過在課堂中的再三觀察，我隻能得出這樣的結論：在靈活軟體實踐、設計模式、設計原則等方面，.net程式員往往要弱一些。在我的課堂上，.net程式員常常從來沒有聽說過這些基本概念。必須改變這種情況。
本書的另一版本，由我父親robert c. martin撰寫的agile software development: principles, patterns, and practices在2002年末出版，并赢得了2003年的jolt大獎。那是一本很好的書，得到了許多開發者的贊揚。遺憾的是，它對.net社群幾乎沒有提供什麼幫助。盡管書中的内容同樣适用于.net，但是幾乎沒有.net程式員讀過它。
我希望這本.net版本能夠充當.net社群和其他開發者社群之間的橋梁。我希望程式員能夠閱讀它并看到更好的建構軟體的方法。我希望他們開始使用更好的軟體實踐、建立更好的設計并提升.net應用的品質标準。我希望.net程式員可以和其他程式員一樣好。我希望.net程式員能夠在軟體社群中獲得新的地位，這樣java程式員就會以加入.net團隊為榮。
在完成本書的整個過程中，對于是否把我的名字放在一本與.net有關的圖書的封面上，我有過多次思想鬥争。我曾問自己是否要把名字和.net聯系在一起，并承擔可能由此帶來的所有負面後果，但現在我不再遲疑了。我是一名.net程式員。不！是一名靈活的.net程式員。我以此為榮。
關于本書
本書簡史
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代碼。希望你能夠仔細閱讀它們，因為在很大程度上，代碼正是本書的精髓。代碼是本書所講内容的實際展現。
本書采用重複講解的方式，由一系列不同規模的案例研究組成。有些案例非常小，有些案例則需要用幾章來描述。每個案例研究之前都有一些預備材料，其中講述了在該案例研究中将用到的面向對象設計原則和模式。
本書首先讨論了開發實踐和過程，其中穿插了許多小的案例研究以及示例。然後，我們轉移到設計和設計原則的主題上，接着是一些設計模式、更多管理包的設計原則以及更多的模式。所有這些主題都附有案例研究。
是以，請準備好學習一些代碼和uml（統一模組化語言）圖。你将要學習的圖書技術性非常強，其中要教授的知識就像惡魔一樣，盡在細節中{![原文為the devils are in the details，諺語，相當于韓非子所說的“千裡之堤，潰于蟻穴”，比喻細節之重要。
—編者注]}。
本書的内容結構
本書由四個部分和兩個附錄組成。
第一部分：靈活開發。本部分描述了靈活開發的概念。首先介紹了靈活聯盟宣言，然後提供了對極限程式設計（xp）的概述，接着讨論了許多闡明個别極限程式設計實踐的小案例，特别是那些影響設計和編寫代碼方式的實踐。
第二部分：靈活設計。本部分中的各章談論了面向對象軟體設計：什麼是面向對象軟體設計，管理複雜性的問題以及技術，面向對象類設計的一些原則。本部分最後幾章講述uml實用子集。
第三部分：薪水支付案例研究。它描述了一個簡單的批量處理薪水支付系統的面向對象設計和c#實作。本部分的前幾章描述了該案例研究會用到的一些設計模式。最後一章包含了完整的案例研究，這也是本書中最大和最完整的一個案例。
第四部分：打包薪水支付系統。本部分開始描述面向對象包設計的一些原則。接着，通過增量地打包上一部分中的類來繼續闡明這些原則。本部分最後講述薪水支付應用的資料庫和ui設計。
接下來是兩個附錄：附錄a，“雙公司記”；附錄b，jack reeves的文章“什麼是軟體”。
如何使用本書
如果你是一名開發人員，請從頭至尾閱讀本書。本書主要是寫給開發人員的，它包含以靈活方式開發軟體所需要的資訊。從頭至尾閱讀可以首先學習實踐，接着是原則，然後是模式，最後是把它們全部聯系起來的案例研究。把所有這些知識整合起來會幫助你完成項目。
如果你是一名管理人員或者業務分析師，請閱讀第一部分“靈活開發”。第1章～第6章提供了對靈活原則和實踐的深入讨論。内容涉及需求、計劃、測試、重構以及程式設計。它會給你一些有關如何建構團隊以及管理項目的指導，幫助你完成項目。
如果你想學習uml，請首先閱讀第13章~第19章。然後，閱讀第三部分“薪水支付案例研究”的所有章節。這種閱讀方法在uml文法和使用方面會給你提供一個好的基礎，同時也會幫助你在uml和c#語言之間進行轉換。
如果你想學習設計模式，請先閱讀第二部分“靈活設計”學習設計原則，然後閱讀第三部分“薪水支付案例研究”、第四部分“打包薪水支付系統”。這幾部分定義了所有的模式，并且展示了如何在典型的情形中使用它們。
如果你想學習面向對象設計原則，請閱讀第二部分“靈活設計”、第三部分“薪水支付案例研究”以及第四部分“打包薪水支付系統”。這些章節将會描述面向對象設計的原則，并且向你展示如何使用這些原則。
如果你想學習靈活開發方法，請閱讀第一部分“靈活開發”。這部分描述了靈活開發，内容涉及需求、計劃、測試、重構以及程式設計。
如果你隻想笑一笑，請閱讀附錄a“雙公司記”。
緻謝
衷心感謝以下人士：lowell lindstrom、brian button、erik meade、mike hill、michael feathers、jim newkirk、micah martin、angelique martin、susan rosso、talisha jefferson、ron jeffries、kent beck、jeff langr、david farber、bob koss、james grenning、lance welter、pascal roy、martin fowler、john goodsen、alan apt、paul hodgetts、phil markgraf、pete mcbreen、h. s. lahman、dave harris、james kanze、mark webster、chris biegay、alan francis、jessica d’amico、chris guzikowski、paul petralia、michelle housley、david chelimsky、paul pagel、tim ottinger、christoffer hedgate以及neil roodyn。
非常感謝grady booch和paul becker允許我在本書中使用原本用于grady的object-oriented____analysis and design with applications第3版中的章節。特别感謝jack reeves，他慷慨地允許我全文引用他的論文“什麼是軟體設計”（what is software design？）。
每章開頭處美妙的、偶爾還有些炫目的插圖是jennifer kohnke和我的女兒angela brooks繪制的。
3寫于1995~2001年的任何可信的學術作品中肯定使用了術語kuhnian。它指的是the structure____of scientific revolutions一書，作者為thomas s. kuhn，由芝加哥大學出版社出版于1962年。[庫恩是美國著名科學史家和哲學家，在其代表作《科學革命的結構》一書中提出了“範型轉換”（paradigm shift）理論。—編者注]
4 kent beck, test-driven development by example, addison-wesley, 2003。
本文僅用于學習和交流目的，不代表異步社群觀點。非商業轉載請注明作譯者、出處，并保留本文的原始連結。
目錄
第一部分 靈活開發
<a href="https://yq.aliyun.com/articles/96486">第1章 靈活實踐</a>
<a href="https://yq.aliyun.com/articles/96486">1.1節靈活聯盟</a>
<a href="https://yq.aliyun.com/articles/96515">1.2 原則</a>
<a href="https://yq.aliyun.com/articles/96518">1.3 結論</a>
<a href="https://yq.aliyun.com/articles/96520">1.4 參考文獻</a>
第二部分 靈活設計
<a href="https://yq.aliyun.com/articles/96530">第2章 極限程式設計概述</a>
<a href="https://yq.aliyun.com/articles/96530">2.1 極限程式設計實踐</a>
<a href="https://yq.aliyun.com/articles/96536">2.2 結論</a>
<a href="https://yq.aliyun.com/articles/96542">2.3 參考文獻</a>
第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 什麼是軟體
索引