Clean Code - 类

类的组织

作者给出了 Java 类中元素的组织。出现的前后关系如下

• 变量
  • 公共静态常量
  • 私有静态变量
  • 私有实体变量
  • （少有的）公共变量
• 函数
  • 静态函数
  • 公共函数（私有的工具函数紧紧贴合在调用它的公共函数之后）

封装

• 尽量保持变量和工具函数的私有性，测试如果有访问需要，那么首先将变量声明为（protected），让测试能访问到。
• （个人观点）能不 public 就别 public ！public 代表了外部所有人都能访问，会影响到很多东西，而且很容易破坏 SRP 原则

类应该短小

• 衡量标准：权责（responsibility）
• 衡量方法：
  • 用简短的言语描述出这个类的职责，且不用到 ”并且“、”和“、”同时“、”或者“、”但“、“还能”……这些词，如果有，说明权责太多了，拆！
  • 看类名是否模糊，如果类名含有模糊的词，如 Processor、Manager、Super，往往说明有不恰当的权责聚集情况存在

单一权责原则（SRP）

• 定义：类或模块应有且只有一条加以修改的理由

• 个人理解：单一权责的权责划分也和粒度有关系，粒度越大的划分标准会让一些类 ”看似符合“ 单一权责，例如我说 UIManager 就是管理 UI 的东西，只要 UI 不变，这很有问题。那么什么叫 UI 变了？变了什么？实际应该要把粒度再划小一点，保证在一个比较小的粒度标准下划分出来的单一权责就会比较合理。

大类 < 小类

系统应该由许多短小的类而不是少量巨大的类组成。每个小类封装一个权责，只有一个修改原因，并与少数其他类一起协同达成期望的系统行为。

内聚

• 内聚类的表现：

  类应该只有少量实体变量，类中的每个方法都应该操作一个或多个这种变量。通常而言，方法操作的变量越多，就越黏到类上。如果一个类中的每个变量都被每个方法使用，则该类具有强大的内聚性。（简而言之，少量的实体变量散布在尽可能多的函数中）

• 保持内聚性就会得到许多短小的类

  如何证明？书本说，将类变短小，就要将大函数变小，仅仅将大函数中的若干段拆出来，做成小函数，将小函数所需的变量不做参数而是变成类的成员变量。当有过多的成员变量只为少数函数服务的时候，类的内聚性就降低了，此时就要拆新类，新的类将会有更高的内聚性！

为修改而组织

• 总之一句话：在理想的系统中，我们通过拓展系统而非修改现有代码来添加特性

• （个人理解）：要对系统可预见的修改留空间，每次修改都尽量组织好代码，让下次修改的代价变得更小。

隔离修改

• 具体类、抽象类：

  具体类包含实现细节（代码），而抽象类则只呈现概念。依赖于具体细节的客户类充斥了许多可变因素，当细节改变，就会有风险，我们可以借助接口和抽象类来隔离这些细节带来的影响。

• 依赖倒置（DIP）：

  依赖倒置可以理解，但是在书本中鲍勃大叔强调了一点，本质而言，DIP 认为类应当依赖于抽象而不是依赖于具体细节！（个人理解：抽象具体来说可以是抽象接口、抽象类，当然了如果只是说 Java）