《代码整洁之道》读书笔记（六）之写好类

代码语句和函数的整洁是一个比较底层的介绍，下面将介绍比之更高层级的类的整洁。

1. 类的组织

遵循标准的Java约定，类应该从一组变量列表开始。如果有公共静态常量，应该先出现。然后是私有静态变量，以及私有实体变量。很少会有公共变量。

公共函数应跟在变量列表之后。把某个公共函数调用的私有工具函数紧随在该公共函数之后。

封装

优先保持变量和工具函数的私有性。

2. 类应该短小

关于类的第一条规则是类应该短小。

函数的第一规则也是短小。不过对于函数，我们通过计算代码行数来衡量大小。而对于类，我们采用不同的衡量方法，计算权责(resonsibility)。

2.1 单一职责原则

单一职责原则（SRP）认为，类或模块应有且只有一条加以修改的理由。

SRP是OO设计中最为重要的概念之一，也是较为容易理解和遵循的概念之一。但是，SRP往往也是最容易被破坏的类设计原则。

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

2.2. 内聚

类应该只有少量实体变量。类中的每个方法都应该操作一个或多个这种变量。通常而言，方法操作的变量越多，就越黏聚到类上。如果一个类中的每个变量都被每个方法所使用，则该类具有最大的内聚性。

保持函数和参数列表短小的策略，有时会导致为一组子集方法所用的实体变量数量增加。出现这种情况时，往往意味着至少有一个类要从大类中挣扎出来。

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

将大函数拆分为许多小函数，往往也是将类拆分为许多小类的时机。

想想看一个有许多变量的大函数。你想把该函数中某一小部分拆解成单独的函数。不过，你想要拆出来的代码使用了该函数中声明的4个变量。是否必须将这4个变量都作为参数传递到新函数中呢？ 完全没必要！只要将4个变量提升为类的实体变量，完全无需传递任何变量就能拆解代码了。应该很容易将函数拆分为小块。可惜这意味着类丧失了内聚性，以为堆积了越来越多只允许少量函数共享而存在的实体变量。那么，将这些实体变量和函数移到新类中就完美了！

3. 为了修改而合理组织类

遵循OCP（开放闭合原则）：对扩展开放，对修改封闭。

隔离修改

需求会改变，所以代码也会改变。具体类包含实现细节，而抽象类则只呈现概念。

我们应该遵循DIP（依赖倒置原则）：类应该依赖抽象而不是依赖于具体细节。