優先考慮組合／聚合，而不是繼承
代碼的演進過程
針對《設置》和《發現》中table view的代碼邏輯
起初我是這樣寫的
起初
后來我是這樣寫的
后來
現在我是這樣寫的
現在
為何要這樣做
大家都知道面向對象中繼承的各種優點，所以選擇了使用繼承（不多說）
但是繼承相比較組合依然存在缺點
- 單一繼承
- 不夠靈活
- 耦合嚴重
- 代碼量大
- 破壞封裝
- 靜態類型
題外話
從上面代碼的演變可以看到table view的很多代理方法都是相同的邏輯，并不是我們需要關心的。
非常贊同@巍哥說的view controller中占據篇幅的并不是table view的代理，而是數據的構建。
所以，我才覺得更應該把table view的代理拿到外面，而把大家關心的數據構建保留在view controller中。
