本文專門為初學者而寫，因為很多初學者可能還不了解公共操作類的作用和封裝技巧，大部分有經驗的程序員都會把自己所碰到的技術問題整理封裝成類，這就是公共操作類。公共操作類往往具有一些通用性，也可能專門解決某些棘手問題。公共操作類是應用程序框架的核心，主要目標是解決大部分技術問題。我將在本文介紹封裝公共操作類的要點，供初學者參考。
開發公共操作類的原因
很多初學者會奇怪，.Net Framework提供的API相當易用，為何還要多此一舉，進行一層封裝呢。下面列舉封裝公共操作類的一些動機。
.Net Framework API太過龐大
想想看.Net Framework包含多少個程序集？每個程序集包含多少個命名空間？每個命名空間包含多少個類？每個類包含多少個屬性和方法？在如此龐大的代碼海洋中游泳，你沒有一艘船怎么能行。
現在給你一個任務，需要實現一個文件上傳功能，但你從來沒有做過，你會怎么辦？由於你不清楚.Net哪個程序集包含這個功能，更不知道使用哪幾個類的方法組合可以完成這個任務，所以必須查資料，很少有人能直接在VS上自己把它摸索出來。
你會進行以下步驟：
- 百度（為啥不用Google,打不開啊，你不會因為一個簡單問題就翻牆吧，不過很多生僻和棘手的問題，百度和國產搜索引擎都靠不住，只有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/