結合設計模式說說如何設計類
一，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
《設計模式精解》
《大話設計模式》
原文鏈接：http://www.cnblogs.com/xfu123/archive/2012/06/28/2558377.html
【編輯推薦】
