代码整洁之道-第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 认为类应当依赖于抽象而不是依赖于具体细节。

10.4 文献