C#作為一個完全面向對象的語言，有個特性很重要但是往往會不重視，而不重視的結果就會造成代碼雜亂難以解讀、維護。這個特性就是封裝。
這里不是大談C#的封裝，我只講一個，關于方法封裝的一些問題。
方法可以說是類或者對象的一些業務邏輯，那在什么情況下需要封裝成方法呢：
1、功能相對獨立
2、多處復用
3、一個方法體過于冗余或者實現邏輯過多
4、公開處理內部數據接口(也可以用屬性)
如果滿足上面的任何一個條件，就可以考慮封成獨立的方法了，這里又涉及到一個概念——重構。好的代碼都是重構出來的，沒有誰能一步登天(起碼我們這些小菜鳥做不到)。代碼的雜亂很大一部分原因是由于作者的思維、邏輯混亂，復雜的問題簡單化了，或者簡單的問題復雜化了。所以重構的第一步是要理清自己的邏輯，邏輯清楚了，算法自然就出來了，接下來做的就是把算法用代碼實現的問題了。
對于重構有個原則：需而為之，不需而不為。重構也不盡然都是好，畢竟一開始的想法很有可能是相當不錯的，如果要推翻，得有充足的理由，所以，重構也是有成本的，很可能又引入一些新的bug也難說。就我個人而言，是個比較喜歡折騰的熊孩子，頂多折騰了半天回到原點，不過折騰多了也會有些門道的。建議大家多折騰，丑話說在前頭，折騰前做好備份~
這里也說一下對方法的要求，當然是整潔的方法要求：
1、短小，盡量不要超過一屏
2、獨立，一個方法只做一件事
3、方法名要見名知意、風格一致，前者讓人一看就知道方法做什么，后者別人可以推斷這個函數的作用
4、參數不要超過3個，超過的話就提取為對象。
