《重构》第三章 - 读后感（发散、散弹、依恋）

随着第三章的不断学习，会发现我们针对代码中的坏味道，书中也是不断的深入细节。刚开始一些代码问题都是最常见的，而后则是一些特殊的例子。所以在名称的命名上也很奇特，有时候不仔细理解，那么还真不好理解。

今天主要过一下坏味道代码中的发散式变化、散弹式变化和依恋情结。首先看这些名词估计已经都懵逼了。所以预想就成了一种困难，只能凭空猜测了。

发散式变化

书中举了两个例子，主要表达的一种现象是在一个类中一处发生变化。那么使用该类的其他类的很多部分都需要发生变化，这种局限与一个类内的一处变化导致引用类的其他部分变化的现象就叫做发散式变化。作者怕自个记不住这个发散，所以将其比作一个平面内的发散。而这个平面就是一个类，或者是一个领域。对于在一个平面内的变化导致该关联的平面内的其他部分的变化，书中写道使用抽离类的方式，大概的意思就是说将潜在的可能引起该类其他部分变化的共性逻辑实现放到一个抽离的类中，这样在抽离的类中变化都不会影响他的引用层类。

散弹式修改

散弹是修改说的是一个类发生变化，那么与之相关的很多类都要发生变化。对于这种情况，我们仔细思考一下其出现的原因还是该类的属性、方法被不同的类进行了引用。所以对于这种情况，书中建议我们将一些列相关的行为发或者属性进行抽象并放到同一个类中，如果没有相关的类，那么就创作一个。当然这种操作是可以迭代的。但是如果把一些类似的具有相同领域性质的属性和方法放到一起是有发散式的问题。

总结一下就是发散式变化就是一个类受多种变化的影响，散弹式就是说一个类变化引发多个类的变化。对应的方法归结于将相关的方法和属性进行领域规划拆分，保障该领域的变化仅仅引起该领域的变化，对于引用该领域的对象没有任何影响。这块作者觉得还是说的是我们笔记第一节中说到的自己做好自己事情的基本原则。也就是说自己管不好自己，那么很容易导致发散以及散弹式的问题。

依恋情结

依恋情结主要描述的是我们代码中引用其他类的一种现象。一般来说我们在一个类中引用其他类无非就是获取数据，然后进行计算任务。但是如果我们通过该类过去的数据达到一定次数，那么就不是单纯的计算问题了，很大程度是上边界不清的依恋问题。对于这种问题书中建议我们将代码中通过依恋对象获取数据的代码和相关的逻辑进行抽离并独立成一个函数。然后将该函数放置到该计算逻辑应该归属的领域内。这里进行改造的灵魂就是将一起变化的东西放到一起。说白了也就是我们在第一节中说到的自己管好自己事，也只有自己做好自己事的基础上我们才有可能改变别人甚至的所有人。