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