通過實現TableView來理解IOS編程

先說點題外話。我們在日常做和IOS的UI相關的工作的時候，有一個組件的使用頻率非常高--UITabelView。于是就要求我們對 UITableView的每一個函數接口，每一個屬性都了如指掌，只有這樣在使用UITableView的時候，我們才能游刃有余的處理各種需求。不然做出來的東西，很多時候只是功能實現了，但是程序效率和代碼可維護性都比較差。舉個例子，比如在tableView頭部要顯示一段文字。我見過的最啰嗦的解決方案是這樣的：

1. 子類化一個UIViewController
2. 將根View設置成一個UIScrollView
3. 把頭部的Label和TableView加在ScrollView上面
4. 開始各種調整ScrollView和TableView的delegate調用函數里面的參數，讓Label能隨著TableView滑動

其實如果你熟悉UITableView，那么你幾句話就可以搞定

   UILabel* label = [UILabel alloc] initWithFrame:CGRectMake(0, 0, CGRectGetWidth(self.view.frame), 40);
    label.text = @"就是一段文字嘛，干嘛大動干戈";
    tableVIew.tableHeaderView = label;

所謂工欲善其事必先利器，編程語言和各種庫其實本質上就是工具而已。你要想用這些工具來實現產品和Leader提出的各種需求。當然，不止是功能上的實現，還包括程序效率，代碼質量。特別想著重強調一下代碼質量，如果你不想后面維護自己的代碼就像噩夢一樣，如果你不想一旦新來一個需求就得對代碼大刀闊斧的傷筋動骨，如果你不想給后來者埋坑。那么最好就多注意一下。

這里的代碼質量并不是簡簡單單的指代碼寫點注釋了，利用Xcode提供的一些像pragam或者#warning來解釋代碼。《編寫可閱讀代碼的藝術》還有其他一些編程的書籍也都說道，真正高質量的代碼，是不需要注釋的。一個好的代碼從邏輯上和結構上都是清晰的。我看到很多很難維護的代碼都是因為邏輯結構混亂，和設計模式濫用導致的程序結構紊亂。分析其原因，就會發現很多時候，是因為寫代碼的人對所使用的工具（主要是objc和UIKit）不是非常熟悉，于是就寫了很多湊出來的臨時方案，簡單的實現了功能。表面看起來挺好的，但是實際上代碼已經外強中，骨子里都亂了。后期維護起來會讓人痛不欲生。

了解一下UITableView的一些詳細的技術細節甚至是UIKit的一些技術細節對于我們寫出比較好的代碼，比較好的實現任務是很有必要的。我們通過實現自己的TableView來反觀UIKit的UITableView，來加深我們對UITableView和UIKit的理解。在這個過程中，我們會碰到非常多非常細節的問題，而這些正是我們需要注意并且掌握的。

同時，個人一直覺得對于搞IOS開發來說自己實現一遍TableView就像是一種成人禮一樣。你能夠通過實現一個UITableView來深入的理解UIKit的一些技術細節，對IOS UI編程所使用到的工具，有比較深入的了解。這樣，寫程序的時候才不會捉襟見肘。

言歸正傳。開始實現一個TableView。

項目主頁：http://www.baiduhome.net/lib/view/home/1419994904734