**摘要：**由于最近在做重構的項目，所以對重構又重新進行了一遍學習和整理，對31天重構最早接觸是在2009年10月份，由于當時沒有訂閱[Sean Chambers](http://www.lostechies.com/blogs/sean_chambers/archive/2009/07/31/31-days-of-refactoring.aspx)的blog，所以是在國外的社區上閑逛的時候鏈接過去的。記得當時一口氣看完了整個系列并沒有多少感覺，因為這些基本上項目都在使用，只是我們沒有專門把它標示和整理出來，所以也沒有引起多大的重視。現在突然接手這個重構項目，由于團隊成員技術和經驗參差不齊，所以有必要專門整理一個重構的綱要，當然這個系列也非常適合做新系統的代碼規范參考，只要有代碼的地方，這個重構規范就很有價值。周末也不想出去閑逛，因為在剛到這個美麗的城市，沒有親戚或者朋友，所以才能靜下心來兩天時間寫完這個重構參考規范。同時也感受了Windows Live writer寫文章的快感。當然重構的整體架構得另當別論（整體架構在我的這篇文章有專門的講解（[http://www.cnblogs.com/zenghongliang/archive/2010/06/23/1763438.html](http://www.cnblogs.com/zenghongliang/archive/2010/06/archive/2010/06/23/1763438.html)）。大的架構設計好了以后，這些重構細節點就成了東風之后的大火，對整個項目也是至關重要。31天重構這個系列和《代碼大全》、《重構：改善既有代碼的設計》比較起來最大的特點就是比較簡單、淺顯易懂。那么我這些文章也都是學習Sean Chambers的31天重構的筆記整理，所以如果大家對這個筆記有任何異議也可以指出。 具體也可以通過[http://www.lostechies.com/blogs/sean_chambers/archive/2009/07/31/31-days-of-refactoring.aspx](http://www.lostechies.com/blogs/sean_chambers/archive/2009/07/31/31-days-of-refactoring.aspx)查看原文。 **概念：**本文中的“使用策略類” 是指用設計模式中的策略模式來替換原來的switch case和if else語句，這樣可以解開耦合，同時也使維護性和系統的可擴展性大大增強。 **正文：**如下面代碼所示，ClientCode 類會更加枚舉State的值來調用ShippingInfo 的不同方法，但是這樣就會產生很多的判斷語句，如果代碼量加大，類變得很大了的話，維護中改動也會變得很大，每次改動一個地方，都要對整個結構進行編譯（假如是多個工程），所以我們想到了對它進行重構，剝開耦合。 ~~~ namespace LosTechies.DaysOfRefactoring.SwitchToStrategy.Before { public class ClientCode { public decimal CalculateShipping() { ShippingInfo shippingInfo = new ShippingInfo(); return shippingInfo.CalculateShippingAmount(State.Alaska); } } public enum State { Alaska, NewYork, Florida } public class ShippingInfo { public decimal CalculateShippingAmount(State shipToState) { switch (shipToState) { case State.Alaska: return GetAlaskaShippingAmount(); case State.NewYork: return GetNewYorkShippingAmount(); case State.Florida: return GetFloridaShippingAmount(); default: return 0m; } } private decimal GetAlaskaShippingAmount() { return 15m; } private decimal GetNewYorkShippingAmount() { return 10m; } private decimal GetFloridaShippingAmount() { return 3m; } } } ~~~ 重構后的代碼如下所示，抽象出一個IShippingCalculation 接口，然后把ShippingInfo 類里面的GetAlaskaShippingAmount、GetNewYorkShippingAmount、GetFloridaShippingAmount三個方法分別提煉成三個類，然后繼承自IShippingCalculation 接口，這樣在調用的時候就可以通過IEnumerable<IShippingCalculation> 來解除之前的switch case語句，這和IOC的做法頗為相似。 ~~~ using System; using System.Collections.Generic; using System.Linq; namespace LosTechies.DaysOfRefactoring.SwitchToStrategy.After_WithIoC { public interface IShippingInfo { decimal CalculateShippingAmount(State state); } public class ClientCode { [Inject] public IShippingInfo ShippingInfo { get; set; } public decimal CalculateShipping() { return ShippingInfo.CalculateShippingAmount(State.Alaska); } } public enum State { Alaska, NewYork, Florida } public class ShippingInfo : IShippingInfo { private IDictionary<State, IShippingCalculation> ShippingCalculations { get; set; } public ShippingInfo(IEnumerable<IShippingCalculation> shippingCalculations) { ShippingCalculations = shippingCalculations.ToDictionary(calc => calc.State); } public decimal CalculateShippingAmount(State shipToState) { return ShippingCalculations[shipToState].Calculate(); } } public interface IShippingCalculation { State State { get; } decimal Calculate(); } public class AlaskShippingCalculation : IShippingCalculation { public State State { get { return State.Alaska; } } public decimal Calculate() { return 15m; } } public class NewYorkShippingCalculation : IShippingCalculation { public State State { get { return State.NewYork; } } public decimal Calculate() { return 10m; } } public class FloridaShippingCalculation : IShippingCalculation { public State State { get { return State.Florida; } } public decimal Calculate() { return 3m; } } } ~~~ **總結：**這種重構在設計模式當中把它單獨取了一個名字——策略模式，這樣做的好處就是可以隔開耦合，以注入的形式實現功能，這使增加功能變得更加容易和簡便，同樣也增強了整個系統的穩定性和健壯性。