重構(gòu)

前言

"重構(gòu)"這個(gè)概念來自Smalltalk圈子，沒多久就進(jìn)入了其他語言陣營(yíng)之中。由于重構(gòu)是框架開發(fā)中不可缺少的一部分，所以當(dāng)框架開發(fā)人員討論自己的工作時(shí)，這個(gè)術(shù)語就誕生了。當(dāng)他們精練自己的類繼承體系時(shí)，當(dāng)他們叫喊自己可以拿掉多少多少行代碼時(shí)，重構(gòu)的概念慢慢浮出水面?？蚣茉O(shè)計(jì)者知道，這東西不可能一開始就完全正確，它將隨著設(shè)計(jì)者的經(jīng)驗(yàn)成長(zhǎng)而進(jìn)化；他們也知道，代碼被閱讀和被修改的次數(shù)遠(yuǎn)遠(yuǎn)多于它被編寫的次數(shù)。保持代碼易讀、易修改的關(guān)鍵，就是重構(gòu)——對(duì)框架而言如此，對(duì)一般軟件也如此。好極了，還有什么問題嗎？問題很顯然：重構(gòu)具有風(fēng)險(xiǎn)。它必須修改運(yùn)作中的程序，這可能引入一些不易察覺的錯(cuò)誤。如果重構(gòu)方式不恰當(dāng)，可能毀掉你數(shù)天甚至數(shù)星期的成果。如果重構(gòu)時(shí)不做好準(zhǔn)備，不遵守規(guī)則，風(fēng)險(xiǎn)就更大。你挖掘自己的代碼，很快發(fā)現(xiàn)了一些值得修改的地方，于是你挖得更深。挖得愈深，找到的重構(gòu)機(jī)會(huì)就越多，于是你的修改也愈多……最后你給自己挖了個(gè)大坑，卻爬不出去了。為了避免自掘墳?zāi)?，重?gòu)必須系統(tǒng)化進(jìn)行。我在《設(shè)計(jì)模式》書中和另外三位作者曾經(jīng)提過：設(shè)計(jì)模式為重構(gòu)提供了目標(biāo)。然而"確定目標(biāo)"只是問題的一部分而已，改造程序以達(dá)到目標(biāo)，是另一個(gè)難題。

內(nèi)容概要

　　《重構(gòu)：改善既有代碼的設(shè)計(jì)（英文版）》清晰揭示了重構(gòu)的過程，解釋了重構(gòu)的原理和最佳實(shí)踐方式，并給出了何時(shí)以及何地應(yīng)該開始挖掘代碼以求改善。書中給出了70多個(gè)可行的重構(gòu)，每個(gè)重構(gòu)都介紹了一種經(jīng)過驗(yàn)證的代碼變換手法的動(dòng)機(jī)和技術(shù)?！吨貥?gòu)：改善既有代碼的設(shè)計(jì)（英文版）》提出的重構(gòu)準(zhǔn)則將幫助你一次一小步地修改你的代碼，從而減少了開發(fā)過程中的風(fēng)險(xiǎn)。

作者簡(jiǎn)介

作者：（美國(guó)）福勒（Martin Fowler）Martin Fowler世界軟件開發(fā)大師，在面向?qū)ο蠓治鲈O(shè)計(jì)、UML、模式、xP和重構(gòu)等領(lǐng)域都有卓越貢獻(xiàn)?，F(xiàn)為著名軟件開發(fā)咨詢公司Thoughtworks的首席科學(xué)家。他的多部著作《分析模式》、《UML精粹》和《企業(yè)應(yīng)用架構(gòu)模式》等都已經(jīng)成為膾炙人口的經(jīng)典。其他參編者Kent Beck軟件開發(fā)方法學(xué)的泰斗，極限編程的創(chuàng)始人。他是Three Rivers lnslitule公司總裁，也是Agitar S0ftware的成員。John Brant和Don Roberts The Refactory公司的創(chuàng)始人。Refactory Browser的開發(fā)者。多年來一直從事研究重構(gòu)的實(shí)踐與理論。William Opdyke  目前在朗訊貝爾實(shí)驗(yàn)室工作，他寫的關(guān)于面向?qū)ο罂蚣艿牟┦空撐氖侵貥?gòu)方面的第一篇著名文章。

書籍目錄

Chapter 1: Refactoring, a First Example  1The Starting Point　1The First Step in Refactoring　7Decomposing and Redistributing the Statement Method　8Replacing the Conditional Logic on Price Code with Polymorphism　34Final Thoughts　52Chapter 2: Principles in Refactoring　53Defining Refactoring　53Why Should You Refactor　55When Should You Refactor　57What Do I Tell My Manager　60Problems with Refactoring　62Refactoring and Design　66Refactoring and Performance　69Where Did Refactoring Come From　71Chapter 3: Bad Smells in Code (by Kent Beck and Martin Fowler)　75Duplicated Code　76Long Method　76Large Class　78Long Parameter List　78Divergent Change　79Shotgun Surgery　80Feature Envy　80Data Clumps　81Primitive Obsession　81Switch Statements　82Parallel Inheritance Hierarchies　83Lazy Class　83Speculative Generality　83Temporary Field　84Message Chains　84Middle Man　85Inappropriate Intimacy　85Alternative Classes with Different Interfaces　85Incomplete Library Class　86Data Class　86Refused Bequest　87Comments　87Chapter 4: Building Tests　89The Value of Self-testing Code　89The JUnit Testing Framework　91Adding More Tests　97Chapter 5: Toward a Catalog of Refactorings　103Format of the Refactorings　103Finding References　105How Mature Are These Refactorings　106Chapter 6: Composing Methods　109Extract Method　110Inline Method　117Inline Temp　119Replace Temp with Query　120Introduce Explaining Variable　124Split Temporary Variable　128Remove Assignments to Parameters　131Replace Method with Method Object　135Substitute Algorithm　139Chapter 7: Moving Features Between Objects　141Move Method　142Move Field　146Extract Class　149Inline Class　154Hide Delegate　157Remove Middle Man　160Introduce Foreign Method　162Introduce Local Extension　164Chapter 8: Organizing Data　169Self Encapsulate Field　171Replace Data Value with Object　175Change Value to Reference　179Change Reference to Value　183Replace Array with Object　186Duplicate Observed Data　189Change Unidirectional Association to Bidirectional　197Change Bidirectional Association to Unidirectional　200Replace Magic Number with Symbolic Constant　204Encapsulate Field　206Encapsulate Collection　208Replace Record with Data Class　217Replace Type Code with Class　218Replace Type Code with Subclasses　223Replace Type Code with State/Strategy　227Replace Subclass with Fields　232Chapter 9: Simplifying Conditional Expressions　237Decompose Conditional　238Consolidate Conditional Expression　240Consolidate Duplicate Conditional Fragments　243Remove Control Flag　245Replace Nested Conditional with Guard Clauses　250Replace Conditional with Polymorphism　255Introduce Null Object　260Introduce Assertion　267Chapter 10: Making Method Calls Simpler　271Rename Method　273Add Parameter　275Remove Parameter　277Separate Query from Modifier　279Parameterize Method　283Replace Parameter with Explicit Methods　285Preserve Whole Object　288Replace Parameter with Method　292Introduce Parameter Object　295Remove Setting Method　300Hide Method　303Replace Constructor with Factory Method　304Encapsulate Downcast　308Replace Error Code with Exception　310Replace Exception with Test　315Chapter 11: Dealing with Generalization　319Pull Up Field　320Pull Up Method　322Pull Up Constructor Body　325Push Down Method　328Push Down Field　329Extract Subclass　330Extract Superclass　336Extract Interface　341Collapse Hierarchy　344Form Template Method　345Replace Inheritance with Delegation　352Replace Delegation with Inheritance　355Chapter 12: Big Refactorings (by Kent Beck and Martin Fowler)　359Tease Apart Inheritance　362Convert Procedural Design to Objects　368Separate Domain from Presentation　370Extract Hierarchy　375Chapter 13: Refactoring, Reuse, and Reality (by William Opdyke)　379A Reality Check　380Why Are Developers Reluctant to Refactor Their Programs　381A Reality Check (Revisited)　394Resources and References for Refactoring　394Implications Regarding Software Reuse and Technology Transfer　395A Final Note　397References　397Chapter 14: Refactoring Tools (by Don Roberts and John Brant)　401Refactoring with a Tool　401Technical Criteria for a Refactoring Tool　403Practical Criteria for a Refactoring Tool　405Wrap Up　407Chapter 15: Putting It All Together (by Kent Beck)　409References　413List of Soundbites　417Index　419

章節(jié)摘錄

插圖：Any technical author has the problem of deciding when to publish. The earlieryou publish, the quicker people can take advantage of the ideas. However, people are always learning. If you publish half-baked ideas too early, the ideas canbe incomplete and even lead to problems for those who try to use them.   The basic technique of refactoring, taking small steps and testing often, hasbeen well tested over many years, especially in the Smalltalk community. So I'mconfident that the basic idea of refactoring is very stable.   The refactorings in this book are my notes about the refactorings I use. Ihave used them all. However, there is a difference between using a refactoringand boiling it down into the mechanical steps I give herein. In particular, youoccasionally see problems that crop up only in very specific circumstances. Icannot say that I have had a lot of people work from these steps to spot many of these kinds of problems. As you use the refactorings, be aware of what youare doing. Remember that like working with a recipe, you have to adapt the refactorings to your circumstances. If you run into an interesting problem, dropme an e-mail, and I'll try to pass on these circumstances for others.

編輯推薦

《重構(gòu):改善既有代碼的設(shè)計(jì)(英文版)》：軟件開發(fā)的不朽經(jīng)典、生動(dòng)闡述重構(gòu)原理和具體做法、普通程序員進(jìn)階到編程高手必須修煉的秘笈。

圖書封面

圖書標(biāo)簽Tags

無

評(píng)論、評(píng)分、閱讀與下載

---

    重構(gòu) PDF格式下載

---