類組合還
是類繼承？假設我
們有一張表a，有多個畫面用到。比如10個畫面用到。由於每個畫面功能不一
樣，但a表的大多數字段所以欄位都是共用的。
這種情況下，怎麼寫自己的info
類呢？大概有3種方案
方案1：每個畫面都寫乙個自己的info類
。方案2：先寫乙個表a的info類
，然後每個畫面的info
類裡面加乙個表a的info類作
為屬性。也就是
類組合。
方案3：先寫乙個表a的info類
，然後每個畫面的info類都
繼承於表a的info
類。也就是
類繼承。
我們稍微分析一下，方案1首先被淘汰掉，因為代
碼量大，增加了工作量和
維護成本。那方案2和方案3呢？都是面向
物件的思想，究竟哪種好呢？
這還得了解一下
類組合和
類繼承的
優缺點。
■類組合的優
點：
--容器類僅能通過
被包含對
象的介面來對其
進行訪問。
-- 「黑盒」復用，因為
被包含對
象的內部
細節對外是不可見。
-- 封裝性好。
-- 實現
上的相互依賴性比
較小。被包含
物件與容器物件之
間的依賴關係比較少
-- 每乙個類只專
注於一項任務
。 -- 通過獲
取指向其它的具有相同型別的
物件引用，可以在執行期
間動態地定義（
物件的）組合。
■類組
合的缺點：
-- 導致系統
中的物件過
多。 -- 為
了能將多個不同的物件作
為組合塊（composition block）來使用，必須仔
細地對介面
進行定義。
■類繼承的優點：
-- 容易進
行新的實現，因為
其大多數可
繼承而來。
-- 易於修改或擴
展那些被復用的實現。
■類繼承的缺點：
-- 破壞了封裝性，因為這
會將父類
的實現細節暴露給
子類。
-- 「白盒」復用，因為父類
的內部細節對於子類
而言通常是可見的。
-- 當父類的實現
更改時，子類
也不得不會隨之更改。
-- 從父類繼
承來的實現
將不能在執行期
間進行改變。
coad規則
僅當下列的所有標準被滿足時，方可使用繼承：
▲子類表達了「是乙個…的特殊
型別」，而非「是乙個由…所扮演的角色」。
▲子類的乙個例項永遠
不需要轉
化（transmute）為其它
類的乙個物件。
▲子類是對
其父類的職責
（responsibility）進行
擴充套件，而非重寫或
廢除（nullify）。
▲子類沒有對
那些僅作為
乙個工具
類（utility class）的功能進行
擴充套件。 ▲對
於乙個位於實際的
問題域（problem domain）的
類而言，其子
類特指一種角色（role），交易（transaction）或
裝置（device）。 組
合與繼承都是重要的重用方法，在物件導向開
發的早期繼承被
過度使用。
實際上究竟是用組合
還是繼承是要根據
實際情況來判斷的，用
組合的好處多
還是用繼承的好
處多，或者兩者集合起來用。
因此綜合上面的
優缺點，上面的那個例子用繼承好
處多，因
為這個地方只是乙個
單純的一
張表的操作。如果是設計多
張表的話，使用
類組合更好一些，因
為類組合封裝性好，不容易出錯。
這個地方就需要我們具體
問題具體分析了。
物件導向 類組合還是類繼承？
類組 合 還 是 類繼 承？假設 我 們 有一 張 表a，有多個畫面用到。比如10個畫面用到。由於每個畫面功能不一 樣 但a表的大多數字段所以欄位都是共用的。這 種情況下，怎麼寫自己的info 類 呢？大概有3種方案 方案1 每個畫面都寫乙個自己的info類 方案2 先寫乙個表a的info類 然後每...
物件導向 類的組合
組合 將乙個類的物件封裝到另乙個類的物件的屬性中 乙個類的物件是另乙個類的物件的屬性 就叫組合 例如 圓形類的物件是圓環類物件的 outer 屬性的值 計算圓形相關資料的公式只和 circle 類在一起 其餘的用到公式的地方都是通過 circle 類來使用的 公式與其他類之間的關係是乙個 松耦合 的...
物件導向 類的繼承
1 派生類物件的構造與析構 建立派生類物件的時候首先呼叫基類的建構函式初始化基類成員，隨後才呼叫派生類建構函式 派生類物件的析構過程首先是呼叫派生類的析構函式，再呼叫基類的析構函式 2 多重繼承 b c都繼承於a，而d繼承於b和c 多重繼承的兩義性 當d的物件呼叫a中的成員時就會產生兩義性 d b ...