代码整洁之道-10 类的修改

 

工具函数紧随在调用它的化共函数后面

测试需要调用一个函数或变量，轩为在整个程序包内可访问

首先想办法保有隐私，放松封装是下策

类短小： 计算权责

 

方法数量较少，可还是拥有太多权责

名称描述其权责，命名帮助判断类长度

25个单词描述一个类，且不用 if、and 还能通过之跟踪，不能还能

无法为某个类命以精确的名称，不能只做一件事

 

只有一条修改的理由

变这个可能也变那个，但现在问题是变那个不一定变这个了

 

分而治之，其在编程作为中的重要程度等同于程序中应用这个原则的重要程度

直接转向下一个问题，切分为去耦式单元

搞清楚一件较大工作如何完成，就得在类与类之间找来找去？

大量短小类，少量庞大类，不会更多移动部件。

想把工 具归置到头有定义和标记良好的组件的工具箱的抽屉中

少数几个 把所有东西扔进去的？

 

一个特定时间只需理解直接有关的复杂性

在目前不需要了解的一大堆东西中艰难跋涉

只有一个修改的原因

类中的方法和变量互相依赖，互相结合成一个逻辑整体

 

 

一个思维转换的过程：

一个有许多变量的大函数，你想把该函数中某一步部分拆解成单独函数，

但要扩出来的代码使用了该函数中声明的4个变量

将4个变量提升为类的实体变量，无需传递任何变量

也使类增益了内聚几至-堆积了越来越多只为允许少量函数共享而存在的实体变量

如果有些函数想要共享某些变量，为什么不让它们拥有自己的类呢

当类丧失了内聚性，就拆分它

将大函数拆为许多小函数，也是将类拆分为多个小类的时机

会拥有更为透明的结构

 

这并不算是重写，我没从闫开始写一遍程序

采用了同样的算法和机制来完成工作

通过编写验证第一人程序的精确行为的用例一实现修改，然后，做了许多小改动，每改动一次就执行一次，确保程序的行为没有变化