第十章 类
10.1 类的组织
遵循标准的Java约定，类应该从一组变量列表开始。如果有公共静态常量，应该先出现。 然后是私有静态变量，以及私有实体变量。很少会有公共变量。公共函数因跟在列表变量之后。公共函数调用的私有工具函数紧跟在公共函数后面。
封装。
10.2 类应该短小
类也应该短小，对于函数，我们采用计算代码行数衡量大小，对于类，我们衡量方式是计算权责。
类的名称应当描述其权责。实际上，命名正是帮助判断类的长度的第一个手段。如果无 法为某个类命以精确的名称，这个类大概就太长了。类名越含混，该类越有可能拥有过多权 责。例如，如果类名中包括含义模糊的词，如Processor 或Manager 或Super ,这种现象往往 说明有不恰当的权责聚集情况存在。
描述一个类就不要使用 if、and、or、but等词汇。
10.2.1 单一权责原则
单一权责原则(SRP)认为，类或模块应有且只有一条加以修改的理由。该原则既给出 了权责的定义，又是关于类的长度的指导方针。类只应有一个权责一只有一条修改的理由。
10.2.2 内聚
类应该只有少量实体变量。类中的每个方法都应该操作一个或多个这种变量。通常而言， 方法操作的变量越多，就越黏聚到类上。如果一个类中的每个变量都被每个方法所使用，则 该类具有最大的内聚性。
10.2.3 保持内聚性就会得到许多短小的类
仅仅是将较大的函数切割为小函数，就将导致更多的类出现。想想看一个有许多变量的 大函数。你想把该函数中某一小部分拆解成单独的函数。不过，你想要拆出来的代码使用了 该函数中声明的4个变量。是否必须将这4个变量都作为参数传递到新函数中去呢？
完全没必要！只要将4个变量提升为类的实体变量，完全无需传递任何变量就能拆解代 码了。应该很容易将函数拆分为小块。
可惜这也意味着类丧失了内聚性，因为堆积了越来越多只为允许少量函数共享而存在的 实体变量。等一下！如果有些函数想要共享某些变量，为什么不让它们拥有自己的类呢？当 类丧失了内聚性，就拆分它！
所以，将大函数拆为许多小函数，往往也是将类拆分为多个小类的时机。程序会更加有 组织，也会拥有更为透明的结构。
10.3 为了修改而组织
对于多数系统，修改将一直持续。每处修改都让我们冒着系统其他部分不能如期望般工 作的风险。在整洁的系统中，我们对类加以组织，以降低修改的风险。
隔离修改
需求会改变，所以代码也会改变。我们可以借助接口和抽象类来隔离这些细节。依赖倒置原则。
我们要构建一个依赖于外部TokyoStockExchange API 的Portfolio 类，与其设计直接依赖于Tokyo StockExchange 的Portfolio 类，不如创建StockExchange 接口， 其中只声明一个方法：
