優(yōu)先考慮組合／聚合，而不是繼承

代碼的演進(jìn)過程

針對(duì)《設(shè)置》和《發(fā)現(xiàn)》中table view的代碼邏輯
起初我是這樣寫的

起初

后來我是這樣寫的

后來

現(xiàn)在我是這樣寫的

現(xiàn)在

為何要這樣做

大家都知道面向?qū)ο笾欣^承的各種優(yōu)點(diǎn)，所以選擇了使用繼承（不多說）
但是繼承相比較組合依然存在缺點(diǎn)

• 單一繼承
• 不夠靈活
• 耦合嚴(yán)重
• 代碼量大
• 破壞封裝
• 靜態(tài)類型

題外話

從上面代碼的演變可以看到table view的很多代理方法都是相同的邏輯，并不是我們需要關(guān)心的。
非常贊同@巍哥說的view controller中占據(jù)篇幅的并不是table view的代理，而是數(shù)據(jù)的構(gòu)建。
所以，我才覺得更應(yīng)該把table view的代理拿到外面，而把大家關(guān)心的數(shù)據(jù)構(gòu)建保留在view controller中。