類組 合 還 是 類繼 承？
假設 我 們 有一 張 表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類 然後每個畫面的info 類...
物件導向 類的組合
組合 將乙個類的物件封裝到另乙個類的物件的屬性中 乙個類的物件是另乙個類的物件的屬性 就叫組合 例如 圓形類的物件是圓環類物件的 outer 屬性的值 計算圓形相關資料的公式只和 circle 類在一起 其餘的用到公式的地方都是通過 circle 類來使用的 公式與其他類之間的關係是乙個 松耦合 的...
物件導向 類的繼承
1 派生類物件的構造與析構 建立派生類物件的時候首先呼叫基類的建構函式初始化基類成員，隨後才呼叫派生類建構函式 派生類物件的析構過程首先是呼叫派生類的析構函式，再呼叫基類的析構函式 2 多重繼承 b c都繼承於a，而d繼承於b和c 多重繼承的兩義性 當d的物件呼叫a中的成員時就會產生兩義性 d b ...