繼承具有如下優點：實現新的類非常容易，因為基類的大部分功能都可以通過繼承關係自動賦予派生類；修改或者擴充套件繼承來的實現非常容易；只要修改父類，派生的類的行為就同時被修改了。初學物件導向程式設計的人會認為繼承真是乙個好東西，是實現復用的最好手段。但是隨著應用的深入就會發現繼承有很多缺點：繼承破壞封裝性。基類的很多內部細節都是對派生類可見的，因此這種復用是「白箱復用」；如果基類的實現發生改變，那麼派生類的實現也將隨之改變。這樣就導致了子類行為的不可預知性；從基類繼承來的實現是無法在執行期動態改變的，因此降低了應用的靈活性。
繼承關係有很多缺點，如果合理使用組合則可以有效的避免這些缺點，使用組合關係將系統對變化的適應力從靜態提公升到動態，而且由於組合將已有物件組合到了新物件中，因此新物件可以呼叫已有物件的功能。由於組合關係中各個物件的內部實現是隱藏的，我們只能通過介面呼叫，因此我們完全可以在執行期用實現了同樣介面的另外乙個物件來代替原物件，從而靈活實現執行期的行為控制。而且使用合成關係有助於保持每個類的職責的單一性，這樣類的層次體系以及類的規模都不太可能增長為不可控制的龐然大物。因此我們優先使用組合而不是繼承。
當然這並不是說繼承是不好的，我們可用的類總是不夠豐富，而使用繼承復用來建立一些實用的類將會比組合來的更快，因此在系統中合理的搭配使用繼承和組合將會使你的系統強大而又牢固。
為什麼要優先使用組合 而不是繼承？
繼承具有如下優點 實現新的類非常容易，因為基類的大部分功能都可以通過繼承關係自動賦予派生類 修改或者擴充套件繼承來的實現非常容易 只要修改父類，派生的類的行為就同時被修改了。初學物件導向程式設計的人會認為繼承真是乙個好東西，是實 現復用的最好手段。但是隨著應用的深入就會發現繼承有很多缺點 繼承破壞封...
為什麼是裝飾模式而不是繼承
對於是否需要快取算乙個需求的話 兩種情況 讀取的流的型別是了另乙個需求 兩種情況 輸入還是輸出又是乙個需求如果採用繼承的話 兩種情況 需要的類有 帶快取 位元組型 輸入流 帶快取 位元組型 輸出流 帶快取 字元型 輸入流 帶快取 字元型 輸出流 不帶快取 位元組型 輸入流 不帶快取 位元組型 輸出流...
組合而不是繼承，單一職責
今天在寫c 程式的時候，有乙個使用了三年多的模型，大概是這樣的 有乙個介面捕獲需要主視窗的滑鼠事件的時候，那麼他就需要從imouseevent繼承介面,然後像registerevent imouseevent event 註冊，如果有滑鼠事件，主視窗會通過呼叫虛函式來通知這個介面 我們一般的 是這樣...