【JAVA】代碼重構技巧

時間  2019-12-06
標籤 JAVA 代碼 技巧 欄目 Java 简体版
原文   原文鏈接

簡介

重構是持續改進代碼的基礎。抵制重構將帶來技術麻煩：忘記代碼片斷的功能、建立沒法測試的代碼等等。算法

而有了重構，使用單元測試、共享代碼以及更可靠的無bug 的代碼這些最佳實踐就顯得簡單多了。編程

鑑於重構的重要性，我決定在整個8 月份天天介紹一個重構。在開始以前，請容許我事先聲明，儘管我試着對每一個重構進行額外的描述和討論，但我並非在聲明它們的全部權。網絡

我介紹的大多數重構均可以在Refactoring.com 中找到，有一些來自《代碼大全（第2 版）》，剩下的則是我本身常用或從其餘網站找到的。我以爲註明每一個重構的出處並非重要的，由於你能夠在網上不一樣的帖子或文章中找到名稱相似的重構。框架

本着這一精神，我將在明天發佈第一篇帖子並開始長達31天的重構馬拉松之旅。但願大家可以享受重構並從中獲益。ide

 

代碼重構第1天：封裝集合

在某些場景中，向類的使用者隱藏類中的完整集合是一個很好的作法，好比對集合的add/remove操做中包含其餘的相關邏輯時。所以，以可迭代但不直接在集合上進行操做的方式來暴露集合，是個不錯的主意。咱們來看代碼：函數

 
 
 
 
 
    
  
  
  
  
  
  1. public class Order
    2. 
  
  
  
  
  
  2. {
    3. 
  
  
  
  
  
  3.  private int _orderTotal;
    4. 
  
  
  
  
  
  4.  private List<OrderLine> _orderLines;
    5. 
  
  
  
  
  
  5.  
    6. 
  
  
  
  
  
  6.  public IEnumerable<OrderLine> OrderLines
    7. 
  
  
  
  
  
  7.  {
    8. 
  
  
  
  
  
  8.  get { return _orderLines; }
    9. 
  
  
  
  
  
  9.  }
    10. 
  
  
  
  
  
  10.  
    11. 
  
  
  
  
  
  11.  public void AddOrderLine(OrderLine orderLine)
    12. 
  
  
  
  
  
  12.  {
    13. 
  
  
  
  
  
  13.  _orderTotal += orderLine.Total;
    14. 
  
  
  
  
  
  14.  _orderLines.Add(orderLine);
    15. 
  
  
  
  
  
  15.  }
    16. 
  
  
  
  
  
  16.  
    17. 
  
  
  
  
  
  17.  public void RemoveOrderLine(OrderLine orderLine)
    18. 
  
  
  
  
  
  18.  {
    19. 
  
  
  
  
  
  19.  orderLine = _orderLines.Find(o => o == orderLine);
    20. 
  
  
  
  
  
  20.  if (orderLine == null) return;
    21. 
  
  
  
  
  
  21.  _orderTotal -= orderLine.Total;
    22. 
  
  
  
  
  
  22.  _orderLines.Remove(orderLine);
    23. 
  
  
  
  
  
  23.  }
    24. 
  
  
  
  
  
  24. }
    25.

如你所見，咱們對集合進行了封裝，沒有將Add/Remove 方法暴露給類的使用者。在.NET Framework中，有些類如ReadOnlyCollection，會因爲封裝集合而產生不一樣的行爲，但它們各自都有防止誤解的說明。這是一個很是簡單但卻極具價值的重構，能夠確保用戶不會誤用你暴露的集合，避免代碼中的一些bug。工具

 

代碼重構第2天：移動方法

今天的重構一樣很是簡單，以致於人們並不認爲這是一個有價值的重構。遷移方法（Move Method），顧名思義就是將方法遷移到合適的位置。在開始重構前，咱們先看看一下代碼：post

 
 
 
 
 
    
  
  
  
  
  
  1. public class BankAccount
    2. 
  
  
  
  
  
  2. {
    3. 
  
  
  
  
  
  3.  public BankAccount(int accountAge, int creditScore, AccountInterest accountInterest)
    4. 
  
  
  
  
  
  4.  {
    5. 
  
  
  
  
  
  5.  AccountAge = accountAge;
    6. 
  
  
  
  
  
  6.  CreditScore = creditScore;
    7. 
  
  
  
  
  
  7.  AccountInterest = accountInterest;
    8. 
  
  
  
  
  
  8.  }
    9. 
  
  
  
  
  
  9.  
    10. 
  
  
  
  
  
  10.  public int AccountAge { get; private set; }
    11. 
  
  
  
  
  
  11.  public int CreditScore { get; private set; }
    12. 
  
  
  
  
  
  12.  public AccountInterest AccountInterest { get; private set; }
    13. 
  
  
  
  
  
  13.  
    14. 
  
  
  
  
  
  14.  public double CalculateInterestRate()
    15. 
  
  
  
  
  
  15.  {
    16. 
  
  
  
  
  
  16.  if (CreditScore > 800)
    17. 
  
  
  
  
  
  17.  return 0.02;
    18. 
  
  
  
  
  
  18.  
    19. 
  
  
  
  
  
  19.  if (AccountAge > 10)
    20. 
  
  
  
  
  
  20.  return 0.03;
    21. 
  
  
  
  
  
  21.  
    22. 
  
  
  
  
  
  22.  return 0.05;
    23. 
  
  
  
  
  
  23.  }
    24. 
  
  
  
  
  
  24. }
    25. 
 
 
 
 
 
 
 
 
 
 
    
  
  
  
  
  
  1. public class AccountInterest
    2. 
  
  
  
  
  
  2. {
    3. 
  
  
  
  
  
  3.  public BankAccount Account { get; private set; }
    4. 
  
  
  
  
  
  4.  
    5. 
  
  
  
  
  
  5.  public AccountInterest(BankAccount account)
    6. 
  
  
  
  
  
  6.  {
    7. 
  
  
  
  
  
  7.  Account = account;
    8. 
  
  
  
  
  
  8.  }
    9. 
  
  
  
  
  
  9.  
    10. 
  
  
  
  
  
  10.  public double InterestRate
    11. 
  
  
  
  
  
  11.  {
    12. 
  
  
  
  
  
  12.  get { return Account.CalculateInterestRate(); }
    13. 
  
  
  
  
  
  13.  }
    14. 
  
  
  
  
  
  14.  
    15. 
  
  
  
  
  
  15.  public bool IntroductoryRate
    16. 
  
  
  
  
  
  16.  {
    17. 
  
  
  
  
  
  17.  get { return Account.CalculateInterestRate() < 0.05; }
    18. 
  
  
  
  
  
  18.  }
    19. 
  
  
  
  
  
  19. }
    20.

這裏值得注意的是BankAccount.CalculateInterest 方法。當一個方法被其餘類使用比在它所在類中的使用還要頻繁時，咱們就須要使用遷移方法重構了——將方法遷移到更頻繁地使用它的類中。因爲依賴關係，該重構並不能應用於全部實例，但人們仍是常常低估它的價值。單元測試

最終的代碼應該是這樣的：學習

 
 
 
 
 
    
  
  
  
  
  
  1. public class BankAccount
    2. 
  
  
  
  
  
  2. {
    3. 
  
  
  
  
  
  3.  public BankAccount(int accountAge, int creditScore, AccountInterest accountInterest)
    4. 
  
  
  
  
  
  4.  {
    5. 
  
  
  
  
  
  5.  AccountAge = accountAge;
    6. 
  
  
  
  
  
  6.  CreditScore = creditScore;
    7. 
  
  
  
  
  
  7.  AccountInterest = accountInterest;
    8. 
  
  
  
  
  
  8.  }
    9. 
  
  
  
  
  
  9.  
    10. 
  
  
  
  
  
  10.  public int AccountAge { get; private set; }
    11. 
  
  
  
  
  
  11.  public int CreditScore { get; private set; }
    12. 
  
  
  
  
  
  12.  public AccountInterest AccountInterest { get; private set; }
    13. 
  
  
  
  
  
  13. }
    14. 
 
 
 
 
 
 
 
 
 
 
    
  
  
  
  
  
  1. public class AccountInterest
    2. 
  
  
  
  
  
  2. {
    3. 
  
  
  
  
  
  3.  public BankAccount Account { get; private set; }
    4. 
  
  
  
  
  
  4.  public AccountInterest(BankAccount account)
    5. 
  
  
  
  
  
  5.  {
    6. 
  
  
  
  
  
  6.  Account = account;
    7. 
  
  
  
  
  
  7.  }
    8. 
  
  
  
  
  
  8.  
    9. 
  
  
  
  
  
  9.  public double InterestRate
    10. 
  
  
  
  
  
  10.  {
    11. 
  
  
  
  
  
  11.  get { return CalculateInterestRate(); }
    12. 
  
  
  
  
  
  12.  }
    13. 
  
  
  
  
  
  13.  
    14. 
  
  
  
  
  
  14.  public bool IntroductoryRate
    15. 
  
  
  
  
  
  15.  {
    16. 
  
  
  
  
  
  16.  get { return CalculateInterestRate() < 0.05; }
    17. 
  
  
  
  
  
  17.  }
    18. 
  
  
  
  
  
  18.  
    19. 
  
  
  
  
  
  19.  public double CalculateInterestRate()
    20. 
  
  
  
  
  
  20.  {
    21. 
  
  
  
  
  
  21.  if (Account.CreditScore > 800)
    22. 
  
  
  
  
  
  22.  return 0.02;
    23. 
  
  
  
  
  
  23.  
    24. 
  
  
  
  
  
  24.  if (Account.AccountAge > 10)
    25. 
  
  
  
  
  
  25.  return 0.03;
    26. 
  
  
  
  
  
  26.  
    27. 
  
  
  
  
  
  27.  return 0.05;
    28. 
  
  
  
  
  
  28.  }
    29. 
  
  
  
  
  
  29. }
    30.

夠簡單吧？

 

代碼重構第3天：提高方法

提高方法（Pull Up Method）重構是將方法向繼承鏈上層遷移的過程。用於一個方法被多個實現者使用時。

 
 
 
 
 
    
  
  
  
  
  
  1. public abstract class Vehicle
    2. 
  
  
  
  
  
  2. {
    3. 
  
  
  
  
  
  3.  // other methods
    4. 
  
  
  
  
  
  4. }
    5. 
  
  
  
  
  
  5.  
    6. 
  
  
  
  
  
  6. public class Car : Vehicle
    7. 
  
  
  
  
  
  7. {
    8. 
  
  
  
  
  
  8.  public void Turn(Direction direction)
    9. 
  
  
  
  
  
  9.  {
    10. 
  
  
  
  
  
  10.  // code here
    11. 
  
  
  
  
  
  11.  }
    12. 
  
  
  
  
  
  12. }
    13. 
  
  
  
  
  
  13.  
    14. 
  
  
  
  
  
  14. public class Motorcycle : Vehicle
    15. 
  
  
  
  
  
  15. {
    16. 
  
  
  
  
  
  16. }
    17. 
  
  
  
  
  
  17.  
    18. 
  
  
  
  
  
  18. public enum Direction
    19. 
  
  
  
  
  
  19. {
    20. 
  
  
  
  
  
  20.  Left,
    21. 
  
  
  
  
  
  21.  Right
    22. 
  
  
  
  
  
  22. }
    23.

如你所見，目前只有Car類中包含Turn方法，但咱們也但願在Motorcycle 類中使用。所以，若是沒有基類，咱們就建立一個基類並將該方法「上移」到基類中，這樣兩個類就均可以使用Turn 方法了。這樣作惟一的缺點是擴充了基類的接口、增長了其複雜性，所以需謹慎使用。只有當一個以上的子類須要使用該方法時才須要進行遷移。若是濫用繼承，系統將會很快崩潰。這時你應該使用組合代替繼承。重構以後的代碼以下：

 
 
 
 
 
    
  
  
  
  
  
  1. public abstract class Vehicle
    2. 
  
  
  
  
  
  2. {
    3. 
  
  
  
  
  
  3.  public void Turn(Direction direction)
    4. 
  
  
  
  
  
  4.  {
    5. 
  
  
  
  
  
  5.  // code here
    6. 
  
  
  
  
  
  6.  }
    7. 
  
  
  
  
  
  7. }
    8. 
  
  
  
  
  
  8.  
    9. 
  
  
  
  
  
  9. public class Car : Vehicle
    10. 
  
  
  
  
  
  10. {
    11. 
  
  
  
  
  
  11. }
    12. 
  
  
  
  
  
  12.  
    13. 
  
  
  
  
  
  13. public class Motorcycle : Vehicle
    14. 
  
  
  
  
  
  14. {
    15. 
  
  
  
  
  
  15. }
    16. 
  
  
  
  
  
  16.  
    17. 
  
  
  
  
  
  17. public enum Direction
    18. 
  
  
  
  
  
  18. {
    19. 
  
  
  
  
  
  19.  Left,
    20. 
  
  
  
  
  
  20.  Right
    21. 
  
  
  
  
  
  21. }
    22.

 

代碼重構第4天：下降方法

昨天咱們介紹了將方法遷移到基類以供多個子類使用的上移方法重構，今天咱們來看看相反的操做。重構前的代碼以下：

 
 
 
 
 
    
  
  
  
  
  
  1. public abstract class Animal
    2. 
  
  
  
  
  
  2. {
    3. 
  
  
  
  
  
  3.  public void Bark()
    4. 
  
  
  
  
  
  4.  {
    5. 
  
  
  
  
  
  5.  // code to bark
    6. 
  
  
  
  
  
  6.  }
    7. 
  
  
  
  
  
  7. }
    8. 
  
  
  
  
  
  8.  
    9. 
  
  
  
  
  
  9. public class Dog : Animal
    10. 
  
  
  
  
  
  10. {
    11. 
  
  
  
  
  
  11. }
    12. 
  
  
  
  
  
  12.  
    13. 
  
  
  
  
  
  13. public class Cat : Animal
    14. 
  
  
  
  
  
  14. {
    15. 
  
  
  
  
  
  15. }
    16.

這裏的基類有一個Bark方法。或許咱們的貓咪們一時半會也無法學會汪汪叫（bark），所以Cat 類中再也不須要這個功能了。儘管基類不須要這個方法，但在顯式處理Dog 類時也許還須要，所以咱們將Bark 方法「下降」到Dog 類中。這時，有必要評估Animal基類中是否還有其餘行爲。若是沒有，則是一個將Animal抽象類轉換成接口的好時機。由於契約中不須要任何代碼，能夠認爲是一個標記接口。

 
 
 
 
 
    
  
  
  
  
  
  1. public abstract class Animal
    2. 
  
  
  
  
  
  2. {
    3. 
  
  
  
  
  
  3. }
    4. 
  
  
  
  
  
  4.  
    5. 
  
  
  
  
  
  5. public class Dog : Animal
    6. 
  
  
  
  
  
  6. {
    7. 
  
  
  
  
  
  7.  public void Bark()
    8. 
  
  
  
  
  
  8.  {
    9. 
  
  
  
  
  
  9.  // code to bark
    10. 
  
  
  
  
  
  10.  }
    11. 
  
  
  
  
  
  11. }
    12. 
  
  
  
  
  
  12.  
    13. 
  
  
  
  
  
  13. public class Cat : Animal
    14. 
  
  
  
  
  
  14. {
    15. 
  
  
  
  
  
  15. }
    16.

 

代碼重構第5天：提高字段

今天咱們來看看一個和提高方法十分相似的重構。不過今天咱們處理的不是方法，而是字段。

 
 
 
 
 
    
  
  
  
  
  
  1. public abstract class Account
    2. 
  
  
  
  
  
  2. {
    3. 
  
  
  
  
  
  3. }
    4. 
  
  
  
  
  
  4.  
    5. 
  
  
  
  
  
  5. public class CheckingAccount : Account
    6. 
  
  
  
  
  
  6. {
    7. 
  
  
  
  
  
  7.  private decimal _minimumCheckingBalance = 5m;
    8. 
  
  
  
  
  
  8. }
    9. 
  
  
  
  
  
  9.  
    10. 
  
  
  
  
  
  10. public class SavingsAccount : Account
    11. 
  
  
  
  
  
  11. {
    12. 
  
  
  
  
  
  12.  private decimal _minimumSavingsBalance = 5m;
    13. 
  
  
  
  
  
  13. }
    14.

在這個例子中，兩個子類中包含重複的常量。爲了提升複用性咱們將字段上移到基類中，並簡化其名稱。

 
 
 
 
 
    
  
  
  
  
  
  1. public abstract class Account
    2. 
  
  
  
  
  
  2. {
    3. 
  
  
  
  
  
  3.  protected decimal _minimumBalance = 5m;
    4. 
  
  
  
  
  
  4. }
    5. 
  
  
  
  
  
  5.  
    6. 
  
  
  
  
  
  6. public class CheckingAccount : Account
    7. 
  
  
  
  
  
  7. {
    8. 
  
  
  
  
  
  8. }
    9. 
  
  
  
  
  
  9.  
    10. 
  
  
  
  
  
  10. public class SavingsAccount : Account
    11. 
  
  
  
  
  
  11. {
    12. 
  
  
  
  
  
  12. }
    13.

 

重構代碼第6天：下降字段

與提高字段相反的重構是下降字段。一樣，這也是一個無需多言的簡單重構。

 
 
 
 
 
    
  
  
  
  
  
  1. public abstract class Task
    2. 
  
  
  
  
  
  2. {
    3. 
  
  
  
  
  
  3.  protected string _resolution;
    4. 
  
  
  
  
  
  4. }
    5. 
  
  
  
  
  
  5.  
    6. 
  
  
  
  
  
  6. public class BugTask : Task
    7. 
  
  
  
  
  
  7. {
    8. 
  
  
  
  
  
  8. }
    9. 
  
  
  
  
  
  9.  
    10. 
  
  
  
  
  
  10. public class FeatureTask : Task
    11. 
  
  
  
  
  
  11. {
    12. 
  
  
  
  
  
  12. }
    13.

在這個例子中，基類中的一個字符串字段只被一個子類使用，所以能夠進行下移。只要沒有其餘子類使用基類的字段時，就應該當即執行該重構。保留的時間越長，就越有可能不去重構而保持原樣。

 
 
 
 
 
    
  
  
  
  
  
  1. public abstract class Task
    2. 
  
  
  
  
  
  2. {
    3. 
  
  
  
  
  
  3. }
    4. 
  
  
  
  
  
  4.  
    5. 
  
  
  
  
  
  5. public class BugTask : Task
    6. 
  
  
  
  
  
  6. {
    7. 
  
  
  
  
  
  7.  private string _resolution;
    8. 
  
  
  
  
  
  8. }
    9. 
  
  
  
  
  
  9.  
    10. 
  
  
  
  
  
  10. public class FeatureTask : Task
    11. 
  
  
  
  
  
  11. {
    12. 
  
  
  
  
  
  12. }
    13.

 

重構代碼第7天：重命名（方法，類，參數）

這是我最經常使用也是最有用的重構之一。咱們對方法/類/參數的命名每每不那麼合適，以致於誤導閱讀者對於方法/類/參數功能的理解。這會形成閱讀者的主觀臆斷，甚至引入bug。這個重構看起來簡單，但卻十分重要。

 
 
 
 
 
    
  
  
  
  
  
  1. public class Person
    2. 
  
  
  
  
  
  2. {
    3. 
  
  
  
  
  
  3.  public string FN { get; set; }
    4. 
  
  
  
  
  
  4.  public decimal ClcHrlyPR()
    5. 
  
  
  
  
  
  5.  {
    6. 
  
  
  
  
  
  6.  // code to calculate hourly payrate
    7. 
  
  
  
  
  
  7.  return 0m;
    8. 
  
  
  
  
  
  8.  }
    9. 
  
  
  
  
  
  9. }
    10.

如你所見，咱們的類/方法/參數的名稱十分晦澀難懂，能夠理解爲不一樣的含義。應用這個重構你只需隨手將
名稱修改得更具描述性、更容易傳達其含義便可。簡單吧。

 
 
 
 
 
    
  
  
  
  
  
  1. // Changed the class name to Employee
    2. 
  
  
  
  
  
  2. public class Employee
    3. 
  
  
  
  
  
  3. {
    4. 
  
  
  
  
  
  4.  public string FirstName { get; set; }
    5. 
  
  
  
  
  
  5.  
    6. 
  
  
  
  
  
  6.  public decimal CalculateHourlyPay()
    7. 
  
  
  
  
  
  7.  {
    8. 
  
  
  
  
  
  8.  // code to calculate hourly payrate
    9. 
  
  
  
  
  
  9.  return 0m;
    10. 
  
  
  
  
  
  10.  }
    11. 
  
  
  
  
  
  11. }
    12.

 

重構代碼第8天：使用委派代替繼承

繼承的誤用十分廣泛。它只能用於邏輯環境，但卻常常用於簡化，這致使複雜的沒有意義的繼承層次。看下面的代碼：

 
 
 
 
 
    
  
  
  
  
  
  1. public class Sanitation
    2. 
  
  
  
  
  
  2. {
    3. 
  
  
  
  
  
  3.  public string WashHands()
    4. 
  
  
  
  
  
  4.  {
    5. 
  
  
  
  
  
  5.  return "Cleaned!";
    6. 
  
  
  
  
  
  6.  }
    7. 
  
  
  
  
  
  7. }
    8. 
  
  
  
  
  
  8.  
    9. 
  
  
  
  
  
  9. public class Child : Sanitation
    10. 
  
  
  
  
  
  10. {
    11. 
  
  
  
  
  
  11. }
    12.

在該例中，Child 並非Sanitation，所以這樣的繼承層次是毫無心義的。咱們能夠這樣重構：在Child 的構造函數裏實現一個Sanitation實例，並將方法的調用委託給這個實例。若是你使用依賴注入，能夠經過構造函數傳遞Sanitation實例，儘管在我看來還要向IoC容器註冊模型是一種壞味道，但領會精神就能夠了。繼承只能用於嚴格的繼承場景，並非用來快速編寫代碼的工具。

 
 
 
 
 
    
  
  
  
  
  
  1. public class Sanitation
    2. 
  
  
  
  
  
  2. {
    3. 
  
  
  
  
  
  3.  public string WashHands()
    4. 
  
  
  
  
  
  4.  {
    5. 
  
  
  
  
  
  5.  return "Cleaned!";
    6. 
  
  
  
  
  
  6.  }
    7. 
  
  
  
  
  
  7. }
    8. 
  
  
  
  
  
  8.  
    9. 
  
  
  
  
  
  9. public class Child
    10. 
  
  
  
  
  
  10. {
    11. 
  
  
  
  
  
  11.  private Sanitation Sanitation { get; set; }
    12. 
  
  
  
  
  
  12.  
    13. 
  
  
  
  
  
  13.  public Child()
    14. 
  
  
  
  
  
  14.  {
    15. 
  
  
  
  
  
  15.  Sanitation = new Sanitation();
    16. 
  
  
  
  
  
  16.  }
    17. 
  
  
  
  
  
  17.  
    18. 
  
  
  
  
  
  18.  public string WashHands()
    19. 
  
  
  
  
  
  19.  {
    20. 
  
  
  
  
  
  20.  return Sanitation.WashHands();
    21. 
  
  
  
  
  
  21.  }
    22. 
  
  
  
  
  
  22. }
    23.

 

代碼重構第9天：提取接口

今天咱們來介紹一個經常被忽視的重構：提取接口。若是你發現多於一個類使用另一個類的某些方法，引入接口解除這種依賴每每十分有用。該重構實現起來很是簡單，而且可以享受到鬆耦合帶來的好處。

 
 
 
 
 
    
  
  
  
  
  
  1. public class ClassRegistration
    2. 
  
  
  
  
  
  2. {
    3. 
  
  
  
  
  
  3.  public void Create()
    4. 
  
  
  
  
  
  4.  {
    5. 
  
  
  
  
  
  5.  // create registration code
    6. 
  
  
  
  
  
  6.  }
    7. 
  
  
  
  
  
  7.  
    8. 
  
  
  
  
  
  8.  public void Transfer()
    9. 
  
  
  
  
  
  9.  {
    10. 
  
  
  
  
  
  10.  // class transfer code
    11. 
  
  
  
  
  
  11.  }
    12. 
  
  
  
  
  
  12.  
    13. 
  
  
  
  
  
  13.  public decimal Total { get; private set; }
    14. 
  
  
  
  
  
  14. }
    15. 
  
  
  
  
  
  15.  
    16. 
  
  
  
  
  
  16. public class RegistrationProcessor
    17. 
  
  
  
  
  
  17. {
    18. 
  
  
  
  
  
  18.  public decimal ProcessRegistration(ClassRegistration registration)
    19. 
  
  
  
  
  
  19.  {
    20. 
  
  
  
  
  
  20.  registration.Create();
    21. 
  
  
  
  
  
  21.  return registration.Total;
    22. 
  
  
  
  
  
  22.  }
    23. 
  
  
  
  
  
  23. }
    24.

在下面的代碼中，你能夠看到我提取出了消費者所使用的兩個方法，並將其置於一個接口中。如今消費者沒必要關心和了解實現了這些方法的類。咱們解除了消費者與實際實現之間的耦合，使其只依賴於咱們建立的契約。

 
 
 
 
 
    
  
  
  
  
  
  1. public interface IClassRegistration
    2. 
  
  
  
  
  
  2. {
    3. 
  
  
  
  
  
  3.  void Create();
    4. 
  
  
  
  
  
  4.  decimal Total { get; }
    5. 
  
  
  
  
  
  5. }
    6. 
  
  
  
  
  
  6.  
    7. 
  
  
  
  
  
  7. public class ClassRegistration : IClassRegistration
    8. 
  
  
  
  
  
  8. {
    9. 
  
  
  
  
  
  9.  public void Create()
    10. 
  
  
  
  
  
  10.  {
    11. 
  
  
  
  
  
  11.  // create registration code
    12. 
  
  
  
  
  
  12.  }
    13. 
  
  
  
  
  
  13.  
    14. 
  
  
  
  
  
  14.  public void Transfer()
    15. 
  
  
  
  
  
  15.  {
    16. 
  
  
  
  
  
  16.  // class transfer code
    17. 
  
  
  
  
  
  17.  }
    18. 
  
  
  
  
  
  18.  
    19. 
  
  
  
  
  
  19.  public decimal Total { get; private set; }
    20. 
  
  
  
  
  
  20. }
    21. 
  
  
  
  
  
  21.  
    22. 
  
  
  
  
  
  22. public class RegistrationProcessor
    23. 
  
  
  
  
  
  23. {
    24. 
  
  
  
  
  
  24.  public decimal ProcessRegistration(IClassRegistration registration)
    25. 
  
  
  
  
  
  25.  {
    26. 
  
  
  
  
  
  26.  registration.Create();
    27. 
  
  
  
  
  
  27.  return registration.Total;
    28. 
  
  
  
  
  
  28.  }
    29. 
  
  
  
  
  
  29. }
    30.

 

代碼重構第10天：提取方法

今天咱們要介紹的重構是提取方法。這個重構極其簡單但卻大有裨益。首先，將邏輯置於命名良好的方法內有助於提升代碼的可讀性。當方法的名稱能夠很好地描述這部分代碼的功能時，能夠有效地減小其餘開發者的研究時間。假設越少，代碼中的bug 也就越少。重構以前的代碼以下：

 
 
 
 
 
    
  
  
  
  
  
  1. public class Receipt
    2. 
  
  
  
  
  
  2. {
    3. 
  
  
  
  
  
  3.  private IList<decimal> Discounts { get; set; }
    4. 
  
  
  
  
  
  4.  private IList<decimal> ItemTotals { get; set; }
    5. 
  
  
  
  
  
  5.  
    6. 
  
  
  
  
  
  6.  public decimal CalculateGrandTotal()
    7. 
  
  
  
  
  
  7.  {
    8. 
  
  
  
  
  
  8.  decimal subTotal = 0m;
    9. 
  
  
  
  
  
  9.  foreach (decimal itemTotal in ItemTotals)
    10. 
  
  
  
  
  
  10.  subTotal += itemTotal;
    11. 
  
  
  
  
  
  11.  if (Discounts.Count > 0)
    12. 
  
  
  
  
  
  12.  {
    13. 
  
  
  
  
  
  13.  foreach (decimal discount in Discounts)
    14. 
  
  
  
  
  
  14.  subTotal -= discount;
    15. 
  
  
  
  
  
  15.  }
    16. 
  
  
  
  
  
  16.  
    17. 
  
  
  
  
  
  17.  decimal tax = subTotal * 0.065m;
    18. 
  
  
  
  
  
  18.  subTotal += tax;
    19. 
  
  
  
  
  
  19.  return subTotal;
    20. 
  
  
  
  
  
  20.  }
    21. 
  
  
  
  
  
  21. }
    22.

你會發現CalculateGrandTotal方法一共作了3件不一樣的事情：計算總額、折扣和發票稅額。開發者爲了搞清楚每一個功能如何處理而不得不將代碼從頭看到尾。相比於此，向下面的代碼那樣將每一個任務分解成單獨的方法則要節省更多時間，也更具可讀性：

 
 
 
 
 
    
  
  
  
  
  
  1. public class Receipt
    2. 
  
  
  
  
  
  2. {
    3. 
  
  
  
  
  
  3.  private IList<decimal> Discounts { get; set; }
    4. 
  
  
  
  
  
  4.  private IList<decimal> ItemTotals { get; set; }
    5. 
  
  
  
  
  
  5.  public decimal CalculateGrandTotal()
    6. 
  
  
  
  
  
  6.  {
    7. 
  
  
  
  
  
  7.  decimal subTotal = CalculateSubTotal();
    8. 
  
  
  
  
  
  8.  subTotal = CalculateDiscounts(subTotal);
    9. 
  
  
  
  
  
  9.  subTotal = CalculateTax(subTotal);
    10. 
  
  
  
  
  
  10.  return subTotal;
    11. 
  
  
  
  
  
  11.  }
    12. 
  
  
  
  
  
  12.  
    13. 
  
  
  
  
  
  13.  private decimal CalculateTax(decimal subTotal)
    14. 
  
  
  
  
  
  14.  {
    15. 
  
  
  
  
  
  15.  decimal tax = subTotal * 0.065m;
    16. 
  
  
  
  
  
  16.  subTotal += tax;
    17. 
  
  
  
  
  
  17.  return subTotal;
    18. 
  
  
  
  
  
  18.  }
    19. 
  
  
  
  
  
  19.  
    20. 
  
  
  
  
  
  20.  private decimal CalculateDiscounts(decimal subTotal)
    21. 
  
  
  
  
  
  21.  {
    22. 
  
  
  
  
  
  22.  if (Discounts.Count > 0)
    23. 
  
  
  
  
  
  23.  {
    24. 
  
  
  
  
  
  24.  foreach (decimal discount in Discounts)
    25. 
  
  
  
  
  
  25.  subTotal -= discount;
    26. 
  
  
  
  
  
  26.  }
    27. 
  
  
  
  
  
  27.  return subTotal;
    28. 
  
  
  
  
  
  28.  }
    29. 
  
  
  
  
  
  29.  
    30. 
  
  
  
  
  
  30.  private decimal CalculateSubTotal()
    31. 
  
  
  
  
  
  31.  {
    32. 
  
  
  
  
  
  32.  decimal subTotal = 0m;
    33. 
  
  
  
  
  
  33.  foreach (decimal itemTotal in ItemTotals)
    34. 
  
  
  
  
  
  34.  subTotal += itemTotal;
    35. 
  
  
  
  
  
  35.  return subTotal;
    36. 
  
  
  
  
  
  36.  }
    37. 
  
  
  
  
  
  37. }
    38.

 

代碼重構第11天：使用策略類

今天的重構沒有固定的形式，多年來我使用過不一樣的版本，而且我敢打賭不一樣的人也會有不一樣的版本。該重構適用於這樣的場景：switch 語句塊很大，而且會隨時引入新的判斷條件。這時，最好使用策略模式將每一個條件封裝到單獨的類中。實現策略模式的方式是不少的。我在這裏介紹的策略重構使用的是字典策略，這麼作的好處是調用者沒必要修改原來的代碼。

 
 
 
 
 
    
  
  
  
  
  
  1. namespace LosTechies.DaysOfRefactoring.SwitchToStrategy.Before
    2. 
  
  
  
  
  
  2. {
    3. 
  
  
  
  
  
  3.  public class ClientCode
    4. 
  
  
  
  
  
  4.  {
    5. 
  
  
  
  
  
  5.  public decimal CalculateShipping()
    6. 
  
  
  
  
  
  6.  {
    7. 
  
  
  
  
  
  7.  ShippingInfo shippingInfo = new ShippingInfo();
    8. 
  
  
  
  
  
  8.  return shippingInfo.CalculateShippingAmount(State.Alaska);
    9. 
  
  
  
  
  
  9.  }
    10. 
  
  
  
  
  
  10.  }
    11. 
  
  
  
  
  
  11.  
    12. 
  
  
  
  
  
  12.  public enum State
    13. 
  
  
  
  
  
  13.  {
    14. 
  
  
  
  
  
  14.  Alaska,
    15. 
  
  
  
  
  
  15.  NewYork,
    16. 
  
  
  
  
  
  16.  Florida
    17. 
  
  
  
  
  
  17.  }
    18. 
  
  
  
  
  
  18.  
    19. 
  
  
  
  
  
  19.  public class ShippingInfo
    20. 
  
  
  
  
  
  20.  {
    21. 
  
  
  
  
  
  21.  public decimal CalculateShippingAmount(State shipToState)
    22. 
  
  
  
  
  
  22.  {
    23. 
  
  
  
  
  
  23.  switch (shipToState)
    24. 
  
  
  
  
  
  24.  {
    25. 
  
  
  
  
  
  25.  case State.Alaska:
    26. 
  
  
  
  
  
  26.  return GetAlaskaShippingAmount();
    27. 
  
  
  
  
  
  27.  case State.NewYork:
    28. 
  
  
  
  
  
  28.  return GetNewYorkShippingAmount();
    29. 
  
  
  
  
  
  29.  case State.Florida:
    30. 
  
  
  
  
  
  30.  return GetFloridaShippingAmount();
    31. 
  
  
  
  
  
  31.  default:
    32. 
  
  
  
  
  
  32.  return 0m;
    33. 
  
  
  
  
  
  33.  }
    34. 
  
  
  
  
  
  34.  }
    35. 
  
  
  
  
  
  35.  
    36. 
  
  
  
  
  
  36.  private decimal GetAlaskaShippingAmount()
    37. 
  
  
  
  
  
  37.  {
    38. 
  
  
  
  
  
  38.  return 15m;
    39. 
  
  
  
  
  
  39.  }
    40. 
  
  
  
  
  
  40.  
    41. 
  
  
  
  
  
  41.  private decimal GetNewYorkShippingAmount()
    42. 
  
  
  
  
  
  42.  {
    43. 
  
  
  
  
  
  43.  return 10m;
    44. 
  
  
  
  
  
  44.  }
    45. 
  
  
  
  
  
  45.  
    46. 
  
  
  
  
  
  46.  private decimal GetFloridaShippingAmount()
    47. 
  
  
  
  
  
  47.  {
    48. 
  
  
  
  
  
  48.  return 3m;
    49. 
  
  
  
  
  
  49.  }
    50. 
  
  
  
  
  
  50.  }
    51. 
  
  
  
  
  
  51. }
    52.

要應用該重構，需將每一個測試條件至於單獨的類中，這些類實現了一個共同的接口。而後將枚舉做爲字典的鍵，這樣就能夠獲取正確的實現，並執行其代碼了。之後若是但願添加新的條件，只需添加新的實現類，並將其添加至ShippingCalculations 字典中。正如前面說過的，這不是實現策略模式的惟一方式。我在這裏將字體加粗顯示，是由於確定會有人在評論裏指出這點：）用你以爲好用的方法。我用這種方式實現重構的好處是，不用修改客戶端代碼。全部的修改都在ShippingInfo 類內部。
Jayme Davis指出這種重構因爲仍然須要在構造函數中進行綁定，因此只不過是增長了一些類而已，但若是綁定IShippingCalculation的策略能夠置於IoC中，帶來的好處仍是不少的，它可使你更靈活地捆綁策略。

 
 
 
 
 
    
  
  
  
  
  
  1. namespace LosTechies.DaysOfRefactoring.SwitchToStrategy.After
    2. 
  
  
  
  
  
  2. {
    3. 
  
  
  
  
  
  3.  public class ClientCode
    4. 
  
  
  
  
  
  4.  {
    5. 
  
  
  
  
  
  5.  public decimal CalculateShipping()
    6. 
  
  
  
  
  
  6.  {
    7. 
  
  
  
  
  
  7.  ShippingInfo shippingInfo = new ShippingInfo();
    8. 
  
  
  
  
  
  8.  return shippingInfo.CalculateShippingAmount(State.Alaska);
    9. 
  
  
  
  
  
  9.  }
    10. 
  
  
  
  
  
  10.  }
    11. 
  
  
  
  
  
  11.  
    12. 
  
  
  
  
  
  12.  public enum State
    13. 
  
  
  
  
  
  13.  {
    14. 
  
  
  
  
  
  14.  Alaska,
    15. 
  
  
  
  
  
  15.  NewYork,
    16. 
  
  
  
  
  
  16.  Florida
    17. 
  
  
  
  
  
  17.  }
    18. 
  
  
  
  
  
  18.  
    19. 
  
  
  
  
  
  19.  public class ShippingInfo
    20. 
  
  
  
  
  
  20.  {
    21. 
  
  
  
  
  
  21.  private IDictionary<State, IShippingCalculation> ShippingCalculations
    22. 
  
  
  
  
  
  22.  { get; set; }
    23. 
  
  
  
  
  
  23.  
    24. 
  
  
  
  
  
  24.  public ShippingInfo()
    25. 
  
  
  
  
  
  25.  {
    26. 
  
  
  
  
  
  26.  ShippingCalculations = new Dictionary<State, IShippingCalculation>
    27. 
  
  
  
  
  
  27.  {
    28. 
  
  
  
  
  
  28.  { State.Alaska, new AlaskShippingCalculation() },
    29. 
  
  
  
  
  
  29.  { State.NewYork, new NewYorkShippingCalculation() },
    30. 
  
  
  
  
  
  30.  { State.Florida, new FloridaShippingCalculation() }
    31. 
  
  
  
  
  
  31.  };
    32. 
  
  
  
  
  
  32.  }
    33. 
  
  
  
  
  
  33.  
    34. 
  
  
  
  
  
  34.  public decimal CalculateShippingAmount(State shipToState)
    35. 
  
  
  
  
  
  35.  {
    36. 
  
  
  
  
  
  36.  return ShippingCalculations[shipToState].Calculate();
    37. 
  
  
  
  
  
  37.  }
    38. 
  
  
  
  
  
  38.  }
    39. 
  
  
  
  
  
  39.  
    40. 
  
  
  
  
  
  40.  public interface IShippingCalculation
    41. 
  
  
  
  
  
  41.  {
    42. 
  
  
  
  
  
  42.  decimal Calculate();
    43. 
  
  
  
  
  
  43.  }
    44. 
  
  
  
  
  
  44.  
    45. 
  
  
  
  
  
  45.  public class AlaskShippingCalculation : IShippingCalculation
    46. 
  
  
  
  
  
  46.  {
    47. 
  
  
  
  
  
  47.  public decimal Calculate()
    48. 
  
  
  
  
  
  48.  {
    49. 
  
  
  
  
  
  49.  return 15m;
    50. 
  
  
  
  
  
  50.  }
    51. 
  
  
  
  
  
  51.  }
    52. 
  
  
  
  
  
  52.  
    53. 
  
  
  
  
  
  53.  public class NewYorkShippingCalculation : IShippingCalculation
    54. 
  
  
  
  
  
  54.  {
    55. 
  
  
  
  
  
  55.  public decimal Calculate()
    56. 
  
  
  
  
  
  56.  {
    57. 
  
  
  
  
  
  57.  return 10m;
    58. 
  
  
  
  
  
  58.  }
    59. 
  
  
  
  
  
  59.  }
    60. 
  
  
  
  
  
  60.  
    61. 
  
  
  
  
  
  61.  public class FloridaShippingCalculation : IShippingCalculation
    62. 
  
  
  
  
  
  62.  {
    63. 
  
  
  
  
  
  63.  public decimal Calculate()
    64. 
  
  
  
  
  
  64.  {
    65. 
  
  
  
  
  
  65.  return 3m;
    66. 
  
  
  
  
  
  66.  }
    67. 
  
  
  
  
  
  67.  }
    68. 
  
  
  
  
  
  68. }
    69.

爲了使這個示例圓滿，咱們來看看在ShippingInfo 構造函數中使用Ninject 爲IoC容器時如何進行綁定。須要更改的地方不少，主要是將state 的枚舉放在策略內部，以及Ninject 向構造函數傳遞一個IShippingInfo 的IEnumerable泛型。接下來咱們使用策略類中的state屬性建立字典，其他部分保持不變。（感謝Nate Kohari和Jayme Davis）

 
 
 
 
 
    
  
  
  
  
  
  1. public interface IShippingInfo
    2. 
  
  
  
  
  
  2. {
    3. 
  
  
  
  
  
  3.  decimal CalculateShippingAmount(State state);
    4. 
  
  
  
  
  
  4. }
    5. 
  
  
  
  
  
  5.  
    6. 
  
  
  
  
  
  6. public class ClientCode
    7. 
  
  
  
  
  
  7. {
    8. 
  
  
  
  
  
  8.  [Inject]
    9. 
  
  
  
  
  
  9.  public IShippingInfo ShippingInfo { get; set; }
    10. 
  
  
  
  
  
  10.  
    11. 
  
  
  
  
  
  11.  public decimal CalculateShipping()
    12. 
  
  
  
  
  
  12.  {
    13. 
  
  
  
  
  
  13.  return ShippingInfo.CalculateShippingAmount(State.Alaska);
    14. 
  
  
  
  
  
  14.  }
    15. 
  
  
  
  
  
  15. }
    16. 
  
  
  
  
  
  16.  
    17. 
  
  
  
  
  
  17. public enum State
    18. 
  
  
  
  
  
  18. {
    19. 
  
  
  
  
  
  19.  Alaska,
    20. 
  
  
  
  
  
  20.  NewYork,
    21. 
  
  
  
  
  
  21.  Florida
    22. 
  
  
  
  
  
  22. }
    23. 
  
  
  
  
  
  23.  
    24. 
  
  
  
  
  
  24. public class ShippingInfo : IShippingInfo
    25. 
  
  
  
  
  
  25. {
    26. 
  
  
  
  
  
  26.  private IDictionary<State, IShippingCalculation> ShippingCalculations
    27. 
  
  
  
  
  
  27.  { get; set; }
    28. 
  
  
  
  
  
  28.  public ShippingInfo(IEnumerable<IShippingCalculation> shippingCalculations)
    29. 
  
  
  
  
  
  29.  {
    30. 
  
  
  
  
  
  30.  ShippingCalculations = shippingCalculations.ToDictionary(
    31. 
  
  
  
  
  
  31.  calc => calc.State);
    32. 
  
  
  
  
  
  32.  }
    33. 
  
  
  
  
  
  33.  
    34. 
  
  
  
  
  
  34.  public decimal CalculateShippingAmount(State shipToState)
    35. 
  
  
  
  
  
  35.  {
    36. 
  
  
  
  
  
  36.  return ShippingCalculations[shipToState].Calculate();
    37. 
  
  
  
  
  
  37.  }
    38. 
  
  
  
  
  
  38. }
    39. 
  
  
  
  
  
  39.  
    40. 
  
  
  
  
  
  40. public interface IShippingCalculation
    41. 
  
  
  
  
  
  41. {
    42. 
  
  
  
  
  
  42.  State State { get; }
    43. 
  
  
  
  
  
  43.  decimal Calculate();
    44. 
  
  
  
  
  
  44. }
    45. 
  
  
  
  
  
  45.  
    46. 
  
  
  
  
  
  46. public class AlaskShippingCalculation : IShippingCalculation
    47. 
  
  
  
  
  
  47. {
    48. 
  
  
  
  
  
  48.  public State State { get { return State.Alaska; } }
    49. 
  
  
  
  
  
  49.  public decimal Calculate()
    50. 
  
  
  
  
  
  50.  {
    51. 
  
  
  
  
  
  51.  return 15m;
    52. 
  
  
  
  
  
  52.  }
    53. 
  
  
  
  
  
  53. }
    54. 
  
  
  
  
  
  54.  
    55. 
  
  
  
  
  
  55. public class NewYorkShippingCalculation : IShippingCalculation
    56. 
  
  
  
  
  
  56. {
    57. 
  
  
  
  
  
  57.  public State State { get { return State.NewYork; } }
    58. 
  
  
  
  
  
  58.  public decimal Calculate()
    59. 
  
  
  
  
  
  59.  {
    60. 
  
  
  
  
  
  60.  return 10m;
    61. 
  
  
  
  
  
  61.  }
    62. 
  
  
  
  
  
  62. }
    63. 
  
  
  
  
  
  63.  
    64. 
  
  
  
  
  
  64. public class FloridaShippingCalculation : IShippingCalculation
    65. 
  
  
  
  
  
  65. {
    66. 
  
  
  
  
  
  66.  public State State { get { return State.Florida; } }
    67. 
  
  
  
  
  
  67.  public decimal Calculate()
    68. 
  
  
  
  
  
  68.  {
    69. 
  
  
  
  
  
  69.  return 3m;
    70. 
  
  
  
  
  
  70.  }
    71. 
  
  
  
  
  
  71. }
    72.

 

代碼重構第12天：分解依賴

有些單元測試須要恰當的測試「縫隙」（test seam）來模擬/隔離一些不想被測試的部分。若是你正想在代碼中引入這種單元測試，那麼今天介紹的重構就十分有用。在這個例子中，咱們的客戶端代碼使用一個靜態類來實現功能。但當須要單元測試時，問題就來了。咱們沒法在單元測試中模擬靜態類。解決的方法是使用一個接口將靜態類包裝起來，造成一個縫隙來切斷與靜態類之間的依賴。

 
 
 
 
 
    
  
  
  
  
  
  1. public class AnimalFeedingService
    2. 
  
  
  
  
  
  2. {
    3. 
  
  
  
  
  
  3.  private bool FoodBowlEmpty { get; set; }
    4. 
  
  
  
  
  
  4.  public void Feed()
    5. 
  
  
  
  
  
  5.  {
    6. 
  
  
  
  
  
  6.  if (FoodBowlEmpty)
    7. 
  
  
  
  
  
  7.  Feeder.ReplenishFood();
    8. 
  
  
  
  
  
  8.  // more code to feed the animal
    9. 
  
  
  
  
  
  9.  }
    10. 
  
  
  
  
  
  10. }
    11. 
  
  
  
  
  
  11.  
    12. 
  
  
  
  
  
  12. public static class Feeder
    13. 
  
  
  
  
  
  13. {
    14. 
  
  
  
  
  
  14.  public static void ReplenishFood()
    15. 
  
  
  
  
  
  15.  {
    16. 
  
  
  
  
  
  16.  // fill up bowl
    17. 
  
  
  
  
  
  17.  }
    18. 
  
  
  
  
  
  18. }
    19.

重構時咱們所要作的就是引入一個接口和簡單調用上面那個靜態類的類。所以行爲仍是同樣的，只是調用的方式產生了變化。這是一個不錯的重構起始點，也是向代碼添加單元測試的簡單方式。

 
 
 
 
 
    
  
  
  
  
  
  1. public class AnimalFeedingService
    2. 
  
  
  
  
  
  2. {
    3. 
  
  
  
  
  
  3.  public IFeederService FeederService { get; set; }
    4. 
  
  
  
  
  
  4.  
    5. 
  
  
  
  
  
  5.  public AnimalFeedingService(IFeederService feederService)
    6. 
  
  
  
  
  
  6.  {
    7. 
  
  
  
  
  
  7.  FeederService = feederService;
    8. 
  
  
  
  
  
  8.  }
    9. 
  
  
  
  
  
  9.  
    10. 
  
  
  
  
  
  10.  private bool FoodBowlEmpty { get; set; }
    11. 
  
  
  
  
  
  11.  
    12. 
  
  
  
  
  
  12.  public void Feed()
    13. 
  
  
  
  
  
  13.  {
    14. 
  
  
  
  
  
  14.  if (FoodBowlEmpty)
    15. 
  
  
  
  
  
  15.  FeederService.ReplenishFood();
    16. 
  
  
  
  
  
  16.  // more code to feed the animal
    17. 
  
  
  
  
  
  17.  }
    18. 
  
  
  
  
  
  18. }
    19. 
  
  
  
  
  
  19.  
    20. 
  
  
  
  
  
  20. public interface IFeederService
    21. 
  
  
  
  
  
  21. {
    22. 
  
  
  
  
  
  22.  void ReplenishFood();
    23. 
  
  
  
  
  
  23. }
    24. 
  
  
  
  
  
  24.  
    25. 
  
  
  
  
  
  25. public class FeederService : IFeederService
    26. 
  
  
  
  
  
  26. {
    27. 
  
  
  
  
  
  27.  public void ReplenishFood()
    28. 
  
  
  
  
  
  28.  {
    29. 
  
  
  
  
  
  29.  Feeder.ReplenishFood();
    30. 
  
  
  
  
  
  30.  }
    31. 
  
  
  
  
  
  31. }
    32. 
  
  
  
  
  
  32.  
    33. 
  
  
  
  
  
  33. public static class Feeder
    34. 
  
  
  
  
  
  34. {
    35. 
  
  
  
  
  
  35.  public static void ReplenishFood()
    36. 
  
  
  
  
  
  36.  {
    37. 
  
  
  
  
  
  37.  // fill up bowl
    38. 
  
  
  
  
  
  38.  }
    39. 
  
  
  
  
  
  39. }
    40.

如今，咱們能夠在單元測試中將模擬的IFeederService 傳入AnimalFeedingService 構造函數。測試成功後，咱們能夠將靜態方法中的代碼移植到FeederService 類中，並刪除靜態類。

 

代碼重構第13天：提取方法對象

今天的重構來自於Martin Fowler的重構目錄。在我看來，這是一個比較罕見的重構，但有時卻終能派上用場。當你嘗試進行提取方法的重構時，須要引入大量的方法。在一個方法中使用衆多的本地變量有時會使代碼變得醜陋。所以最好使用提取方法對象這個重構，將執行任務的邏輯分開。

 
 
 
 
 
    
  
  
  
  
  
  1. public class OrderLineItem
    2. 
  
  
  
  
  
  2. {
    3. 
  
  
  
  
  
  3.  public decimal Price { get; private set; }
    4. 
  
  
  
  
  
  4. }
    5. 
  
  
  
  
  
  5.  
    6. 
  
  
  
  
  
  6. public class Order
    7. 
  
  
  
  
  
  7. {
    8. 
  
  
  
  
  
  8.  private IList<OrderLineItem> OrderLineItems { get; set; }
    9. 
  
  
  
  
  
  9.  private IList<decimal> Discounts { get; set; }
    10. 
  
  
  
  
  
  10.  private decimal Tax { get; set; }
    11. 
  
  
  
  
  
  11.  
    12. 
  
  
  
  
  
  12.  public decimal Calculate()
    13. 
  
  
  
  
  
  13.  {
    14. 
  
  
  
  
  
  14.  decimal subTotal = 0m;
    15. 
  
  
  
  
  
  15.  
    16. 
  
  
  
  
  
  16.  // Total up line items
    17. 
  
  
  
  
  
  17.  foreach (OrderLineItem lineItem in OrderLineItems)
    18. 
  
  
  
  
  
  18.  {
    19. 
  
  
  
  
  
  19.  subTotal += lineItem.Price;
    20. 
  
  
  
  
  
  20.  }
    21. 
  
  
  
  
  
  21.  
    22. 
  
  
  
  
  
  22.  // Subtract Discounts
    23. 
  
  
  
  
  
  23.  foreach (decimal discount in Discounts)
    24. 
  
  
  
  
  
  24.  subTotal -= discount;
    25. 
  
  
  
  
  
  25.  
    26. 
  
  
  
  
  
  26.  // Calculate Tax
    27. 
  
  
  
  
  
  27.  decimal tax = subTotal * Tax;
    28. 
  
  
  
  
  
  28.  
    29. 
  
  
  
  
  
  29.  // Calculate GrandTotal
    30. 
  
  
  
  
  
  30.  decimal grandTotal = subTotal + tax;
    31. 
  
  
  
  
  
  31.  return grandTotal;
    32. 
  
  
  
  
  
  32.  }
    33. 
  
  
  
  
  
  33. }
    34.

咱們經過構造函數，將返回計算結果的類的引用傳遞給包含多個計算方法的新建對象，或者向方法對象的構造函數中單獨傳遞各個參數。以下面的代碼：

 
 
 
 
 
    
  
  
  
  
  
  1. public class OrderLineItem
    2. 
  
  
  
  
  
  2. {
    3. 
  
  
  
  
  
  3.  public decimal Price { get; private set; }
    4. 
  
  
  
  
  
  4. }
    5. 
  
  
  
  
  
  5.  
    6. 
  
  
  
  
  
  6. public class Order
    7. 
  
  
  
  
  
  7. {
    8. 
  
  
  
  
  
  8.  public IEnumerable<OrderLineItem> OrderLineItems { get; private set; }
    9. 
  
  
  
  
  
  9.  public IEnumerable<decimal> Discounts { get; private set; }
    10. 
  
  
  
  
  
  10.  public decimal Tax { get; private set; }
    11. 
  
  
  
  
  
  11.  
    12. 
  
  
  
  
  
  12.  public decimal Calculate()
    13. 
  
  
  
  
  
  13.  {
    14. 
  
  
  
  
  
  14.  return new OrderCalculator(this).Calculate();
    15. 
  
  
  
  
  
  15.  }
    16. 
  
  
  
  
  
  16. }
    17. 
  
  
  
  
  
  17.  
    18. 
  
  
  
  
  
  18. public class OrderCalculator
    19. 
  
  
  
  
  
  19. {
    20. 
  
  
  
  
  
  20.  private decimal SubTotal { get; set; }
    21. 
  
  
  
  
  
  21.  private IEnumerable<OrderLineItem> OrderLineItems { get; set; }
    22. 
  
  
  
  
  
  22.  private IEnumerable<decimal> Discounts { get; set; }
    23. 
  
  
  
  
  
  23.  private decimal Tax { get; set; }
    24. 
  
  
  
  
  
  24.  
    25. 
  
  
  
  
  
  25.  public OrderCalculator(Order order)
    26. 
  
  
  
  
  
  26.  {
    27. 
  
  
  
  
  
  27.  OrderLineItems = order.OrderLineItems;
    28. 
  
  
  
  
  
  28.  Discounts = order.Discounts;
    29. 
  
  
  
  
  
  29.  Tax = order.Tax;
    30. 
  
  
  
  
  
  30.  }
    31. 
  
  
  
  
  
  31.  
    32. 
  
  
  
  
  
  32.  public decimal Calculate()
    33. 
  
  
  
  
  
  33.  {
    34. 
  
  
  
  
  
  34.  CalculateSubTotal();
    35. 
  
  
  
  
  
  35.  SubtractDiscounts();
    36. 
  
  
  
  
  
  36.  CalculateTax();
    37. 
  
  
  
  
  
  37.  return SubTotal;
    38. 
  
  
  
  
  
  38.  }
    39. 
  
  
  
  
  
  39.  
    40. 
  
  
  
  
  
  40.  private void CalculateSubTotal()
    41. 
  
  
  
  
  
  41.  {
    42. 
  
  
  
  
  
  42.  // Total up line items
    43. 
  
  
  
  
  
  43.  foreach (OrderLineItem lineItem in OrderLineItems)
    44. 
  
  
  
  
  
  44.  SubTotal += lineItem.Price;
    45. 
  
  
  
  
  
  45.  }
    46. 
  
  
  
  
  
  46.  
    47. 
  
  
  
  
  
  47.  private void SubtractDiscounts()
    48. 
  
  
  
  
  
  48.  {
    49. 
  
  
  
  
  
  49.  // Subtract Discounts
    50. 
  
  
  
  
  
  50.  foreach (decimal discount in Discounts)
    51. 
  
  
  
  
  
  51.  SubTotal -= discount;
    52. 
  
  
  
  
  
  52.  }
    53. 
  
  
  
  
  
  53.  
    54. 
  
  
  
  
  
  54.  private void CalculateTax()
    55. 
  
  
  
  
  
  55.  {
    56. 
  
  
  
  
  
  56.  // Calculate Tax
    57. 
  
  
  
  
  
  57.  SubTotal += SubTotal * Tax;
    58. 
  
  
  
  
  
  58.  }
    59. 
  
  
  
  
  
  59. }
    60.

 

代碼重構第14天：分離職責

把一個類的多個職責進行拆分，這貫徹了SOLID 中的單一職責原則（SRP）。儘管對於如何劃分「職責」常常存在爭論，但應用這項重構仍是十分簡單的。我這裏並不會回答劃分職責的問題，只是演示一個結構清晰的示例，將類劃分爲多個負責具體職責的類。

 
 
 
 
 
    
  
  
  
  
  
  1. public class Video
    2. 
  
  
  
  
  
  2. {
    3. 
  
  
  
  
  
  3.  public void PayFee(decimal fee)
    4. 
  
  
  
  
  
  4.  {
    5. 
  
  
  
  
  
  5.  }
    6. 
  
  
  
  
  
  6.  
    7. 
  
  
  
  
  
  7.  public void RentVideo(Video video, Customer customer)
    8. 
  
  
  
  
  
  8.  {
    9. 
  
  
  
  
  
  9.  customer.Videos.Add(video);
    10. 
  
  
  
  
  
  10.  }
    11. 
  
  
  
  
  
  11.  
    12. 
  
  
  
  
  
  12.  public decimal CalculateBalance(Customer customer)
    13. 
  
  
  
  
  
  13.  {
    14. 
  
  
  
  
  
  14.  return customer.LateFees.Sum();
    15. 
  
  
  
  
  
  15.  }
    16. 
  
  
  
  
  
  16. }
    17. 
  
  
  
  
  
  17.  
    18. 
  
  
  
  
  
  18. public class Customer
    19. 
  
  
  
  
  
  19. {
    20. 
  
  
  
  
  
  20.  public IList<decimal> LateFees { get; set; }
    21. 
  
  
  
  
  
  21.  public IList<Video> Videos { get; set; }
    22. 
  
  
  
  
  
  22. }
    23.

如你所見，Video類包含兩個職責，一個負責處理錄像租賃，另外一個負責管理管理用戶的租賃總數。要分離職責，咱們能夠將用戶的邏輯轉移到用戶類中。

 
 
 
 
 
    
  
  
  
  
  
  1. public class Video
    2. 
  
  
  
  
  
  2. {
    3. 
  
  
  
  
  
  3.  public void RentVideo(Video video, Customer customer)
    4. 
  
  
  
  
  
  4.  {
    5. 
  
  
  
  
  
  5.  customer.Videos.Add(video);
    6. 
  
  
  
  
  
  6.  }
    7. 
  
  
  
  
  
  7. }
    8. 
  
  
  
  
  
  8.  
    9. 
  
  
  
  
  
  9. public class Customer
    10. 
  
  
  
  
  
  10. {
    11. 
  
  
  
  
  
  11.  public IList<decimal> LateFees { get; set; }
    12. 
  
  
  
  
  
  12.  public IList<Video> Videos { get; set; }
    13. 
  
  
  
  
  
  13.  
    14. 
  
  
  
  
  
  14.  public void PayFee(decimal fee)
    15. 
  
  
  
  
  
  15.  {
    16. 
  
  
  
  
  
  16.  }
    17. 
  
  
  
  
  
  17.  
    18. 
  
  
  
  
  
  18.  public decimal CalculateBalance(Customer customer)
    19. 
  
  
  
  
  
  19.  {
    20. 
  
  
  
  
  
  20.  return customer.LateFees.Sum();
    21. 
  
  
  
  
  
  21.  }
    22. 
  
  
  
  
  
  22. }
    23.

 

代碼重構第15天：移除重複內容

這大概是處理一個方法在多處使用時最多見的重構。若是不加以注意的話，你會慢慢地養成重複的習慣。開發者經常因爲懶惰或者在想要儘快生成儘量多的代碼時，向代碼中添加不少重複的內容。我想也不必過多解釋了吧，直接看代碼把。

 
 
 
 
 
    
  
  
  
  
  
  1. public class MedicalRecord
    2. 
  
  
  
  
  
  2. {
    3. 
  
  
  
  
  
  3.  public DateTime DateArchived { get; private set; }
    4. 
  
  
  
  
  
  4.  public bool Archived { get; private set; }
    5. 
  
  
  
  
  
  5.  
    6. 
  
  
  
  
  
  6.  public void ArchiveRecord()
    7. 
  
  
  
  
  
  7.  {
    8. 
  
  
  
  
  
  8.  Archived = true;
    9. 
  
  
  
  
  
  9.  DateArchived = DateTime.Now;
    10. 
  
  
  
  
  
  10.  }
    11. 
  
  
  
  
  
  11.  
    12. 
  
  
  
  
  
  12.  public void CloseRecord()
    13. 
  
  
  
  
  
  13.  {
    14. 
  
  
  
  
  
  14.  Archived = true;
    15. 
  
  
  
  
  
  15.  DateArchived = DateTime.Now;
    16. 
  
  
  
  
  
  16.  }
    17. 
  
  
  
  
  
  17. }
    18.

咱們用共享方法的方式來刪除重複的代碼。看！沒有重複了吧？請務必在必要的時候執行這項重構。它能有效地減小bug，由於你不會將有bug的代碼複製/粘貼到各個角落。

 
 
 
 
 
    
  
  
  
  
  
  1. public class MedicalRecord
    2. 
  
  
  
  
  
  2. {
    3. 
  
  
  
  
  
  3.  public DateTime DateArchived { get; private set; }
    4. 
  
  
  
  
  
  4.  public bool Archived { get; private set; }
    5. 
  
  
  
  
  
  5.  
    6. 
  
  
  
  
  
  6.  public void ArchiveRecord()
    7. 
  
  
  
  
  
  7.  {
    8. 
  
  
  
  
  
  8.  SwitchToArchived();
    9. 
  
  
  
  
  
  9.  }
    10. 
  
  
  
  
  
  10.  
    11. 
  
  
  
  
  
  11.  public void CloseRecord()
    12. 
  
  
  
  
  
  12.  {
    13. 
  
  
  
  
  
  13.  SwitchToArchived();
    14. 
  
  
  
  
  
  14.  }
    15. 
  
  
  
  
  
  15.  
    16. 
  
  
  
  
  
  16.  private void SwitchToArchived()
    17. 
  
  
  
  
  
  17.  {
    18. 
  
  
  
  
  
  18.  Archived = true;
    19. 
  
  
  
  
  
  19.  DateArchived = DateTime.Now;
    20. 
  
  
  
  
  
  20.  }
    21. 
  
  
  
  
  
  21. }
    22.

 

代碼重構第16天：封裝條件

當代碼中充斥着若干條件判斷時，代碼的真正意圖會迷失於這些條件判斷之中。這時我喜歡將條件判斷提取到一個易於讀取的屬性或方法（若是有參數）中。重構以前的代碼以下：

 
 
 
 
 
    
  
  
  
  
  
  1. public class RemoteControl
    2. 
  
  
  
  
  
  2. {
    3. 
  
  
  
  
  
  3.  private string[] Functions { get; set; }
    4. 
  
  
  
  
  
  4.  private string Name { get; set; }
    5. 
  
  
  
  
  
  5.  private int CreatedYear { get; set; }
    6. 
  
  
  
  
  
  6.  
    7. 
  
  
  
  
  
  7.  public string PerformCoolFunction(string buttonPressed)
    8. 
  
  
  
  
  
  8.  {
    9. 
  
  
  
  
  
  9.  // Determine if we are controlling some extra function
    10. 
  
  
  
  
  
  10.  // that requires special conditions
    11. 
  
  
  
  
  
  11.  if (Functions.Length > 1 && Name == "RCA" &&
    12. 
  
  
  
  
  
  12.  CreatedYear > DateTime.Now.Year - 2)
    13. 
  
  
  
  
  
  13.  return "doSomething";
    14. 
  
  
  
  
  
  14.  }
    15. 
  
  
  
  
  
  15. }
    16.

重構以後，代碼的可讀性更強，意圖更明顯：

 
 
 
 
 
    
  
  
  
  
  
  1. public class RemoteControl
    2. 
  
  
  
  
  
  2. {
    3. 
  
  
  
  
  
  3.  private string[] Functions { get; set; }
    4. 
  
  
  
  
  
  4.  private string Name { get; set; }
    5. 
  
  
  
  
  
  5.  private int CreatedYear { get; set; }
    6. 
  
  
  
  
  
  6.  
    7. 
  
  
  
  
  
  7.  private bool HasExtraFunctions
    8. 
  
  
  
  
  
  8.  {
    9. 
  
  
  
  
  
  9.  get
    10. 
  
  
  
  
  
  10.  {
    11. 
  
  
  
  
  
  11.  return Functions.Length > 1 && Name == "RCA" &&
    12. 
  
  
  
  
  
  12.  CreatedYear > DateTime.Now.Year - 2;
    13. 
  
  
  
  
  
  13.  }
    14. 
  
  
  
  
  
  14.  }
    15. 
  
  
  
  
  
  15.  
    16. 
  
  
  
  
  
  16.  public string PerformCoolFunction(string buttonPressed)
    17. 
  
  
  
  
  
  17.  {
    18. 
  
  
  
  
  
  18.  // Determine if we are controlling some extra function
    19. 
  
  
  
  
  
  19.  // that requires special conditions
    20. 
  
  
  
  
  
  20.  if (HasExtraFunctions)
    21. 
  
  
  
  
  
  21.  return "doSomething";
    22. 
  
  
  
  
  
  22.  }
    23. 
  
  
  
  
  
  23. }
    24.

 

代碼重構第17天：提取父類

今天的重構來自於Martin Fowler的重構目錄，當一個類有不少方法但願將它們「提拔」到基類以供同層次的其餘類使用時，會常用該重構。下面的類包含兩個方法，咱們但願提取這兩個方法並容許其餘類使用。

 
 
 
 
 
    
  
  
  
  
  
  1. public class Dog
    2. 
  
  
  
  
  
  2. {
    3. 
  
  
  
  
  
  3.  public void EatFood()
    4. 
  
  
  
  
  
  4.  {
    5. 
  
  
  
  
  
  5.  // eat some food
    6. 
  
  
  
  
  
  6.  }
    7. 
  
  
  
  
  
  7.  
    8. 
  
  
  
  
  
  8.  public void Groom()
    9. 
  
  
  
  
  
  9.  {
    10. 
  
  
  
  
  
  10.  // perform grooming
    11. 
  
  
  
  
  
  11.  }
    12. 
  
  
  
  
  
  12. }
    13.

重構以後，咱們僅僅將須要的方法轉移到了一個新的基類中。這很相似「Pull Up」重構，只是在重構以前，並不存在基類。

 
 
 
 
 
    
  
  
  
  
  
  1. public class Animal
    2. 
  
  
  
  
  
  2. {
    3. 
  
  
  
  
  
  3.  public void EatFood()
    4. 
  
  
  
  
  
  4.  {
    5. 
  
  
  
  
  
  5.  // eat some food
    6. 
  
  
  
  
  
  6.  }
    7. 
  
  
  
  
  
  7.  
    8. 
  
  
  
  
  
  8.  public void Groom()
    9. 
  
  
  
  
  
  9.  {
    10. 
  
  
  
  
  
  10.  // perform grooming
    11. 
  
  
  
  
  
  11.  }
    12. 
  
  
  
  
  
  12. }
    13. 
  
  
  
  
  
  13.  
    14. 
  
  
  
  
  
  14. public class Dog : Animal
    15. 
  
  
  
  
  
  15. {
    16. 
  
  
  
  
  
  16. }
    17.

 

代碼重構第18天：使用條件判斷代替異常

今天的重構沒有什麼出處，是我平時常用而總結出來的。歡迎您發表任何改進意見或建議。我相信必定還有其餘比較好的重構能夠解決相似的問題。

我曾無數次面對的一個代碼壞味道就是，使用異常來控制程序流程。您可能會看到相似的代碼：

 
 
 
 
 
    
  
  
  
  
  
  1. public class Microwave
    2. 
  
  
  
  
  
  2. {
    3. 
  
  
  
  
  
  3.  private IMicrowaveMotor Motor { get; set; }
    4. 
  
  
  
  
  
  4.  
    5. 
  
  
  
  
  
  5.  public bool Start(object food)
    6. 
  
  
  
  
  
  6.  {
    7. 
  
  
  
  
  
  7.  bool foodCooked = false;
    8. 
  
  
  
  
  
  8.  try
    9. 
  
  
  
  
  
  9.  {
    10. 
  
  
  
  
  
  10.  Motor.Cook(food);
    11. 
  
  
  
  
  
  11.  foodCooked = true;
    12. 
  
  
  
  
  
  12.  }
    13. 
  
  
  
  
  
  13.  catch (InUseException)
    14. 
  
  
  
  
  
  14.  {
    15. 
  
  
  
  
  
  15.  foodcooked = false;
    16. 
  
  
  
  
  
  16.  }
    17. 
  
  
  
  
  
  17.  return foodCooked;
    18. 
  
  
  
  
  
  18.  }
    19. 
  
  
  
  
  
  19. }
    20.

異常應該僅僅完成本身的本職工做：處理異常行爲。大多數狀況你均可以將這些代碼用恰當的條件判斷替換，並進行恰當的處理。下面的代碼能夠稱之爲契約式設計，由於咱們在執行具體工做以前明確了Motor類的狀態，而不是經過異常來進行處理。

 
 
 
 
 
    
  
  
  
  
  
  1. public class Microwave
    2. 
  
  
  
  
  
  2. {
    3. 
  
  
  
  
  
  3.  private IMicrowaveMotor Motor { get; set; }
    4. 
  
  
  
  
  
  4.  public bool Start(object food)
    5. 
  
  
  
  
  
  5.  {
    6. 
  
  
  
  
  
  6.  if (Motor.IsInUse)
    7. 
  
  
  
  
  
  7.  return false;
    8. 
  
  
  
  
  
  8.  Motor.Cook(food);
    9. 
  
  
  
  
  
  9.  return true;
    10. 
  
  
  
  
  
  10. }
    11. 
  
  
  
  
  
  11. }
    12.

 

代碼重構第19天：提取工廠類

今天的重構是由GangOfFour首先提出的，網絡上有不少關於該模式不一樣的用法。

在代碼中，一般須要一些複雜的對象建立工做，以使這些對象達到一種可使用的狀態。一般狀況下，這種建立不過是新建對象實例，並以咱們須要的方式進行工做。可是，有時候這種建立對象的需求會極具增加，而且混淆了建立對象的原始代碼。這時，工廠類就派上用場了。最複雜的工廠模式是使用抽象工廠建立對象族。而咱們只是使用最基本的方式，用一個工廠類建立
一個特殊類的實例。來看下面的代碼：

 
 
 
 
 
    
  
  
  
  
  
  1. public class PoliceCarController
    2. 
  
  
  
  
  
  2. {
    3. 
  
  
  
  
  
  3.  public PoliceCar New(int mileage, bool serviceRequired)
    4. 
  
  
  
  
  
  4.  {
    5. 
  
  
  
  
  
  5.  PoliceCar policeCar = new PoliceCar();
    6. 
  
  
  
  
  
  6.  policeCar.ServiceRequired = serviceRequired;
    7. 
  
  
  
  
  
  7.  policeCar.Mileage = mileage;
    8. 
  
  
  
  
  
  8.  return policeCar;
    9. 
  
  
  
  
  
  9.  }
    10. 
  
  
  
  
  
  10. }
    11.

如您所見，New方法負責建立PoliceCar並根據一些外部輸入初始化PoliceCar的某些屬性。對於簡單的建立工做來講，這樣作能夠從容應對。可是長此以往，建立的工做量愈來愈大，而且被附加在controller 類上，但這並非controller類的職責。這時，咱們能夠將建立代碼提取到一個Factory類中去，由該類負責PoliceCar實例的建立。

 
 
 
 
 
    
  
  
  
  
  
  1. public interface IPoliceCarFactory
    2. 
  
  
  
  
  
  2. {
    3. 
  
  
  
  
  
  3.  PoliceCar Create(int mileage, bool serviceRequired);
    4. 
  
  
  
  
  
  4. }
    5. 
  
  
  
  
  
  5.  
    6. 
  
  
  
  
  
  6. public class PoliceCarFactory : IPoliceCarFactory
    7. 
  
  
  
  
  
  7. {
    8. 
  
  
  
  
  
  8.  public PoliceCar Create(int mileage, bool serviceRequired)
    9. 
  
  
  
  
  
  9.  {
    10. 
  
  
  
  
  
  10.  PoliceCar policeCar = new PoliceCar();
    11. 
  
  
  
  
  
  11.  policeCar.ReadForService = serviceRequired;
    12. 
  
  
  
  
  
  12.  policeCar.Mileage = mileage;
    13. 
  
  
  
  
  
  13.  return policeCar;
    14. 
  
  
  
  
  
  14.  }
    15. 
  
  
  
  
  
  15. }
    16. 
  
  
  
  
  
  16.  
    17. 
  
  
  
  
  
  17. public class PoliceCarController
    18. 
  
  
  
  
  
  18. {
    19. 
  
  
  
  
  
  19.  public IPoliceCarFactory PoliceCarFactory { get; set; }
    20. 
  
  
  
  
  
  20.  public PoliceCarController(IPoliceCarFactory policeCarFactory)
    21. 
  
  
  
  
  
  21.  {
    22. 
  
  
  
  
  
  22.  PoliceCarFactory = policeCarFactory;
    23. 
  
  
  
  
  
  23.  }
    24. 
  
  
  
  
  
  24.  
    25. 
  
  
  
  
  
  25.  public PoliceCar New(int mileage, bool serviceRequired)
    26. 
  
  
  
  
  
  26.  {
    27. 
  
  
  
  
  
  27.  return PoliceCarFactory.Create(mileage, serviceRequired);
    28. 
  
  
  
  
  
  28.  }
    29. 
  
  
  
  
  
  29. }
    30.

因爲將建立的邏輯轉移到了工廠中，咱們能夠添加一個類來專門負責實例的建立，而沒必要擔憂在建立或複製代碼的過程當中有所遺漏。

 

代碼重構第20天：提取子類

今天的重構來自於Martin Fowler的模式目錄。你能夠在他的目錄中找到該重構。

當一個類中的某些方法並非面向全部的類時，可使用該重構將其遷移到子類中。我這裏舉的例子十分簡單，它包含一個Registration類，該類處理與學生註冊課程相關的全部信息。

 
 
 
 
 
    
  
  
  
  
  
  1. public class Registration
    2. 
  
  
  
  
  
  2. {
    3. 
  
  
  
  
  
  3.  public NonRegistrationAction Action { get; set; }
    4. 
  
  
  
  
  
  4.  public decimal RegistrationTotal { get; set; }
    5. 
  
  
  
  
  
  5.  public string Notes { get; set; }
    6. 
  
  
  
  
  
  6.  public string Description { get; set; }
    7. 
  
  
  
  
  
  7.  public DateTime RegistrationDate { get; set; }
    8. 
  
  
  
  
  
  8. }
    9.

當使用了該類以後，咱們就會意識到問題所在——它應用於兩個徹底不一樣的場景。屬性NonRegistrationAction和Notes 只有在處理與普通註冊略有不一樣的NonRegistration 時纔會使用。所以，咱們能夠提取一個子類，並將這兩個屬性轉移到NonRegistration類中，這樣才更合適。

 
 
 
 
 
    
  
  
  
  
  
  1. public class Registration
    2. 
  
  
  
  
  
  2. {
    3. 
  
  
  
  
  
  3.  public decimal RegistrationTotal { get; set; }
    4. 
  
  
  
  
  
  4.  public string Description { get; set; }
    5. 
  
  
  
  
  
  5.  public DateTime RegistrationDate { get; set; }
    6. 
  
  
  
  
  
  6. }
    7. 
  
  
  
  
  
  7.  
    8. 
  
  
  
  
  
  8. public class NonRegistration : Registration
    9. 
  
  
  
  
  
  9. {
    10. 
  
  
  
  
  
  10.  public NonRegistrationAction Action { get; set; }
    11. 
  
  
  
  
  
  11.  public string Notes { get; set; }
    12. 
  
  
  
  
  
  12. }
    13.

 

代碼重構第21天：合併繼承

今天的重構來自於Martin Fowler的模式目錄。你能夠在他的目錄中找到該重構。昨天，咱們經過提取子類來下放職責。而今天，當咱們意識到再也不須要某個子類時，可使用Collapse Hierarchy 重構。若是某個子類的屬性（以及其餘成員）能夠被合併到基類中，這時再保留這個子類已經沒有任何意義了。

 
 
 
 
 
    
  
  
  
  
  
  1. public class Website
    2. 
  
  
  
  
  
  2. {
    3. 
  
  
  
  
  
  3.  public string Title { get; set; }
    4. 
  
  
  
  
  
  4.  public string Description { get; set; }
    5. 
  
  
  
  
  
  5.  public IEnumerable<Webpage> Pages { get; set; }
    6. 
  
  
  
  
  
  6. }
    7. 
  
  
  
  
  
  7.  
    8. 
  
  
  
  
  
  8. public class StudentWebsite : Website
    9. 
  
  
  
  
  
  9. {
    10. 
  
  
  
  
  
  10.  public bool IsActive { get; set; }
    11. 
  
  
  
  
  
  11. }
    12.

這裏的子類並無過多的功能，只是表示站點是否激活。這時咱們會意識到判斷站點是否激活的功能應該是通用的。所以能夠將子類的功能放回到Website 中，並刪除StudentWebsite 類型。

 
 
 
 
 
    
  
  
  
  
  
  1. public class Website
    2. 
  
  
  
  
  
  2. {
    3. 
  
  
  
  
  
  3.  public string Title { get; set; }
    4. 
  
  
  
  
  
  4.  public string Description { get; set; }
    5. 
  
  
  
  
  
  5.  public IEnumerable<Webpage> Pages { get; set; }
    6. 
  
  
  
  
  
  6.  public bool IsActive { get; set; }
    7. 
  
  
  
  
  
  7. }
    8.

 

代碼重構第22天：分解方法

今天的重構沒有任何出處。可能已經有其餘人使用了相同的重構，只是名稱不一樣罷了。若是你知道誰的名字比Break Method更好，請轉告我。

這個重構是一種元重構（meta-refactoring），它只是不停地使用提取方法重構，直到將一個大的方法分解成若干個小的方法。下面的例子有點作做，AcceptPayment 方法沒有豐富的功能。所以爲了使其更接近真實場景，咱們只能假設該方法中包含了其餘大量的輔助代碼。

下面的AcceptPayment 方法能夠被劃分爲多個單獨的方法。

 
 
 
 
 
    
  
  
  
  
  
  1. public class CashRegister
    2. 
  
  
  
  
  
  2. {
    3. 
  
  
  
  
  
  3.  public CashRegister()
    4. 
  
  
  
  
  
  4.  {
    5. 
  
  
  
  
  
  5.  Tax = 0.06m;
    6. 
  
  
  
  
  
  6.  }
    7. 
  
  
  
  
  
  7.  
    8. 
  
  
  
  
  
  8.  private decimal Tax { get; set; }
    9. 
  
  
  
  
  
  9.  public void AcceptPayment(Customer customer, IEnumerable<Product> products, decimal payment)
    10. 
  
  
  
  
  
  10.  {
    11. 
  
  
  
  
  
  11.  decimal subTotal = 0m;
    12. 
  
  
  
  
  
  12.  
    13. 
  
  
  
  
  
  13.  foreach (Product product in products)
    14. 
  
  
  
  
  
  14.  {
    15. 
  
  
  
  
  
  15.  subTotal += product.Price;
    16. 
  
  
  
  
  
  16.  }
    17. 
  
  
  
  
  
  17.  
    18. 
  
  
  
  
  
  18.  foreach (Product product in products)
    19. 
  
  
  
  
  
  19.  {
    20. 
  
  
  
  
  
  20.  subTotal -= product.AvailableDiscounts;
    21. 
  
  
  
  
  
  21.  }
    22. 
  
  
  
  
  
  22.  
    23. 
  
  
  
  
  
  23.  decimal grandTotal = subTotal * Tax;
    24. 
  
  
  
  
  
  24.  customer.DeductFromAccountBalance(grandTotal);
    25. 
  
  
  
  
  
  25.  }
    26. 
  
  
  
  
  
  26. }
    27. 
  
  
  
  
  
  27.  
    28. 
  
  
  
  
  
  28. public class Customer
    29. 
  
  
  
  
  
  29. {
    30. 
  
  
  
  
  
  30.  public void DeductFromAccountBalance(decimal amount)
    31. 
  
  
  
  
  
  31.  {
    32. 
  
  
  
  
  
  32.  // deduct from balance
    33. 
  
  
  
  
  
  33.  }
    34. 
  
  
  
  
  
  34. }
    35. 
  
  
  
  
  
  35.  
    36. 
  
  
  
  
  
  36. public class Product
    37. 
  
  
  
  
  
  37. {
    38. 
  
  
  
  
  
  38.  public decimal Price { get; set; }
    39. 
  
  
  
  
  
  39.  public decimal AvailableDiscounts { get; set; }
    40. 
  
  
  
  
  
  40. }
    41.

如您所見，AcceptPayment方法包含多個功能，能夠被分解爲多個子方法。所以咱們屢次使用提取方法重構，結果以下：

 
 
 
 
 
    
  
  
  
  
  
  1. public class CashRegister
    2. 
  
  
  
  
  
  2. {
    3. 
  
  
  
  
  
  3.  public CashRegister()
    4. 
  
  
  
  
  
  4.  {
    5. 
  
  
  
  
  
  5.  Tax = 0.06m;
    6. 
  
  
  
  
  
  6.  }
    7. 
  
  
  
  
  
  7.  
    8. 
  
  
  
  
  
  8.  private decimal Tax { get; set; }
    9. 
  
  
  
  
  
  9.  private IEnumerable<Product> Products { get; set; }
    10. 
  
  
  
  
  
  10.  
    11. 
  
  
  
  
  
  11.  public void AcceptPayment(Customer customer, IEnumerable<Product> products, decimal payment)
    12. 
  
  
  
  
  
  12.  {
    13. 
  
  
  
  
  
  13.  decimal subTotal = CalculateSubtotal();
    14. 
  
  
  
  
  
  14.  subTotal = SubtractDiscounts(subTotal);
    15. 
  
  
  
  
  
  15.  decimal grandTotal = AddTax(subTotal);
    16. 
  
  
  
  
  
  16.  SubtractFromCustomerBalance(customer, grandTotal);
    17. 
  
  
  
  
  
  17.  }
    18. 
  
  
  
  
  
  18.  
    19. 
  
  
  
  
  
  19.  private void SubtractFromCustomerBalance(Customer customer, decimal grandTotal)
    20. 
  
  
  
  
  
  20.  {
    21. 
  
  
  
  
  
  21.  customer.DeductFromAccountBalance(grandTotal);
    22. 
  
  
  
  
  
  22.  }
    23. 
  
  
  
  
  
  23.  
    24. 
  
  
  
  
  
  24.  private decimal AddTax(decimal subTotal)
    25. 
  
  
  
  
  
  25.  {
    26. 
  
  
  
  
  
  26.  return subTotal * Tax;
    27. 
  
  
  
  
  
  27.  }
    28. 
  
  
  
  
  
  28.  
    29. 
  
  
  
  
  
  29.  private decimal SubtractDiscounts(decimal subTotal)
    30. 
  
  
  
  
  
  30.  {
    31. 
  
  
  
  
  
  31.  foreach (Product product in Products)
    32. 
  
  
  
  
  
  32.  {
    33. 
  
  
  
  
  
  33.  subTotal -= product.AvailableDiscounts;
    34. 
  
  
  
  
  
  34.  }
    35. 
  
  
  
  
  
  35.  return subTotal;
    36. 
  
  
  
  
  
  36.  }
    37. 
  
  
  
  
  
  37.  
    38. 
  
  
  
  
  
  38.  private decimal CalculateSubtotal()
    39. 
  
  
  
  
  
  39.  {
    40. 
  
  
  
  
  
  40.  decimal subTotal = 0m;
    41. 
  
  
  
  
  
  41.  foreach (Product product in Products)
    42. 
  
  
  
  
  
  42.  {
    43. 
  
  
  
  
  
  43.  subTotal += product.Price;
    44. 
  
  
  
  
  
  44.  }
    45. 
  
  
  
  
  
  45.  return subTotal;
    46. 
  
  
  
  
  
  46.  }
    47. 
  
  
  
  
  
  47. }
    48. 
  
  
  
  
  
  48.  
    49. 
  
  
  
  
  
  49. public class Customer
    50. 
  
  
  
  
  
  50. {
    51. 
  
  
  
  
  
  51.  public void DeductFromAccountBalance(decimal amount)
    52. 
  
  
  
  
  
  52.  {
    53. 
  
  
  
  
  
  53.  // deduct from balance
    54. 
  
  
  
  
  
  54.  }
    55. 
  
  
  
  
  
  55. }
    56. 
  
  
  
  
  
  56.  
    57. 
  
  
  
  
  
  57. public class Product
    58. 
  
  
  
  
  
  58. {
    59. 
  
  
  
  
  
  59.  public decimal Price { get; set; }
    60. 
  
  
  
  
  
  60.  public decimal AvailableDiscounts { get; set; }
    61. 
  
  
  
  
  
  61. }
    62.

 

代碼重構第23天：引入參數對象

該重構來自於Fowler的重構目錄。有時當使用一個包含多個參數的方法時，因爲參數過多會致使可讀性嚴重降低，如：

 
 
 
 
 
    
  
  
  
  
  
  1. public void Create(decimal amount, Student student, IEnumerable<Course> courses, decimal credits)
    2. 
  
  
  
  
  
  2. {
    3. 
  
  
  
  
  
  3.  // do work
    4. 
  
  
  
  
  
  4. }
    5.

這時有必要新建一個類，負責攜帶方法的參數。若是要增長更多的參數，只需爲對參數對象增長其餘的字段就能夠了，代碼顯得更加靈活。要注意，僅僅在方法的參數確實過多時才使用該重構，不然會使類的數量暴增，而這本應該越少越好。

 
 
 
 
 
    
  
  
  
  
  
  1. public class RegistrationContext
    2. 
  
  
  
  
  
  2. {
    3. 
  
  
  
  
  
  3.  public decimal Amount { get; set; }
    4. 
  
  
  
  
  
  4.  public Student Student { get; set; }
    5. 
  
  
  
  
  
  5.  public IEnumerable<Course> Courses { get; set; }
    6. 
  
  
  
  
  
  6.  public decimal Credits { get; set; }
    7. 
  
  
  
  
  
  7. }
    8. 
  
  
  
  
  
  8.  
    9. 
  
  
  
  
  
  9. public class Registration
    10. 
  
  
  
  
  
  10. {
    11. 
  
  
  
  
  
  11.  public void Create(RegistrationContext registrationContext)
    12. 
  
  
  
  
  
  12.  {
    13. 
  
  
  
  
  
  13.  // do work
    14. 
  
  
  
  
  
  14.  }
    15. 
  
  
  
  
  
  15. }
    16.

 

代碼重構第24天：分解複雜判斷

今天的重構基於c2的wiki條目。Los Techies的Chris Missal一樣也些了一篇關於反模式的post。簡單地說，當你使用大量的嵌套條件判斷時，造成了箭頭型的代碼，這就是箭頭反模式（arrowhead
antipattern）。我常常在不一樣的代碼庫中看到這種現象，這提升了代碼的圈複雜度（cyclomatic complexity）。下面的例子演示了箭頭反模式：

 
 
 
 
 
    
  
  
  
  
  
  1. public class Security
    2. 
  
  
  
  
  
  2. {
    3. 
  
  
  
  
  
  3.  public ISecurityChecker SecurityChecker { get; set; }
    4. 
  
  
  
  
  
  4.  public Security(ISecurityChecker securityChecker)
    5. 
  
  
  
  
  
  5.  {
    6. 
  
  
  
  
  
  6.  SecurityChecker = securityChecker;
    7. 
  
  
  
  
  
  7.  }
    8. 
  
  
  
  
  
  8.  
    9. 
  
  
  
  
  
  9.  public bool HasAccess(User user, Permission permission, IEnumerable<Permission> exemptions)
    10. 
  
  
  
  
  
  10.  {
    11. 
  
  
  
  
  
  11.  bool hasPermission = false;
    12. 
  
  
  
  
  
  12.  if (user != null)
    13. 
  
  
  
  
  
  13.  {
    14. 
  
  
  
  
  
  14.  if (permission != null)
    15. 
  
  
  
  
  
  15.  {
    16. 
  
  
  
  
  
  16.  if (exemptions.Count() == 0)
    17. 
  
  
  
  
  
  17.  {
    18. 
  
  
  
  
  
  18.  if (SecurityChecker.CheckPermission(user, permission) || exemptions.Contains(permission))
    19. 
  
  
  
  
  
  19.  {
    20. 
  
  
  
  
  
  20.  hasPermission = true;
    21. 
  
  
  
  
  
  21.  }
    22. 
  
  
  
  
  
  22.  }
    23. 
  
  
  
  
  
  23.  }
    24. 
  
  
  
  
  
  24.  }
    25. 
  
  
  
  
  
  25.  return hasPermission;
    26. 
  
  
  
  
  
  26.  }
    27. 
  
  
  
  
  
  27. }
    28.

移除箭頭反模式的重構和封裝條件判斷同樣簡單。這種方式的重構在方法執行以前每每會評估各個條件，這有點相似於契約式設計驗證。下面是重構以後的代碼：

 
 
 
 
 
    
  
  
  
  
  
  1. public class Security
    2. 
  
  
  
  
  
  2. {
    3. 
  
  
  
  
  
  3.  public ISecurityChecker SecurityChecker { get; set; }
    4. 
  
  
  
  
  
  4.  
    5. 
  
  
  
  
  
  5.  public Security(ISecurityChecker securityChecker)
    6. 
  
  
  
  
  
  6.  {
    7. 
  
  
  
  
  
  7.  SecurityChecker = securityChecker;
    8. 
  
  
  
  
  
  8.  }
    9. 
  
  
  
  
  
  9.  
    10. 
  
  
  
  
  
  10.  public bool HasAccess(User user, Permission permission, IEnumerable<Permission> exemptions)
    11. 
  
  
  
  
  
  11.  {
    12. 
  
  
  
  
  
  12.  if (user == null || permission == null)
    13. 
  
  
  
  
  
  13.  return false;
    14. 
  
  
  
  
  
  14.  
    15. 
  
  
  
  
  
  15.  if (exemptions.Contains(permission))
    16. 
  
  
  
  
  
  16.  return true;
    17. 
  
  
  
  
  
  17.  return SecurityChecker.CheckPermission(user, permission);
    18. 
  
  
  
  
  
  18.  }
    19. 
  
  
  
  
  
  19. }
    20.

如你所見，該方法大大整價了可讀性和之後的可維護性。不難看出，該方法的全部可能的路徑都會通過驗證。

 

代碼重構第25天：引入契約式設計

契約式設計（DBC，Design By Contract）定義了方法應該包含輸入和輸出驗證。所以，能夠確保全部的工做都是基於可用的數據，而且全部的行爲都是可預料的。不然，將返回異常或錯誤並在方法中進行處理。要了解更多關於DBC的內容，能夠訪問wikipedia。

在咱們的示例中，輸入參數極可能爲null。因爲沒有進行驗證，該方法最終會拋出NullReferenceException。在方法最後，咱們也並不肯定是否爲用戶返回了一個有效的decimal，這可能致使在別的地方引入其餘方法。

 
 
 
 
 
    
  
  
  
  
  
  1. public class CashRegister
    2. 
  
  
  
  
  
  2. {
    3. 
  
  
  
  
  
  3.  public decimal TotalOrder(IEnumerable<Product> products, Customer customer)
    4. 
  
  
  
  
  
  4.  {
    5. 
  
  
  
  
  
  5.  decimal orderTotal = products.Sum(product => product.Price);
    6. 
  
  
  
  
  
  6.  customer.Balance += orderTotal;
    7. 
  
  
  
  
  
  7.  return orderTotal;
    8. 
  
  
  
  
  
  8.  }
    9. 
  
  
  
  
  
  9. }
    10.

在此處引入DBC 驗證是十分簡單的。首先，咱們要聲明customer 不能爲null，而且在計算總值時至少要有一個product。在返回訂單總值時，咱們要肯定其值是否有效。若是此例中任何一個驗證失敗，咱們將以友好的方式拋出相應的異常來描述具體信息，而不是拋出一個晦澀的NullReferenceException。

在.NET Framework 3.5的Microsoft.Contracts命名空間中包含一些DBC框架和異常。我我的尚未使用，但它們仍是值得一看的。關於該命名空間只有在MSDN上能找到點資料。

 
 
 
 
 
    
  
  
  
  
  
  1. public class CashRegister
    2. 
  
  
  
  
  
  2. {
    3. 
  
  
  
  
  
  3.  public decimal TotalOrder(IEnumerable<Product> products, Customer customer)
    4. 
  
  
  
  
  
  4.  {
    5. 
  
  
  
  
  
  5.  if (customer == null)
    6. 
  
  
  
  
  
  6.  throw new ArgumentNullException("customer", "Customer cannot be null");
    7. 
  
  
  
  
  
  7.  if (products.Count() == 0)
    8. 
  
  
  
  
  
  8.  throw new ArgumentException("Must have at least one product to total", "products");
    9. 
  
  
  
  
  
  9.  
    10. 
  
  
  
  
  
  10.  decimal orderTotal = products.Sum(product => product.Price);
    11. 
  
  
  
  
  
  11.  customer.Balance += orderTotal;
    12. 
  
  
  
  
  
  12.  
    13. 
  
  
  
  
  
  13.  if (orderTotal == 0)
    14. 
  
  
  
  
  
  14.  throw new ArgumentOutOfRangeException("orderTotal", "Order Total should not be zero");
    15. 
  
  
  
  
  
  15.  
    16. 
  
  
  
  
  
  16.  return orderTotal;
    17. 
  
  
  
  
  
  17.  }
    18. 
  
  
  
  
  
  18. }
    19.

在驗證過程當中確實增長了很多代碼，你也許會認爲過分使用了DBC。但我認爲在大多數狀況下，處理這些棘手的問題所作的努力都是值得的。追蹤無詳細內容的NullReferenceException的確不是什麼美差。

 

代碼重構第26天：避免雙重否認

今天的重構來自於Fowler的重構目錄。
儘管我在不少代碼中發現了這種嚴重下降可讀性並每每傳達錯誤意圖的壞味道，但這種重構自己仍是很容易實現的。這種毀滅性的代碼所基於的假設致使了錯誤的代碼編寫習慣，並最終致使bug。以下例所示：

 
 
 
 
 
    
  
  
  
  
  
  1. public class Order
    2. 
  
  
  
  
  
  2. {
    3. 
  
  
  
  
  
  3.  public void Checkout(IEnumerable<Product> products, Customer customer)
    4. 
  
  
  
  
  
  4.  {
    5. 
  
  
  
  
  
  5.  if (!customer.IsNotFlagged)
    6. 
  
  
  
  
  
  6.  {
    7. 
  
  
  
  
  
  7.  // the customer account is flagged
    8. 
  
  
  
  
  
  8.  // log some errors and return
    9. 
  
  
  
  
  
  9.  return;
    10. 
  
  
  
  
  
  10.  }
    11. 
  
  
  
  
  
  11.  
    12. 
  
  
  
  
  
  12.  // normal order processing
    13. 
  
  
  
  
  
  13.  }
    14. 
  
  
  
  
  
  14. }
    15. 
  
  
  
  
  
  15.  
    16. 
  
  
  
  
  
  16. public class Customer
    17. 
  
  
  
  
  
  17. {
    18. 
  
  
  
  
  
  18.  public decimal Balance { get; private set; }
    19. 
  
  
  
  
  
  19.  
    20. 
  
  
  
  
  
  20.  public bool IsNotFlagged
    21. 
  
  
  
  
  
  21.  {
    22. 
  
  
  
  
  
  22.  get { return Balance < 30m; }
    23. 
  
  
  
  
  
  23.  }
    24. 
  
  
  
  
  
  24. }
    25.

如你所見，這裏的雙重否認十分難以理解，咱們不得不找出什麼纔是雙重否認所要表達的確定狀態。修改代碼是很容易的。若是咱們找不到確定的判斷，能夠添加一個處理雙重否認的假設，而不要在獲得結果以後再去驗證。

 
 
 
 
 
    
  
  
  
  
  
  1. public class Order
    2. 
  
  
  
  
  
  2. {
    3. 
  
  
  
  
  
  3.  public void Checkout(IEnumerable<Product> products, Customer customer)
    4. 
  
  
  
  
  
  4.  {
    5. 
  
  
  
  
  
  5.  if (customer.IsFlagged)
    6. 
  
  
  
  
  
  6.  {
    7. 
  
  
  
  
  
  7.  // the customer account is flagged
    8. 
  
  
  
  
  
  8.  // log some errors and return
    9. 
  
  
  
  
  
  9.  return;
    10. 
  
  
  
  
  
  10.  }
    11. 
  
  
  
  
  
  11.  
    12. 
  
  
  
  
  
  12.  // normal order processing
    13. 
  
  
  
  
  
  13.  }
    14. 
  
  
  
  
  
  14. }
    15. 
  
  
  
  
  
  15.  
    16. 
  
  
  
  
  
  16. public class Customer
    17. 
  
  
  
  
  
  17. {
    18. 
  
  
  
  
  
  18.  public decimal Balance { get; private set; }
    19. 
  
  
  
  
  
  19.  
    20. 
  
  
  
  
  
  20.  public bool IsFlagged
    21. 
  
  
  
  
  
  21.  {
    22. 
  
  
  
  
  
  22.  get { return Balance >= 30m; }
    23. 
  
  
  
  
  
  23.  }
    24. 
  
  
  
  
  
  24. }
    25.

 

代碼重構第27天：去除上帝類

在傳統的代碼庫中，咱們經常會看到一些違反了SRP原則的類。這些類一般以Utils或Manager結尾，有時也沒有這麼明顯的特徵而僅僅是普通的包含多個功能的類。這種God 類還有一個特徵，使用語句或註釋將代碼分隔爲多個不一樣角色的分組，而這些角色正是這一個類所扮演的。

長此以往，這些類成爲了那些沒有時間放置到恰當類中的方法的垃圾桶。這時的重構須要將方法分解成多個負責單一職責的類。

 
 
 
 
 
    
  
  
  
  
  
  1. public class CustomerService
    2. 
  
  
  
  
  
  2. {
    3. 
  
  
  
  
  
  3.  public decimal CalculateOrderDiscount(IEnumerable<Product> products, Customer customer)
    4. 
  
  
  
  
  
  4.  {
    5. 
  
  
  
  
  
  5.  // do work
    6. 
  
  
  
  
  
  6.  }
    7. 
  
  
  
  
  
  7.  
    8. 
  
  
  
  
  
  8.  public bool CustomerIsValid(Customer customer, Order order)
    9. 
  
  
  
  
  
  9.  {
    10. 
  
  
  
  
  
  10.  // do work
    11. 
  
  
  
  
  
  11.  }
    12. 
  
  
  
  
  
  12.  
    13. 
  
  
  
  
  
  13.  public IEnumerable<string> GatherOrderErrors(IEnumerable<Product> products, Customer customer)
    14. 
  
  
  
  
  
  14.  {
    15. 
  
  
  
  
  
  15.  // do work
    16. 
  
  
  
  
  
  16.  }
    17. 
  
  
  
  
  
  17.  
    18. 
  
  
  
  
  
  18.  public void Register(Customer customer)
    19. 
  
  
  
  
  
  19.  {
    20. 
  
  
  
  
  
  20.  // do work
    21. 
  
  
  
  
  
  21.  }
    22. 
  
  
  
  
  
  22.  
    23. 
  
  
  
  
  
  23.  public void ForgotPassword(Customer customer)
    24. 
  
  
  
  
  
  24.  {
    25. 
  
  
  
  
  
  25.  // do work
    26. 
  
  
  
  
  
  26.  }
    27. 
  
  
  
  
  
  27. }
    28.

使用該重構是很是簡單明瞭的，只需把相關方法提取出來並放置到負責相應職責的類中便可。這使得類的粒度更細、職責更分明、往後的維護更方便。上例的代碼最終被分解爲兩個類：

 
 
 
 
 
    
  
  
  
  
  
  1. public class CustomerOrderService
    2. 
  
  
  
  
  
  2. {
    3. 
  
  
  
  
  
  3.  public decimal CalculateOrderDiscount(IEnumerable<Product> products, Customer customer)
    4. 
  
  
  
  
  
  4.  {
    5. 
  
  
  
  
  
  5.  // do work
    6. 
  
  
  
  
  
  6.  }
    7. 
  
  
  
  
  
  7.  
    8. 
  
  
  
  
  
  8.  public bool CustomerIsValid(Customer customer, Order order)
    9. 
  
  
  
  
  
  9.  {
    10. 
  
  
  
  
  
  10.  // do work
    11. 
  
  
  
  
  
  11.  }
    12. 
  
  
  
  
  
  12.  
    13. 
  
  
  
  
  
  13.  public IEnumerable<string> GatherOrderErrors(IEnumerable<Product> products, Customer customer)
    14. 
  
  
  
  
  
  14.  {
    15. 
  
  
  
  
  
  15.  // do work
    16. 
  
  
  
  
  
  16.  }
    17. 
  
  
  
  
  
  17. }
    18. 
  
  
  
  
  
  18.  
    19. 
  
  
  
  
  
  19. public class CustomerRegistrationService
    20. 
  
  
  
  
  
  20. {
    21. 
  
  
  
  
  
  21.  public void Register(Customer customer)
    22. 
  
  
  
  
  
  22.  {
    23. 
  
  
  
  
  
  23.  // do work
    24. 
  
  
  
  
  
  24.  }
    25. 
  
  
  
  
  
  25.  
    26. 
  
  
  
  
  
  26.  public void ForgotPassword(Customer customer)
    27. 
  
  
  
  
  
  27.  {
    28. 
  
  
  
  
  
  28.  // do work
    29. 
  
  
  
  
  
  29.  }
    30. 
  
  
  
  
  
  30. }
    31.

 

代碼重構第28天：爲布爾方法命名

今天的重構不是來自於Fowler的重構目錄。若是誰知道這項「重構」的確切出處，請告訴我。

固然，你也能夠說這並非一個真正的重構，由於方法實際上改變了，但這是一個灰色地帶，能夠開放討論。一個擁有大量布爾類型參數的方法將很快變得沒法控制，產生難以預期的行爲。參數的數量將決定分解的方法的數量。來看看該重構是如何開始的：

 
 
 
 
 
    
  
  
  
  
  
  1. public class BankAccount
    2. 
  
  
  
  
  
  2. {
    3. 
  
  
  
  
  
  3.  public void CreateAccount(Customer customer, bool withChecking, bool withSavings, bool withStocks)
    4. 
  
  
  
  
  
  4.  {
    5. 
  
  
  
  
  
  5.  // do work
    6. 
  
  
  
  
  
  6.  }
    7. 
  
  
  
  
  
  7. }
    8.

要想使這樣的代碼運行得更好，咱們能夠經過命名良好的方法暴露布爾參數，並將原始方法更改成private以阻止外部調用。顯然，你可能須要進行大量的代碼轉移，也許重構爲一個Parameter Object 會更有意義。

 
 
 
 
 
    
  
  
  
  
  
  1. public class BankAccount
    2. 
  
  
  
  
  
  2. {
    3. 
  
  
  
  
  
  3.  public void CreateAccountWithChecking(Customer customer)
    4. 
  
  
  
  
  
  4.  {
    5. 
  
  
  
  
  
  5.  CreateAccount(customer, true, false);
    6. 
  
  
  
  
  
  6.  }
    7. 
  
  
  
  
  
  7.  
    8. 
  
  
  
  
  
  8.  public void CreateAccountWithCheckingAndSavings(Customer customer)
    9. 
  
  
  
  
  
  9.  {
    10. 
  
  
  
  
  
  10.  CreateAccount(customer, true, true);
    11. 
  
  
  
  
  
  11.  }
    12. 
  
  
  
  
  
  12.  
    13. 
  
  
  
  
  
  13.  private void CreateAccount(Customer customer, bool withChecking, bool withSavings)
    14. 
  
  
  
  
  
  14.  {
    15. 
  
  
  
  
  
  15.  // do work
    16. 
  
  
  
  
  
  16.  }
    17. 
  
  
  
  
  
  17. }
    18.

 

代碼重構第29天：去除中間人對象

今天的重構來自於Fowler的重構目錄。

有時你的代碼裏可能會存在一些「Phantom」或「Ghost」類，Fowler 稱之爲「中間人（Middle Man）」。這些中間人類僅僅簡單地將調用委託給其餘組件，除此以外沒有任何功能。這一層是徹底沒有必要的，咱們能夠不費吹灰之力將其徹底移除。

 
 
 
 
 
    
  
  
  
  
  
  1. public class Consumer
    2. 
  
  
  
  
  
  2. {
    3. 
  
  
  
  
  
  3.  public AccountManager AccountManager { get; set; }
    4. 
  
  
  
  
  
  4.  
    5. 
  
  
  
  
  
  5.  public Consumer(AccountManager accountManager)
    6. 
  
  
  
  
  
  6.  {
    7. 
  
  
  
  
  
  7.  AccountManager = accountManager;
    8. 
  
  
  
  
  
  8.  }
    9. 
  
  
  
  
  
  9.  
    10. 
  
  
  
  
  
  10.  public void Get(int id)
    11. 
  
  
  
  
  
  11.  {
    12. 
  
  
  
  
  
  12.  Account account = AccountManager.GetAccount(id);
    13. 
  
  
  
  
  
  13.  }
    14. 
  
  
  
  
  
  14. }
    15. 
  
  
  
  
  
  15.  
    16. 
  
  
  
  
  
  16. public class AccountManager
    17. 
  
  
  
  
  
  17. {
    18. 
  
  
  
  
  
  18.  public AccountDataProvider DataProvider { get; set; }
    19. 
  
  
  
  
  
  19.  
    20. 
  
  
  
  
  
  20.  public AccountManager(AccountDataProvider dataProvider)
    21. 
  
  
  
  
  
  21.  {
    22. 
  
  
  
  
  
  22.  DataProvider = dataProvider;
    23. 
  
  
  
  
  
  23.  }
    24. 
  
  
  
  
  
  24.  
    25. 
  
  
  
  
  
  25.  public Account GetAccount(int id)
    26. 
  
  
  
  
  
  26.  {
    27. 
  
  
  
  
  
  27.  return DataProvider.GetAccount(id);
    28. 
  
  
  
  
  
  28.  }
    29. 
  
  
  
  
  
  29. }
    30. 
  
  
  
  
  
  30.  
    31. 
  
  
  
  
  
  31. public class AccountDataProvider
    32. 
  
  
  
  
  
  32. {
    33. 
  
  
  
  
  
  33.  public Account GetAccount
    34.
相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程