10.1 类的组织
遵循标准的Java约定，类应该从一组变量列表开始。如果有公共静态常量，应该先出现。然后是私有静态变量，以及私有实体变量。很少会有公共变量。
公共函数应跟在变量列表之后。我们喜欢把有某个公共函数调用的私有工具函数紧随在该公共函数后面。
封装
我们喜欢保持变量和工具函数的私有性，但并不执着于此。
10.2 类应该短小
关于类的第一条规则是类应该短小。第二条规则是还要更短小。
对于函数，我们通过计算代码行数衡量大小。对于类，我们计算其权责。
类的名称应该描述其权责。
10.2.1 单一权责原则
单一权责原则（SRP）认为，类或模块应该有且只有一条加以修改的理由。
系统应该由许多短小的类而不是少量巨大的类组成，每个小类封装一个权责，只有一个修改的原因，并与少数其他类一起协同达成期望的系统行为。
10.2.2 内聚
类应该只有少数实体变量。类中的每个方法都应该操作一个或多个这种变量。通常而言，方法操作的变量越多，就越黏聚到类上。如果一个类中的每个变量都被每个方法所使用，则该类具有最大的内聚性。
一方面，一般来说，创建这种极大化内聚是既不可取也不可能的；另一方面，我们希望内聚性保持在较高位置。内聚性高，意味着类中的方法和变量互相依赖，互相结合成一个逻辑整体。
10.2.3 保持内聚就会得到许多短小的类
将大函数拆分成许多小函数时，往往也是将类拆分成多个小类的时机。程序会更加有组织，也会拥有更为透明的结构。
10.3 为了修改而组织
在整洁的系统中，我们对类加以组织，以降低修改的风险。
隔离需求
降低连接度，遵循了依赖倒置原则（Dependency Inversion Priciple，DIP）。本质而言，DIP认为类应当依赖抽象而不是依赖具体细节。