繼承從代碼復(fù)用的角度來說，特別好用，也特別容易被濫用和被錯(cuò)用。不恰當(dāng)?shù)厥褂美^承導(dǎo)致的最大的一個(gè)特征就是高耦合。在這里我要補(bǔ)充一點(diǎn)，耦合是一個(gè)特征，雖然大部分情況是缺陷的特征，但是當(dāng)耦合成為需求的時(shí)候，耦合就不是缺陷了。耦合成為需求的例子在后面會(huì)提到。

總結(jié)

可見，代碼復(fù)用也是分類別的，如果當(dāng)初只是出于代碼復(fù)用的目的而不區(qū)分類別和場景，就采用繼承是不恰當(dāng)?shù)?。我們?yīng)當(dāng)考慮以上3點(diǎn)要素看是否符合，才能決定是否使用繼承。就目前大多數(shù)的開發(fā)任務(wù)來看，繼承出現(xiàn)的場景不多，主要還是代碼復(fù)用的場景比較多，然而通過組合去進(jìn)行代碼復(fù)用顯得要比繼承麻煩一些，因?yàn)榻M合要求你有更強(qiáng)的抽象能力，繼承則比較符合直覺。然而從未來可能產(chǎn)生的需求變化和維護(hù)成本來看，使用組合其實(shí)是很值得的。另外，當(dāng)你發(fā)現(xiàn)你的繼承超過2層的時(shí)候，你就要好好考慮是否這個(gè)繼承的方案了，第三層繼承正是濫用的開端。確定有必要之后，再進(jìn)行更多層次的繼承。

參考資料

跳出面向?qū)ο笏枷?一) 繼承

多態(tài)

總結(jié)

多態(tài)在面向?qū)ο蟪绦蛑械膽?yīng)用相當(dāng)廣泛，只要有繼承的地方，或多或少都會(huì)用到多態(tài)。然而多態(tài)比起繼承來，更容易被不明不白地使用，一切看起來都那么順其自然。在客戶程序員這邊，一般是只要多態(tài)是可行方案的一種，到最后大部分都會(huì)采用多態(tài)的方案來解決問題。

然而多態(tài)正如它名字中所暗示的，它有非常大的潛在可能引入不屬于對(duì)象初衷的邏輯，巨大的靈活性也導(dǎo)致客戶程序員在面對(duì)問題的時(shí)候不太愿意采用其他相對(duì)更優(yōu)的方案，比如 IOP。在決定是否采用多態(tài)時(shí)，我們要有一個(gè)清晰的角色概念，做好角色細(xì)分，不要角色混亂。該是攔截器的，就給他制定一個(gè)攔截器接口，由另一個(gè)對(duì)象（邏輯上的另一個(gè)對(duì)象，當(dāng)然也可以是自己）去實(shí)現(xiàn)接口里的方法集。不要讓一個(gè)對(duì)象在邏輯上既是攔截器又是業(yè)務(wù)模塊。這樣才方便未來的維護(hù)。另外也要注意被覆重方法的作用，如果只是單純?yōu)榱颂峁└割愃枰闹虚g數(shù)據(jù)的，一律都用 IOP，這是比直接采用多態(tài)更優(yōu)的方案。

IOP 能夠帶來的好處當(dāng)然不止文中寫到的這些，它在其他場合也有非常好的應(yīng)用，它最主要的好處就在于分離了定義和實(shí)現(xiàn)，并且能夠帶來更高的靈活性，靈活到既可以對(duì)語言過高的自由度有一個(gè)限制，也可以靈活到允許同一接口的不同實(shí)現(xiàn)能夠合理地組合。在架構(gòu)設(shè)計(jì)方面是個(gè)非常重要的思想。

參考資料

跳出面向?qū)ο笏枷?二) 多態(tài)

封裝

面向接口編程

IOP。

上一篇：寫點(diǎn)東西下一篇：服務(wù)器部署