代码整洁之道-第10章-类-读书笔记
第 10 章 类
要将注意力放到代码组织的更高层面，才能得到整洁的代码。
10.1 类的组织
遵循标准的 Java 约定，类应该从一组变量列表开始。如果有公共静态变量，应该先出现。然后是私有静态变量，以及私有实体变量。很少会有公共变量。
公共函数应跟在变量列表之后。我们喜欢把由某个公共函数调用的私有工具函数紧随在该公有函数后面。这符合了自顶向下原则，让程序读起来就像一篇报纸文章。
封装
若同一程序包内的某个测试需要调用一个函数或变量，我们就会将该函数或变量置为受保护或在整程序包内可访问。然而，我们首先会想办法使之保有隐私。放松封装总是下策。
10.2 类应该短小
关于类的第一条规则是类应该短小。第二条规则是还要更短小。
对于函数，我们通过计算代码行数衡量大小。对于类，我们采用不同的衡量方法，计算权责（responsibility）。
类的名称应当描述其权责。实际上，命名正是帮助判断类的长度的第一个手段。如果无法为某个类命以精确的名称，这个类大概就太长了。类名越含混，该类越偶可能拥有过多权责。
我们也应该能够用大概 25 个单词简要描述一个类，且不用“若（if）”、“与（and）”、“或（or）”或者“但（but）”等词汇。如果用若、与、或、但就说明类有太多权责。
10.2.1 单一权责原则
单一权责原则（SRP）认为，类或模块应有且只有一条加以修改的理由。该原则既给出了权责的定义，又是关于类的长度的指导方针。类只应有一个权责—只有一条修改的理由。
鉴别权责（修改的理由）常常帮助我们在代码中认识到并创建出更好的抽象。
系统应该由许多短小的类而不是少量巨大的类组成。每个小类封装一个权责，只有一个修改的原因，并与少数其他类一起协同达成期望的系统行为。
10.2.2 内聚
类应该只有少量实体变量。类中的每个方法都应该操作一个或多个这种变量。通常而言，方法操作的变量越多，就越黏聚到类上。如果一个类中的每个变量都被每个方法所使用，则该类具有最大的内聚性。
一般来说，创建这种极大化内聚类是既不可取也不可能的；另一方面，我们希望内聚性保持在较高位置。内聚性高，意味着类中的方法和变量互相依赖、互相结合成一个逻辑整体。
保持函数和参数列表短小的策略，有时会导致为一组子集方法所用的实体变量数量增加。出现这种情况时，往往意味着至少有一个类要从大类中挣扎出来。你应当尝试将这些变量和方法分拆到两个或多个类中，让新的类更为内聚。
10.2.3 保持内聚性就会得到许多短小的类
当类丧失了内聚性，就拆分它！
将大函数拆分成许多小函数，往往也是将类拆分为多个小类的时机。程序会更加有组织，也会拥有更为透明的结构。
重构后的程序更长的原因：其一，重构后的程序采用了更长、更有描述性的变量名。其二，重构后的程序将函数和类声明当作是给代码添加注释的一种手段。其三，我们采用了空格和格式技巧让程序更可读。
10.3 为了修改而组织
出现了只与类的一小部分有关的私有方法行为，意味着存在改进空间。
开放-闭合原则（OCP）：类应当对扩展开放，对修改封闭。
隔离修改
部件之间的解耦代表着系统中的元素互相隔离得很好。隔离也让对系统每个元素的理解变的更加容易。
通过降低连接度，我们的类就遵循了另一条类设计原则，依赖倒置原则（Dependency Inversion Principle,DIP）。本质而言，DIP 认为类应当依赖于抽象而不是依赖于具体细节。
