結合設計模式說說類的設計


學習設計模式有一段時間了,現想小結一下,說說我對類的設計的一些常用法則的理解。

 

一,SOLID法則

Single responsibility principle

每個類僅僅承擔一個具體的任務。特別是那些明顯不屬於類的功能,應該封裝到新的類里去。界面和邏輯的分離就是個很好的例子。

Open/Closed principle

軟件開發必須考慮可擴展性,但是擴展不能更改現有的代碼,否則可能更引起大范圍的連鎖反應。設計類的時候,可以通過抽象來隔離變化,並通過繼承來實現變化。

Liskov substitution principle

如果派生類B公有繼承了基類A,即類B是類A的子類型,那么子類型就能夠替換掉父類型,而且這種替換關系不可逆。正是這種替換關系使得父類可以被復用。注意並不是所有的"is a"關系都適用里氏代換,比方說:足球和美式足球都叫足球,但是編程的時候,美式足球不能認足球為父類,因為足球只能用腳,而美式足球可以用手。

Interface segregation principle

接口類設計要盡量簡練,只需要包含必要的功能即可。比方說:可以簡練到只包含一個純虛函數。

Dependency inversion principle

針對接口編程,而不是針對實現編程。這樣使用接口的類就和接口的具體實現分開了,雙方都可以靈活自如,只要遵守接口約定即可。實踐中純虛函數就是接口,針對接口編程就是重寫純虛函數。

 

二,IC法則(為方便記憶我個人取的名字):

Encapsulation/Information hiding

類的內部數據對外不可見,而只能通過其自身行為改變。封裝不僅僅是數據隱藏,也可以是變化點的隱藏。很多設計模式都使用封裝來創建接口類,在接口類一側的修改不會影響到另一側,從而松開這兩側的耦合,增強了軟件的復用。如果被隱藏的具體被調用類報錯,只能修改被調用類,而不能在調用類中繞開錯誤。

Composition

優先使用組合而不是繼承。繼承是在編譯時刻靜態定義的,而組合可以在運行時刻動態選擇。繼承對子類揭示了其父類的實現細節,這就破壞了封裝,而組合要求對象遵守共同的接口約定,並不破壞封裝。繼承中的子類和父類有緊密的依賴關系,而組合由於多了一層接口並不相互依賴。過多的繼承可能導致類爆炸,不利於后期的維護,而組合可以防止類爆炸,減少繼承層次。

 

 

參考文獻:

GOF

《設計模式精解》

《大話設計模式》

 

 

----------------------------------------------------

另,今晚歐錦賽德國VS意大利,大膽預測德國2:0取勝,一雪06年世界杯半決賽之恥。


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM