类组 合 还 是 类继 承？
假设 我 们 有一 张 表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）。
组 合与 继 承都是重要的重用方法，在面向 对 象开 发 的早期 继 承被 过 度使用。 实际 上究竟是用 组 合 还 是 继 承是要根据 实际 情况来判断的，用 组 合的好 处 多 还 是用 继 承的好 处 多，或者两者集合起来用。
因此综 合上面的 优 缺点，上面的那个例子用 继 承好 处 多，因 为这 个地方只是一个 单纯 的一 张 表的操作。如果是 设计 多 张 表的 话 ，使用 类组 合更好一些，因 为类组 合封装性好，不容易出 错 。 这 个地方就需要我 们 具体 问题 具体分析了。
本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/hantiannan/archive/2009/09/12/4546348.aspx