《重构》第三章 - 读后感（平行继承、冗余类、兼容未来、迷惑字段、耦合消息链、中间人、过度依恋）...

在《重构》第三章剩余的部分里所设计的部分确实还是比较难理解的，或者说书中总结的一些坏味道代码潜在存在点比较难以发现吧，这块还是跟作者本人的经验有一下关系，为了更好的阅读本书，所以这块作者打算抄过来。在抄的同时希望能有一些感悟。

平行继承体系

每当我们为某个类添加一个子类，必须也为另一个类相应的添加一个子类。如果你发现某个继承体系的类名称前缀和另一个继承体系的类名称前缀完全相同，那么这标志这潜在的具有平行继承体系问题。

解决这种平行继承体系问题的方法就是让一个继承体系的实例引用另一个继承体系的实例。这块的意思就是如果我们发现我们类的继承关系存在相同的继承关系的时候，就不应该维持两套相似的继承关系，而是采用一套继承体系，对于业务来说我们只需要通过使用引用的方式桥接过来即可。作者这样理解正确吗？

冗赘类

通过字面意思我就知道这里的冗赘就是多余的意思。书中写道如果一个类不值得其身价，那么就应该消失。书中还举例说了子类，或者新开发类等情况消减原有类的功能。那么对于该类的存在与否都应该好好考虑，该拿掉的一定要拿到，不要留下。

夸夸其谈未来性

这块书中表达的意思就是说对于代码中为了兼容一些可能在未来做某些功能而添加的一些方法或者参数的情况。书中列举了抽象方法、多余参数这种常见的为了未来而做出让步的代码。对于这些为了兼容未来而添加的代码，书中建议我们去掉。主要的原因还是未来还没有来，做好当下比较重要。为了兼容未来可能就会给当下的代码整洁度造成困扰，当然并不是说一定要直接去掉，书中建议我们采用重命名的方法让我们需要改造的方法更具有现实感。

令人迷惑的暂时字段

在某些情况下，代码为了特定情况而定义的零时变量可能也会成为坏味道的源头。因为这些临时变量在某些情况下没有被函数使用，因此编程人员看到这种情况就比较费解了。对于这种问题，也就是书中写道的数据孤儿，为了让这些孤儿有一个家。我们应该为这些数据创建一个类，然后将其相关的操作放进去。同时书中写道这种对象应该是一个函数对象，也就是通过一个函数来获取对象的过程？

过度耦合的消息链

书中对消息链的定义大概是一个类中引用另一个类，然后另一个类引用另外一个新类，然后这样一直引用着，消息链会很长。当然这种引用的调用还是在一个函数中。对于这种问题，只要消息链中的任意一环发生变化，那么整个调用链都可能要做出改变。这块书中的建议是将代码使用引用实例的代码抽离出来然后独立成一个新函数。然后将然后将我们的处理逻辑和调用链分开，但是并不是说直接分开，就是说我们的调用链的主线是干净的，我们的数据处理过程不影响我们的调用链。其实这块的过度耦合的消息链，作者认为应该是消息链和我们的业务处理之间的耦合，所以问题就是如何将消息链和处理逻辑分离的问题。

中间人

这里的中间人主要描述的是面向对象编程中的委托模式，因为面向对象我们要调用其他类的方法，无非就是直接使用引用直接调用或者就是通过其他类进行委托去调用。那么问题就是说如果委托的层数很多，而且没啥必要的情况。因此书中建议我们将没有存在意义的委托类移除掉。采用直接进行打交道的方式。当然如果我们的委托类不单单是委托，它具有其他的功能的时候，书中建议我们将其变成实责对象的子类。因为这样既可以扩展原对象的行为，又可以去掉多余的委托动作。

Inappropriate intimacy

这种关系就是说两个类的关系过于亲密，对于这种问题。就应该提取公共部分形成新类，然后让他们各司其职，在共性的部分直接使用新类。或者将具体的共性代码在一处实现，另一个类通过委托的方式来获取结果。书中还写道对于父类提供的强大功能如果超出了子类所需的程度就应该将其独立出来，而不是继续存在与继承体系中。为何要提取出来的原因还是继承冗余导致类直接出现过度亲密的问题。所以说在《重构》这本书中还是维持各司其职的原本向往。