應用程式框架實戰十二：公共操作類開發技巧（初學者必讀）
本文專門為初學者而寫，因為很多初學者可能還不瞭解公共操作類的作用和封裝技巧，大部分有經驗的程式設計師都會把自己所碰到的技術問題整理封裝成類，這就是公共操作類。公共操作類往往具有一些通用性，也可能專門解決某些棘手問題。公共操作類是應用程式框架的核心，主要目標是解決大部分技術問題。我將在本文介紹封裝公共操作類的要點，供初學者參考。
開發公共操作類的原因
很多初學者會奇怪，.Net Framework提供的API相當易用，為何還要多此一舉，進行一層封裝呢。下面列舉封裝公共操作類的一些動機。
.Net Framework API太過龐大
想想看.Net Framework包含多少個程式集？每個程式集包含多少個名稱空間？每個名稱空間包含多少個類？每個類包含多少個屬性和方法？在如此龐大的程式碼海洋中游泳，你沒有一艘船怎麼能行。
現在給你一個任務，需要實現一個檔案上傳功能，但你從來沒有做過，你會怎麼辦？由於你不清楚.Net哪個程式集包含這個功能，更不知道使用哪幾個類的方法組合可以完成這個任務，所以必須查資料，很少有人能直接在VS上自己把它摸索出來。
你會進行以下步驟：
- 百度（為啥不用Google,打不開啊，你不會因為一個簡單問題就FQ吧，不過很多生僻和棘手的問題，百度和國產搜尋引擎都靠不住，只有Google才能給你指出方向）
- 進入搜尋出來的前幾篇文章，找到需要的程式碼。
- 複製到專案中除錯。萬一你運氣好，一下就通過了，這時候就可以收工，運氣不好繼續百度。
可以看出，當你碰到一個沒做過的功能一定需要查資料，因為.Net類庫太大了，你不可能先把所有的東西學會再進行開發。觀察以上步驟，可以發現你的開發速度和找到正確程式碼的時間成正比。換句話說，如果你找東西的時候，關鍵詞沒有輸入正確，或者東西本身很生僻，你就會拿出大把的時間持續在網上衝浪。
獲得更好的程式碼提示支援，幫助記憶API
.Net開發門檻很低，其中一個重要原因是VS非常強大，特別是程式碼提示功能。
如果現在叫你用記事本來開發一個模組，結果會怎樣？除了開發效率低得嚇人，恐怕寫出來的程式碼編譯都難通過，關鍵一點是你無法精確的記住API。很少有人能精確的記住他使用的每個名稱空間，類名，方法名等，大部分人都只有一個印象，可能記得住名稱空間和類名的一部分，依賴VS強大的程式碼提示功能，上下移動以定位正確的API。
這是一個非常強大的特性，但是由於.Net Framework類庫過於龐大，以及第三方框架的API也非常複雜，從而削弱了程式碼提示的能力，細長的程式碼提示滾動條讓你眼花繚亂。
另一方面，我們平時使用的API數量非常有限，只佔總數1%不到，把這些常用的API封裝到自己的名稱空間中 ，可以大大加強程式碼提示能力，從而幫助你記憶API, 憑藉一點模糊的記憶，根據程式碼提示進行開發。
獲得更好的程式碼複用能力
現在來看程式碼的複用性。
過了三五個月，已經是下一個專案開始了，你又需要進行檔案上傳。這時候，你會意識到之前做過這個功能，但記憶已經很模糊了。記憶很模糊的原因除了時間比較長了以外，還有個原因是你當時直接從網上覆制過來，根本沒有理解。你現在一個選擇是再次百度，但很多時候你不願意這樣幹，可能是上次找東西不大順利，花了大半個小時才找到。也可能是你上次找東西的時候捱了病毒，現在心裡還有陰影。另一個原因是你覺得之前的程式碼一直在使用，比較穩定，所以你決定去老專案裡面把這段程式碼揪出來。然後你開啟已經混亂不堪的專案，四處東翻西找，終於找到，把它複製過來。
可以看到，沒有經過封裝，就只能複製程式碼。這個過程費力，耗時，完全沒有必要。
有經驗的程式設計師，雖然也要搜尋程式碼，但會多幾個步驟，從網上找到的程式碼就算能用，也還要進行整理、封裝以及單元測試。完成程式碼封裝以後，就可以直接呼叫，不再東張西望。
獲得更好的可維護性
將常用程式碼封裝後，所有程式碼呼叫點都指向同一個地方，如果發現BUG或者新增功能，只需要修改一個地方。
簡化API呼叫
有些程式碼確實很常用，記得很牢，但是太囉嗦，可以封裝之後建立一套更簡易的API，以方便呼叫。
更好的管理第三方API
對第三方API進行集中管理，特別是方便切換。
公共操作類開發技巧
技巧一：儘量使用靜態方法
公共操作類應該儘量使用靜態方法，因為這樣呼叫起來比較簡單，誰也不希望為了一個很簡單的操作，還要先例項化物件。
不過如果你需要考慮切換實現，或者需要多次呼叫，就不應該使用靜態方法。
技巧二：封裝囉嗦程式碼，一行搞定
能一行程式碼寫完，誰願意寫兩行？有些操作雖然簡單，但需要寫好幾句，這時候你要考慮封裝起來，呼叫時僅一行搞定，從而簡化API。
技巧三：粗粒度
你不能按.Net Framework那樣細的粒度來封裝常用類，因為這些很快會導致大量的類，從而讓你無法迅速想到你需要的功能在哪個類中。同時也會顯著削弱程式碼提示的能力。
公共操作類是.Net Framework和第三方框架上方的一層外觀，提供一個粗粒度的視角讓你呼叫API更簡單。
技巧四：把記不住的都封裝起來
如果你的記憶力非常糟糕，很多常用的都記不清楚，沒有關係，封裝到你的公共操作類中，它會幫助你記憶，因為你以後只需要在程式碼提示上移動了。
技巧五：形成清晰的API
你必須為你要封裝的功能取一個語義清晰的類名，以及方法名。如果你為了圖快，胡亂取一個，那麼下一次你可能在雜亂無章的公共操作類中迷失方向，因為你不知道哪個類和方法完成你要的功能。
公共操作類，一般會被冠以Helper字尾，比如ConvertHelper，但這不是必須的，我發現用更短的名稱會讓呼叫時更爽。我後面使用Convert，不過這與系統類名衝突，雖然在不同的名稱空間中，Resharpe會提示多個名稱空間，這讓我很不爽，所以我將Convert又縮短了一點，叫Conv。一般來講，除非沒有其它選擇，否則命名儘量不要使用縮寫，這樣會導致很晦澀的API。我在公共操作類中使用一些縮寫，是因為我非常熟悉，並且其它人也比較容易理解，另外也確實是走投無路，不想使用長名稱。
把可能發生變化的部分抽取出來，作為引數傳進去。
技巧六：僅要求必須的引數
為了讓呼叫程式碼更簡單，把不是必須傳遞的引數儘量隱藏到公共類中，或提供引數預設值，這也是封裝的關鍵。有時候哪怕減少一個引數，都會讓工作量減輕很多，因為這個方法可能被大量的呼叫。
技巧七：提供適量的方法過載
為了讓某些功能用起來更靈活，需要提供方法過載。應該針對最常用的幾個操作提供過載，提供太多過載會導致複雜性。
技巧八：新增準確而清晰的註釋
公共操作類高度依賴程式碼提示功能，所以準確而清晰的註釋，就顯得很有必要了。
你雖然盡了最大努力來設計清晰的類名和方法簽名，但別人不一定理解，另外時間長了你自己都會犯傻。這裡有一個重要原因是我們老中英文好的畢竟是少數，大部分人還是和我一樣愛國，英文爛得一塌糊塗，所以哪怕很用心的設計API，還是個四不像。依靠準確的註釋來彌補這個不足是非常有用的。
對於複雜的功能，在註釋上直接提供範例，可以讓你在呼叫時更輕鬆。
技巧九：抽取第三方API介面，以實現切換
為了不被第三方框架捆綁，需要在第三方框架上方建立一層封裝。
一般做法是根據你的需求，抽取一個或多個介面，用第三方API實現這些介面。專案中只使用自己的API，第三方框架的API就不會侵入系統，這樣就可以在必要時切換到另一個三方框架。
不是所有的第三方API都需要封裝，如果它不侵入你的系統，就沒有太大封裝的必要，比如依賴注入框架。還有些框架不是很容易封裝，你可能要使用它的大量API，另外它的API包含大量像Lambda這樣的東西，你封裝起來就很痛苦了，如果這種框架穩定性比較高，一般不輕易更換，直接呼叫也沒有多大問題。
公共操作類開發注意事項
警惕過度封裝
當你逐步習慣了自己封裝API以後，你可能會把系統大量的API封裝進來，從而導致過度封裝。
怎樣才算過度封裝？這其實是一個主觀判斷，我可能覺得你過度封裝了，但你自己卻認為相當好用，這是因為我兩的習慣和風格不同所致。對於這點，不用理會其它人怎麼看，只要你自己用得爽就對了，當然你如果帶團隊，你的團隊成員如果用起很痛苦，你可能就得改改了。
如果你自己都發現框架越來越笨重，每次在程式碼提示上下移動要花很長時間，這就是一個訊號，把用不上的統統幹掉，你的框架也需要經常洗洗澡。
不要忽視簡單功能
並不一定是技術比較困難的才需要封裝，其實簡單的也需要。這一點，哪怕很多老手都會忽視。
要把簡單的東西封裝起來不是一件易事，因為你可能把簡單的東西搞複雜了，換句話說，犯了過度封裝的毛病。但你如果仔細觀察，會發現還是有很多簡單的功能可以更簡化。
我會在後面釋出一些有用的公共操作類例項進行詳細說明。
結語
本篇詳細的介紹了公共操作類的基本技巧，當你以後碰到任何一個技術問題時，應該首先想到的就是封裝成公共操作類，以供日後複用。
對第三方硬體裝置介面和應用平臺介面的封裝，也可以歸納到公共操作類中，只是屬於業務範疇。
本系列是介紹應用程式框架整體的，而公共操作類只是其中一個組成部分，雖然它佔據了大半江山。為了不喧賓奪主，把應用程式框架整體沖淡，我準備單獨開一個系列來專門介紹公共操作類，命名為《Util應用程式框架公共操作類》，到時我會把一些常用的公共操作類奉獻給大家。
.Net應用程式框架交流QQ群: 386092459，歡迎有興趣的朋友加入討論。
謝謝大家的持續關注，我的部落格地址：http://www.cnblogs.com/xiadao521/