狠狠撸

狠狠撸Share a Scribd company logo
你不必严格遵守这些原则,违背它们也不会被处以宗教刑罚。     但你应当把这些原则看
成警铃,若违背了其中的一条,那么警铃就会响起             ----- Arthur J.Riel
    (1) 所 有 数 据 都 应 该 隐 藏 在 所 在 的 类 的 内 部 。

    (2) 类 的 使 用 者 必 须 依 赖 类 的 共 有 接 口 , 但 类 不 能 依 赖 它 的 使 用 者 。

         (3)       尽       量       减   少       类       的       协   议       中   的       消       息   。

  (4)实现所有类都理解的最基本公有接口[例如,拷贝操作(深拷贝和浅拷贝)、相等性判
断 、 正 确 输 出 内 容 、 从 ASCII 描 述 解 析 等 等 ] 。

    (5) 不 要 把 实 现 细 节 ( 例 如 放 置 共 用 代 码 的 私 有 函 数 ) 放 到 类 的 公 有 接 口 中 。

  如果类的两个方法有一段公共代码,那么就可以创建一个防止这些公共代码的私有函
数                  。

    (6) 不 要 以 用 户 无 法 使 用 或 不 感 兴 趣 的 东 西 扰 乱 类 的 公 有 接 口 。

  (7)类之间应该零耦合,或者只有导出耦合关系。也即,一个类要么同另一个类毫无关
系 , 要 么 只 使 用 另 一 个 类 的 公 有 接 口 中 的 操 作 。

         (8)       类       应       该   只       表       示       一   个       关   键       抽       象   。

  包中的所有类对于同一类性质的变化应该是共同封闭的。         一个变化若对一个包影响,则
将 对 包 中 的 所 有 类 产 生 影 响 , 而 对 其 他 的 包 不 造 成 任 何 影 响 .

         (9)       把       相       关   的   数       据       和   行   为       集       中       放   置   。

  设计者应当留意那些通过 get 之类操作从别的对象中获取数据的对象。这种类型的行为
暗  示  着 这  条    经   验  原  则 被  违  反  了  。

    (10) 把 不 相 关 的 信 息 放 在 另 一 个 类 中 ( 也 即 : 互 不 沟 通 的 行 为 ) 。

               朝       着           稳   定       的       方       向       进       行       依       赖   .


    (11) 确 保 你 为 之 建 模 的 抽 象 概 念 是 类 , 而 不 只 是 对 象 扮 演 的 角 色 。

  (12)在水平方向上尽可能统一地分布系统功能,也即:按照设计,顶层类应当统一地
共           享        工         作        。

  (13)在你的系统中不要创建全能类/对象。对名字包含 Driver、Manager、System、Susystem
的      类   要   特    别    多     加       小         心       。

         规     划       一       个   接   口   而       不       是   实   现       一   个       接   口   。
  (14)对公共接口中定义了大量访问方法的类多加小心。大量访问方法意味着相关数据和
行      为    没    有    集   中    存    放    。

    (15) 对 包 含 太 多 互 不 沟 通 的 行 为 的 类 多 加 小 心 。

  这个问题的另一表现是在你的应用程序中的类的公有接口中创建了很多的 get 和 set 函
数                  。

  (16)在由同用户界面交互的面向对象模型构成的应用 程序中,模型不应该依赖于界面,
界     面   则   应  当   依   赖    于  模   型   。

  (17)尽可能地按照现实世界建模(我们常常为了遵守系统功能分布原则、     避免全能类原则
以 及 集 中 放 置 相 关 数 据 和 行 为 的 原 则 而 违 背 这 条 原 则 )。

            (18)    从     你   的   设       计       中       去   除       不   需   要       的   类   。

    一 般 来 说 , 我 们 会 把 这 个 类 降 级 成 一 个 属 性 。

                   (19)   去       除       系           统           外       的       类       。

  系统外的类的特点是,抽象地看它们只往系统领域发送消息但并不接受系统领域内其
他    类    发   出    的    消    息    。

  (20)不要把操作变成类。质疑任何名字是动词或者派生自动词的类,特别是只有一个有
意义行为的类。  考虑一下那个有意义的行为是否应当迁移到已经存在或者尚未发现的某个类
中                                        。

  (21)我们在创建应用程序的分析模型时常常引入代理类。在设计阶段,我们常会发现很
多    代   理  没  有  用   的  ,  应  当   去  除  。

            (22)      尽   量   减       少       类       的       协   作       者   的       数   量   。

    一 个 类 用 到 的 其 他 类 的 数 目 应 当 尽 量 少 。

    (23) 尽 量 减 少 类 和 协 作 者 之 间 传 递 的 消 息 的 数 量 。

  (24)尽量减少类和协作者之间的协作量,也即:减少类和协作者之间传递的不同消息
的              数           量            。

    (25) 尽 量 减 少 类 的 扇 出 , 也 即 : 减 少 类 定 义 的 消 息 数 和 发 送 的 消 息 数 的 乘 积 。

  (26)如果类包含另一个类的对象,那么包含类应当给被包含的对象发送消息。也即:包
含    关   系  总  是  意   味  着  使  用  关   系  。
    (27) 类 中 定 义 的 大 多 数 方 法 都 应 当 在 大 多 数 时 间 里 使 用 大 多 数 数 据 成 员 。

   (28) 类包含的对象数目不应当超过开发者短期记忆的容量。这个数目常常是 6 。

  当类包含多于 6 个数据成员时,可以把逻辑相关的数据成员划分为一组,然后用一个
新  的 包   含   类  去  包 含  这  一  组 成  员  。

    (29) 让 系 统 功 能 在 窄 而 深 的 继 承 体 系 中 垂 直 分 布 。

  (30)在实现语义约束时,最好根据类定义来实现。这常常会导致类泛滥成灾,在这种情
况 下, 约束 应当 在类 的行 为中 实现 ,通 常是 在构 造函 数中 实现 ,但 不是 必须 如此 。

  (31)在类的构造函数中实现语义约束时,把约束测试放在构造函数领域所允许的尽量
深       的    包    含     层    次     中    。

  (32)约束所依赖的语义信息如果经常改变,那么最好放在一个集中式的第 3 方对象中。

  (33)约束所依赖的语义信息如果很少改变,那么最好分布在约束所涉及的各个类中。

    (34) 类 必 须 知 道 它 包 含 什 么 , 但 是 不 能 知 道 谁 包 含 它 。

   (35) 共享字面范围 ( 也就是被同一个类所包含 ) 的对象相互之间不应当有使用关系。

        (36) 继 承 只 应 被 用 来 为 特 化 层 次 结 构 建 模 。


    (37) 派 生 类 必 须 知 道 基 类 , 基 类 不 应 该 知 道 关 于 它 们 的 派 生 类 的 任 何 信 息 。

    (38) 基 类 中 的 所 有 数 据 都 应 当 是 私 有 的 , 不 要 使 用 保 护 数 据 。

  类的设计者永远都不应该把类的使用者不需要的东西放在公有接口中。

    (39) 在 理 论 上 , 继 承 层 次 体 系 应 当 深 一 点 , 越 深 越 好 。

  (40)在实践中,继承层次体系的深度不应当超出一个普通人的短期记忆能力。一个广为
接      受    的    深    度    值   是     6   。

         (41)   所   有   的   抽   象   类    都   应    当   是    基   类    。

         (42)   所   有   的   基   类   都    应   当    是   抽    象   类    。

    (43) 把 数 据 、 行 为 和 / 或 接 口 的 共 性 尽 可 能 地 放 到 继 承 层 次 体 系 的 高 端 。

  (44)如果两个或更多个类共享公共数据(但没有公共行为),那么应当把公共数据放在一
个 类 中 , 每 个 共 享 这 个 数 据 的 类 都 包 含 这 个 类 。

  (45)如果两个或更多个类有共同的数据和行为(就是方法),那么这些类的每一个都应当
从 一 个 表 示 了 这 些 数 据 和 方 法 的 公 共 基 类 继 承 。

  (46)如果两个或更多个类共享公共接口(指的是消息,而不是方法),那么只有他们需要
被 多 态 地 使 用 时 , 他 们 才 应 当 从 一 个 公 共 基 类 继 承 。

  (47)对对象类型的显示的分情况分析一般是错误的。在大多数这样的情况下,设计者应
当         使       用      多       态       。

  (48)对属性值的显示的分情况分析常常是错误的。类应当解耦合成一个继承层次结构,
每 个 属 性 值 都 被 变 换 成 一 个 派 生 类 。

  (49)不要通过继承关系来为类的动态语义建模。试图用静态语义关系来为动态语义建模
会     导  致   在  运   行  时   切  换   类  型   。

   (50) 不要把类的对象变成派生类。对任何只有一个实例的派生类都要多加小心。

  (51)如果你觉得需要在运行时刻创建新的类,那么退后一步以认清你要创建的是对象。
现   在   , 把  这 些  对  象 概  括 成  一  个 类  。

  (52)在派生类中用空方法(也就是什么也不做的方法)来覆写基类中的方法应当是非法的。



  (53)不要把可选包含同对继承的需要相混淆。把可选包含建模成继承会带来泛滥成灾的
类                                        。

    (54) 在 创 建 继 承 层 次 时 , 试 着 创 建 可 复 用 的 框 架 , 而 不 是 可 复 用 的 组 件 。

  (55)如果你在设计中使用了多重继承,先假设你犯了错误。如果没犯错误,你需要设法
证                     明                  。

  (56)只要在面向对象设计中用到了继承,问自己两个问题:(1)派生类是否是它继承的
那 个 东 西 的 一 个 特 殊 类 型 ? (2) 基 类 是 不 是 派 生 类 的 一 部 分 ?

  (57)如果你在一个面向对象设计中发现了多重继承关系,确保没有哪个基类实际上是
另      一   个   基   类   的   派    生   类   。

  (58)在面向对象设计中如果你需要在包含关系和关联关系间作出选择,请选择包含关
系                                       。

  (59)不要把全局数据或全局函数用于类的对象的薄记工作。应当使用类变量或类方法。
  (60)面向对象设计者不应当让物理设计准则来破坏他们的逻辑设计。但是,在对逻辑设
计 作 出 决 策 的 过 程 中 我 们 经 常 用 到 物 理 设 计 准 则 。

  (61)不要绕开公共接口去修改对象的状态。

More Related Content

Similar to 六十一条面向对象分析设计的经验原则 (10)

DOC
闯补惫补代码编写的30条建议
yiditushe
?
DOC
闯补惫补相关基础知识
yiditushe
?
PDF
翱辞诲启思录02
yiditushe
?
PPT
软件工程 第十一章
浒 刘
?
DOC
闯补惫补面试知识
yiditushe
?
DOC
闯补惫补程序员面试之葵花宝典
yiditushe
?
DOC
闯补惫补面试32题
yiditushe
?
DOC
大公司的闯补惫补面试题集
yiditushe
?
PPT
SCJP ch12
r82093403
?
DOC
颁补蝉蝉补苍诲谤补的初步使用及一些简单的操作
zhubin885
?
闯补惫补代码编写的30条建议
yiditushe
?
闯补惫补相关基础知识
yiditushe
?
翱辞诲启思录02
yiditushe
?
软件工程 第十一章
浒 刘
?
闯补惫补面试知识
yiditushe
?
闯补惫补程序员面试之葵花宝典
yiditushe
?
闯补惫补面试32题
yiditushe
?
大公司的闯补惫补面试题集
yiditushe
?
SCJP ch12
r82093403
?
颁补蝉蝉补苍诲谤补的初步使用及一些简单的操作
zhubin885
?

More from yiditushe (20)

DOC
厂辫谤颈苍驳入门纲要
yiditushe
?
PDF
J Bpm4 1中文用户手册
yiditushe
?
PPT
性能测试实践2
yiditushe
?
PPT
性能测试实践1
yiditushe
?
PPT
性能测试技术
yiditushe
?
PPT
Load runner测试技术
yiditushe
?
PPT
J2 ee性能测试
yiditushe
?
PPT
面向对象的闯蝉培训
yiditushe
?
PDF
贵濒别虫3中文教程
yiditushe
?
PDF
开放源代码的全文检索尝耻肠别苍别
yiditushe
?
PDF
基于分词索引的全文检索技术介绍
yiditushe
?
PDF
Lucene In Action
yiditushe
?
DOC
Lucene2 4学习笔记1
yiditushe
?
DOC
Lucene2 4 Demo
yiditushe
?
PDF
Lucene 全文检索实践
yiditushe
?
PDF
Lucene 3[1] 0 原理与代码分析
yiditushe
?
PPT
7 面向对象设计原则
yiditushe
?
PPT
10 团队开发
yiditushe
?
PPT
9 对象持久化与数据建模
yiditushe
?
PPT
8 Uml构架建模
yiditushe
?
厂辫谤颈苍驳入门纲要
yiditushe
?
J Bpm4 1中文用户手册
yiditushe
?
性能测试实践2
yiditushe
?
性能测试实践1
yiditushe
?
性能测试技术
yiditushe
?
Load runner测试技术
yiditushe
?
J2 ee性能测试
yiditushe
?
面向对象的闯蝉培训
yiditushe
?
贵濒别虫3中文教程
yiditushe
?
开放源代码的全文检索尝耻肠别苍别
yiditushe
?
基于分词索引的全文检索技术介绍
yiditushe
?
Lucene In Action
yiditushe
?
Lucene2 4学习笔记1
yiditushe
?
Lucene2 4 Demo
yiditushe
?
Lucene 全文检索实践
yiditushe
?
Lucene 3[1] 0 原理与代码分析
yiditushe
?
7 面向对象设计原则
yiditushe
?
10 团队开发
yiditushe
?
9 对象持久化与数据建模
yiditushe
?
8 Uml构架建模
yiditushe
?
Ad

六十一条面向对象分析设计的经验原则

  • 1. 你不必严格遵守这些原则,违背它们也不会被处以宗教刑罚。 但你应当把这些原则看 成警铃,若违背了其中的一条,那么警铃就会响起 ----- Arthur J.Riel     (1) 所 有 数 据 都 应 该 隐 藏 在 所 在 的 类 的 内 部 。     (2) 类 的 使 用 者 必 须 依 赖 类 的 共 有 接 口 , 但 类 不 能 依 赖 它 的 使 用 者 。     (3) 尽 量 减 少 类 的 协 议 中 的 消 息 。   (4)实现所有类都理解的最基本公有接口[例如,拷贝操作(深拷贝和浅拷贝)、相等性判 断 、 正 确 输 出 内 容 、 从 ASCII 描 述 解 析 等 等 ] 。     (5) 不 要 把 实 现 细 节 ( 例 如 放 置 共 用 代 码 的 私 有 函 数 ) 放 到 类 的 公 有 接 口 中 。   如果类的两个方法有一段公共代码,那么就可以创建一个防止这些公共代码的私有函 数 。     (6) 不 要 以 用 户 无 法 使 用 或 不 感 兴 趣 的 东 西 扰 乱 类 的 公 有 接 口 。   (7)类之间应该零耦合,或者只有导出耦合关系。也即,一个类要么同另一个类毫无关 系 , 要 么 只 使 用 另 一 个 类 的 公 有 接 口 中 的 操 作 。     (8) 类 应 该 只 表 示 一 个 关 键 抽 象 。   包中的所有类对于同一类性质的变化应该是共同封闭的。 一个变化若对一个包影响,则 将 对 包 中 的 所 有 类 产 生 影 响 , 而 对 其 他 的 包 不 造 成 任 何 影 响 .     (9) 把 相 关 的 数 据 和 行 为 集 中 放 置 。   设计者应当留意那些通过 get 之类操作从别的对象中获取数据的对象。这种类型的行为 暗 示 着 这 条 经 验 原 则 被 违 反 了 。     (10) 把 不 相 关 的 信 息 放 在 另 一 个 类 中 ( 也 即 : 互 不 沟 通 的 行 为 ) 。     朝 着 稳 定 的 方 向 进 行 依 赖 .     (11) 确 保 你 为 之 建 模 的 抽 象 概 念 是 类 , 而 不 只 是 对 象 扮 演 的 角 色 。   (12)在水平方向上尽可能统一地分布系统功能,也即:按照设计,顶层类应当统一地 共 享 工 作 。   (13)在你的系统中不要创建全能类/对象。对名字包含 Driver、Manager、System、Susystem 的 类 要 特 别 多 加 小 心 。     规 划 一 个 接 口 而 不 是 实 现 一 个 接 口 。
  • 2.   (14)对公共接口中定义了大量访问方法的类多加小心。大量访问方法意味着相关数据和 行 为 没 有 集 中 存 放 。     (15) 对 包 含 太 多 互 不 沟 通 的 行 为 的 类 多 加 小 心 。   这个问题的另一表现是在你的应用程序中的类的公有接口中创建了很多的 get 和 set 函 数 。   (16)在由同用户界面交互的面向对象模型构成的应用 程序中,模型不应该依赖于界面, 界 面 则 应 当 依 赖 于 模 型 。   (17)尽可能地按照现实世界建模(我们常常为了遵守系统功能分布原则、 避免全能类原则 以 及 集 中 放 置 相 关 数 据 和 行 为 的 原 则 而 违 背 这 条 原 则 )。     (18) 从 你 的 设 计 中 去 除 不 需 要 的 类 。     一 般 来 说 , 我 们 会 把 这 个 类 降 级 成 一 个 属 性 。     (19) 去 除 系 统 外 的 类 。   系统外的类的特点是,抽象地看它们只往系统领域发送消息但并不接受系统领域内其 他 类 发 出 的 消 息 。   (20)不要把操作变成类。质疑任何名字是动词或者派生自动词的类,特别是只有一个有 意义行为的类。 考虑一下那个有意义的行为是否应当迁移到已经存在或者尚未发现的某个类 中 。   (21)我们在创建应用程序的分析模型时常常引入代理类。在设计阶段,我们常会发现很 多 代 理 没 有 用 的 , 应 当 去 除 。     (22) 尽 量 减 少 类 的 协 作 者 的 数 量 。     一 个 类 用 到 的 其 他 类 的 数 目 应 当 尽 量 少 。     (23) 尽 量 减 少 类 和 协 作 者 之 间 传 递 的 消 息 的 数 量 。   (24)尽量减少类和协作者之间的协作量,也即:减少类和协作者之间传递的不同消息 的 数 量 。     (25) 尽 量 减 少 类 的 扇 出 , 也 即 : 减 少 类 定 义 的 消 息 数 和 发 送 的 消 息 数 的 乘 积 。   (26)如果类包含另一个类的对象,那么包含类应当给被包含的对象发送消息。也即:包 含 关 系 总 是 意 味 着 使 用 关 系 。
  • 3.     (27) 类 中 定 义 的 大 多 数 方 法 都 应 当 在 大 多 数 时 间 里 使 用 大 多 数 数 据 成 员 。    (28) 类包含的对象数目不应当超过开发者短期记忆的容量。这个数目常常是 6 。   当类包含多于 6 个数据成员时,可以把逻辑相关的数据成员划分为一组,然后用一个 新 的 包 含 类 去 包 含 这 一 组 成 员 。     (29) 让 系 统 功 能 在 窄 而 深 的 继 承 体 系 中 垂 直 分 布 。   (30)在实现语义约束时,最好根据类定义来实现。这常常会导致类泛滥成灾,在这种情 况 下, 约束 应当 在类 的行 为中 实现 ,通 常是 在构 造函 数中 实现 ,但 不是 必须 如此 。   (31)在类的构造函数中实现语义约束时,把约束测试放在构造函数领域所允许的尽量 深 的 包 含 层 次 中 。   (32)约束所依赖的语义信息如果经常改变,那么最好放在一个集中式的第 3 方对象中。   (33)约束所依赖的语义信息如果很少改变,那么最好分布在约束所涉及的各个类中。     (34) 类 必 须 知 道 它 包 含 什 么 , 但 是 不 能 知 道 谁 包 含 它 。    (35) 共享字面范围 ( 也就是被同一个类所包含 ) 的对象相互之间不应当有使用关系。     (36) 继 承 只 应 被 用 来 为 特 化 层 次 结 构 建 模 。     (37) 派 生 类 必 须 知 道 基 类 , 基 类 不 应 该 知 道 关 于 它 们 的 派 生 类 的 任 何 信 息 。     (38) 基 类 中 的 所 有 数 据 都 应 当 是 私 有 的 , 不 要 使 用 保 护 数 据 。   类的设计者永远都不应该把类的使用者不需要的东西放在公有接口中。     (39) 在 理 论 上 , 继 承 层 次 体 系 应 当 深 一 点 , 越 深 越 好 。   (40)在实践中,继承层次体系的深度不应当超出一个普通人的短期记忆能力。一个广为 接 受 的 深 度 值 是 6 。     (41) 所 有 的 抽 象 类 都 应 当 是 基 类 。     (42) 所 有 的 基 类 都 应 当 是 抽 象 类 。     (43) 把 数 据 、 行 为 和 / 或 接 口 的 共 性 尽 可 能 地 放 到 继 承 层 次 体 系 的 高 端 。   (44)如果两个或更多个类共享公共数据(但没有公共行为),那么应当把公共数据放在一
  • 4. 个 类 中 , 每 个 共 享 这 个 数 据 的 类 都 包 含 这 个 类 。   (45)如果两个或更多个类有共同的数据和行为(就是方法),那么这些类的每一个都应当 从 一 个 表 示 了 这 些 数 据 和 方 法 的 公 共 基 类 继 承 。   (46)如果两个或更多个类共享公共接口(指的是消息,而不是方法),那么只有他们需要 被 多 态 地 使 用 时 , 他 们 才 应 当 从 一 个 公 共 基 类 继 承 。   (47)对对象类型的显示的分情况分析一般是错误的。在大多数这样的情况下,设计者应 当 使 用 多 态 。   (48)对属性值的显示的分情况分析常常是错误的。类应当解耦合成一个继承层次结构, 每 个 属 性 值 都 被 变 换 成 一 个 派 生 类 。   (49)不要通过继承关系来为类的动态语义建模。试图用静态语义关系来为动态语义建模 会 导 致 在 运 行 时 切 换 类 型 。    (50) 不要把类的对象变成派生类。对任何只有一个实例的派生类都要多加小心。   (51)如果你觉得需要在运行时刻创建新的类,那么退后一步以认清你要创建的是对象。 现 在 , 把 这 些 对 象 概 括 成 一 个 类 。   (52)在派生类中用空方法(也就是什么也不做的方法)来覆写基类中的方法应当是非法的。   (53)不要把可选包含同对继承的需要相混淆。把可选包含建模成继承会带来泛滥成灾的 类 。     (54) 在 创 建 继 承 层 次 时 , 试 着 创 建 可 复 用 的 框 架 , 而 不 是 可 复 用 的 组 件 。   (55)如果你在设计中使用了多重继承,先假设你犯了错误。如果没犯错误,你需要设法 证 明 。   (56)只要在面向对象设计中用到了继承,问自己两个问题:(1)派生类是否是它继承的 那 个 东 西 的 一 个 特 殊 类 型 ? (2) 基 类 是 不 是 派 生 类 的 一 部 分 ?   (57)如果你在一个面向对象设计中发现了多重继承关系,确保没有哪个基类实际上是 另 一 个 基 类 的 派 生 类 。   (58)在面向对象设计中如果你需要在包含关系和关联关系间作出选择,请选择包含关 系 。   (59)不要把全局数据或全局函数用于类的对象的薄记工作。应当使用类变量或类方法。
  • 5.   (60)面向对象设计者不应当让物理设计准则来破坏他们的逻辑设计。但是,在对逻辑设 计 作 出 决 策 的 过 程 中 我 们 经 常 用 到 物 理 设 计 准 则 。   (61)不要绕开公共接口去修改对象的状态。