我的爛Code重構之路(二)-泛型方法

前篇提到，以功能分解開發的缺點，但功能分解的開發方式也有其優點，那就是程式碼壞味道(Code Bad Smell)特別的重，就像是吃臭豆腐，味道難然不佳，但如果好好認真盡快的處理，變成一道美味的佳餚也並無可能。

壞味道-發現相似的邏輯

在撰寫函數式Class時，你應該有個直覺，那就是很容易發現相似的邏輯。

舉個簡單的例子，我想整合使用臺北市政府資料開發平台上的資料：

我想整合停車與自行車兩項資訊，資料源到手後，接著就會很習慣的開發寫Code：

  public static class DataTaipei
  {
      public static ParkResult GetPark()
      {
          // 發出停車場請求
          // 取得停車場結果
          return new ParkResult();
      }

      public static YouBikeResult GetYouBike()
      {
          // 發出YouBike請求
          // 取得YouBike結果
          return new YouBikeResult();
      }
  }

我故意不寫程式碼，只要是眼睛沒瞎的都應該知道我想要重構哪部分，說是簡單，但想想實際開發上，可能是第一天寫GetPark方法，第七天才寫GetYouBike方法，兩者中間還有數百、數千行的其他程式碼，你要怎麼聞到壞味道？如果是團隊分工開發，那又更不容易發現。

當然，今天的情境上全部都是我的爛Code，所以那味道很嗆鼻。再說一次，在對這程式碼還有印象、有記憶之前進行重構。你就能保有，怎麼今天寫的這段程式碼好像在那裡看過的感覺，當有這種感覺時，記得停下腳步想想，可能就是一次重構為美味佳餚的機會。

GetPark與GetYouBike的可能實作程式碼：

  public static ParkResult GetPark()
  {
      string serverUrl = "http://data.taipei/";
      string credential = "opendata/datalist/apiAccess?scope=resourceAquire&rid=9ba187c9-b07e-40bc-9aa5-8d3c9f1aad63";
      ParkResult result = null;
      
      HttpClient client = new HttpClient();
      client.BaseAddress = new Uri(serverUrl);
      client.DefaultRequestHeaders.Accept.Clear();
      client.DefaultRequestHeaders.Accept.Add(new MediaTypeWithQualityHeaderValue("application/json"));
      
      HttpResponseMessage response = client.GetAsync(credential).Result;
      if (response.IsSuccessStatusCode)
      {
          result = response.Content.ReadAsAsync<ParkResult>().Result;
      }

      return result;
  }

  public static YouBikeResult GetYouBike()
  {
      string serverUrl = "http://data.taipei/";
      string credential = "opendata/datalist/apiAccess?scope=resourceAquire&rid=ddb80380-f1b3-4f8e-8016-7ed9cba571d5";
      YouBikeResult result = null;

      HttpClient client = new HttpClient();
      client.BaseAddress = new Uri(serverUrl);
      client.DefaultRequestHeaders.Accept.Clear();
      client.DefaultRequestHeaders.Accept.Add(new MediaTypeWithQualityHeaderValue("application/json"));

      HttpResponseMessage response = client.GetAsync(credential).Result;
      if (response.IsSuccessStatusCode)
      {
          result = response.Content.ReadAsAsync<YouBikeResult>().Result;
      }

      return result;
  }

泛型方法

就程式碼發展的歷程而言，這樣的結果很正確，兩個方法互不干擾並獨立作業，就程式碼的職責來看，每個方法只是對自己負責的URI資源做存取也很單一，並無不妥地方。就算不重構，也不會構成什麼大問題。

但我就是嬌情，就是想改，以下使用泛型方法重構之後的程式碼：

        private static HttpClient Request(string serverUrl)
        {
            HttpClient client = new HttpClient();
            client.BaseAddress = new Uri(serverUrl);
            client.DefaultRequestHeaders.Accept.Clear();
            client.DefaultRequestHeaders.Accept.Add(new MediaTypeWithQualityHeaderValue("application/json"));
            return client;
        }

        private static T APIResponse<T>(string serverUrl, string credential, T responseType)
        {
            using (HttpClient client = Request(serverUrl))
            {
                HttpResponseMessage response = client.GetAsync(credential).Result;

                if (response.IsSuccessStatusCode)
                {
                    responseType = response.Content.ReadAsAsync<T>().Result;
                }
            }
            return responseType;
        }

可以看到二點，一、將重覆程式碼(HttpClient部分)抽離為一個獨立的函數，以增加可用性。二、我將相同邏輯的處理抽離並使用泛型技巧，以解決不同型別的問題。

接下來看看使用這些方法後的程式碼：

 const string serverUrl = "http://data.taipei/";
 public static ParkResult GetPark()
 {
     string credential = "opendata/datalist/apiAccess?scope=resourceAquire&rid=ddb80380-f1b3-4f8e-8016-7ed9cba571d5";
     ParkResult result = null;
     result = APIResponse<ParkResult>(serverUrl, credential, result);

     return result;
 }

 public static YouBikeResult GetYouBike()
 {
     string credential = "opendata/datalist/apiAccess?scope=resourceAquire&rid=ddb80380-f1b3-4f8e-8016-7ed9cba571d5";
     YouBikeResult result = null;
     result = APIResponse<YouBikeResult>(serverUrl, credential, result);
     
    return result;
 }

你可以發現，函數裡的程式碼變少變得更簡單了。未來想要呼叫任一個臺北市政府資料開發平台API都可以利用我重構好的泛型方法。

KingKong Bruce記事

網頁