參考資料

• 軟件設計雜談

設計模式

設計模式。

參考資料

• 蔡學鏞架構設計方法

常用的 Javascript 設計模式

參考資料

• 常用的 Javascript 設計模式

面向對象程序設計

參考資料

• S.O.L.I.D：面向對象設計的頭 5 大原則

繼承

繼承從代碼復用的角度來說，特別好用，也特別容易被濫用和被錯用。不恰當地使用繼承導致的最大的一個特征就是高耦合。 在這里我要補充一點，耦合是一個特征，雖然大部分情況是缺陷的特征，但是當耦合成為需求的時候，耦合就不是缺陷了。耦合成為需求的例子在后面會提到。

總結

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

參考資料

• 跳出面向對象思想(一) 繼承

多態(tài)

總結

多態(tài)在面向對象程序中的應用相當廣泛，只要有繼承的地方，或多或少都會用到多態(tài)。然而多態(tài)比起繼承來，更容易被不明不白地使用，一切看起來都那么順其自然。在客戶程序員這邊，一般是只要多態(tài)是可行方案的一種，到最后大部分都會采用多態(tài)的方案來解決問題。

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

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

參考資料

• 跳出面向對象思想(二) 多態(tài)

封裝

面向接口編程

IOP。