第十章 类
要将注意力放到代码组织的更高层面,才能得到更整洁的代码。
10.1 类的组织
遵循标准的 Java 约定,类应该从一组变量列表开始。先是公共静态变量,然后是私有静态变量,以及私有实体变量。很少会有公共变量。
公共函数应跟在变量列表之后,公共函数调用的私有工具函数紧随在该公有函数后面。这符合自顶向下原则。
10.2 类应该短小
在设计类时,第一条规则就是类应该短小
对于函数,通过计算代码行数来衡量大小。对于类,采用不同的衡量方法,计算权责。
类的名称应当描述其权责。实际上,命名正是帮助判断类的长度的第一个手段。如果无法为某个类命以精确的名称,这个类就太长了。类名越含混,该类越偶可能拥有过多权责。
10.2.1 单一权责原则
单一权责原则(SRP)认为,类或模块应有且只有一条加以修改的理由。
系统应该由许多短小的类组成,而不是少量巨大的类组成。每个小类封装一个权责,只有一个修改的原因,并与少量其他类一起协同,从而达成期望的系统行为。
10.2.2 内聚
类应该只有少量实体变量。类中的每个方法都应该操作一个或多个这种变量。通常而言,方法操作的变量越多,就越黏聚到类上。如果一个类中的每个变量都被每个方法所使用,则该类具有最大的内聚性。
一般来说,创建这种极大化内聚类是既不可取也不可能的;另一方面,我们希望内聚性保持在较高位置。内聚性高,意味着类中的方法和变量互相依赖、互相结合成一个逻辑整体。
保持函数和参数列表短小的策略,有时会导致为一组子集方法所用的实体变量数量增加。出现这种情况时,往往意味着至少有一个类要从大类中挣扎出来。你应当尝试将这些变量和方法分拆到两个或多个类中,让新的类更为内聚。
10.2.3 保持内聚性就会得到许多短小的类
当类丧失了内聚性,就拆分它!
将大函数拆分成许多小函数,往往也是将类拆分为多个小类的时机。程序会更加有组织,也会拥有更为透明的结构。
重构后的程序更长的原因:其一,重构后的程序采用了更长、更有描述性的变量名。其二,重构后的程序将函数和类声明当作是给代码添加注释的一种手段。其三,我们采用了空格和格式技巧让程序更可读。
10.3 为了修改而组织
开放-闭合原则(OCP):类应当对扩展开放,对修改封闭。
依赖倒置原则(DIP),类应当依赖于抽象,而不是依赖于具体细节。