61条Java面向对象设计的经验原则

    (1)全部数据都应该 潜藏在所在的类的内部 。

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

    (3)尽量削减类的 协定中的 信息 。

    (4)实现全部类都 了解的最 根本公有接口[例如，拷贝操作(深拷贝和浅拷贝)、相等性推断、正确输出内容、从ASCII 形容解析等等].

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

    假如类的两个 步骤有一段公共代码，那么就 可以 缔造一个 预防这些公共代码的私有函数 。

    (6)不要以消费者 无奈 使用或不有兴趣的东西扰乱类的公有接口 。

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

    (8)类应该只 示意一个 要害 形象 。

    包中的全部类关于同一类性质的 变迁应该是一起 关闭的 。一个 变迁若对一个包影响，则将对包中的全部类产生影响，而对 其余的包不造成任何影响 .(9)把 有关的数据和行为集中 搁置 。

    设计者 该当 留神那些通过get之类操作从别的对象中猎取数据的对象 。这 品种型的行为暗示着这条 教训 准则被违反了 。

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

    朝着 巩固的方向进行依赖 。

    (11)确保你为之建模的 形象概念是类，而 不仅是对象 表演的角色 。类 该当统一地共享工作 。

    (13)在你的系统中不要 缔造全能类/对象 。对名字包括Driver、Manager、System、Susystem的类要特殊多加小心 。

    规划一个接口而不是实现一个接口 。

    (14)对公共接口中定义了大量 拜访 步骤的类多加小心 。大量 拜访 步骤 象征着 有关数据和行为没有集中 存放 。

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

    这个问题的另一 体现是在你的 利用程序中的类的公有接口中 缔造了众多的get和set函数 。

    (16)在由同消费者界面交互的Java面向对象模型组成的 利用程序中，模型不应该依赖于界面，界面则 该当依赖于模型 。

    (17)尽可能地依照 事实世界建模(我们 一般为了 恪守系统 性能 分布 准则、幸免全能类 准则以及集中 搁置 有关数据和行为的 准则而 违反这条 准则) .(18)从你的设计中去除不需求的类 。

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

    (19)去除系统外的类 。

    系统外的类的特色是， 形象地看它们只往系统领域发送 信息但并不 承受系统领域内 其余类发出的 信息 。

    (20)不要把操作变成类 。质疑任何名字是动词或者派生自动词的类，特殊是惟独一个有 意思行为的类 。考量一下那个有 意思的行为是否 该当 迁徙到已经存在或者尚未发现的某个类中 。

    (21)我们在 缔造 利用程序的 综合模型时 一般引入代理类 。在设计阶段，我们常会发现众多代理没有用的， 该当去除 。

    (22)尽量削减类的 合作者的数量 。

    一个类用到的 其余类的数目 该当尽量少 。

    (23)尽量削减类和 合作者中间传递的 信息的数量 。

    (24)尽量削减类和 合作者中间的 合作量，也即：削减类和 合作者中间传递的不同 信息的数量 。

    (25)尽量削减类的扇出，也即：削减类定义的 信息数和发送的 信息数的乘积 。

    (26)假如类包括另一个类的对象，那么包括类 该当给被包括的对象发送 信息 。也即：包括关系总是 象征着 使用关系 。

    (27)类中定义的大多数 步骤都 该当在大多数 工夫里 使用大多数数据成员 。

    (28)类包括的对象数目不 该当超过开发者短期记忆的容量 。这个数目 一般是6.当类包括多于6个数据成员时， 可以把逻辑 有关的数据成员划分为一组， 而后用一个新的包括类去包括这一组成员 。

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

    (30)在实现语义 束缚时，最好依据类定义来实现 。这 一般会招致类泛滥成灾，在这种状况下， 束缚 该当在类的行为中实现，通常是在 构造函数中实现，但不是必须如此 。

    (31)在类的 构造函数中实现语义 束缚时，把 束缚测试放在 构造函数领域所同意的尽量深的包括 品位中 。

    (32)Java面向对象中， 束缚所依赖的语义信息假如 时常转变，那么最好放在一个集中式的第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) 惟独在Java面向对象设计中用到了继承，问自己两个问题：(1)派生类是否是它继承的那个东西的一个特殊类型？(2)基类是否派生类的一 部分？

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

    (58)在面向对象设计中假如你需求在包括关系和关联关系间作出 取舍，请 取舍包括关系 。

    (59)不要把全局数据或全局函数用于类的对象的薄记工作 。 该当 使用类变量或类 步骤 。

    (60)Java面向对象设计者不 该当让物理设计准则来 毁坏他们的逻辑设计 。然而，在对逻辑设计作出决策的过程中我们 时常用到物理设计准则 。

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