前言

最近在看《重构 改善既有代码的设计》，

有很多地方还是挺难的，感觉现在看有点早，应该工作满一年了再看，

因为很多重构还是需有一些经验支持，但既然看了就en着头皮看吧

目录介绍

第一章是一个小案例，通过一个案例，作者不断的优化，引入重构

第二章偏概念性，说实话有点晦涩难懂，看第二章几次差点睡着就跳着看看，建议和我一样的菜鸟本章也跳着看看概念
第三章代码的坏味道，可以说是本书的核心知识了，同样也有小许难懂，这也是本篇我想记录的东西

第四章主要讲测试相关，我也是跳着看的，既然重构就一定需要测试，小步慢行，不断测试

第五章-第十二章是重构列表，第六章往后都是具体重构的实例，可以当作工具书，随时查看，我打算通览一遍，目前坑坑洼洼看到了第六章

这样捋一下也有助于我后续读本书

大佬写的书真的难啃。。。

我们是坐在巨人肩膀上的婴儿👶

重构的定义

在不改变代码外在行为的前提下，对代码作出修改，以改进程序的内部结构

代码的坏味道

• 重复的代码

这样的情况往往由于复制黏贴

提取公共函数

• 过长函数

拆分成若干个函数

• 过大类

One Class One Responsibility

单一职责原则

• 过长参数列表

将参数封装成结构或者类。

• 发散式变化

发散试修改,改好多需求，都会动他。

将总是一起变化的东西放在一块儿。

• 霰弹式修改

散弹试修改,改某个需求的时候，要改很多类。

将各个修改点，集中起来，抽象成一个新类。

• 依恋情节

方法对某个class的兴趣高过对自己所处的本类的兴趣。

将这个函数挪到那个频繁使用的类里面，就成了调用本类的变量和方法。

• 数据泥团

某些数据通常像孩子一样成群玩耍：一起出现在很多类的成员变量中，一起绑定出现在许多方法的参数中，这些数据或许应该自己独立形成对象。 给他们独立抽一个新的类。

• 基本型别偏执

把基本数据类型封装在对象里

• switch惊悚现身

避免使用switch,而用多态或者策略模式替代

• 平行继承体系

当你改变一个层次中的某一个类时，你必须同时改变另外一个层次的并行子类。

让一个继承体系的实例引用另一个继承体系的实例，可以消除引用端的继承体系

• 冗赘类

有些类没干什么活，就把他干掉；合并类

• 夸夸其谈未来性

如果某个函数或类的使用方是测试，那就毫不犹豫干掉他；

以为他没有用户使用，没有存在的价值，不必幻想着未来他可能会用到

• 令人迷惑的暂时值域

将一些只在特殊场景才用到的孤儿临时变量，用一个类管理起来

• 过度耦合的消息链

A -> B -> C -> D

尽量避免消息链

拆函数或者移动函数

• 中间人

对象的基本特性之一就是封装，而你经常会通过分派去实现封装。

但是这一步不能走得太远，如果你发现一个类接口的一大半方法都在做分派，你可能需要移去这个中间人。

用继承代替委托

• 狎昵关系

两个类彼此使用对方的私有的东西，太亲密。

划清界限拆散，或合并，或改成单项联系。

• 异曲同工的类

差不多的类，抽公有的父类

• 不完美的程序库类

我们想使用类库，但类库不是很完美，我们想做一点变更，可以包一层函数或新的类

• 纯稚的数据类

纯数据类）类很简单，仅有公共成员变量，或简单操作函数。

将相关操作封装进去，减少public成员变量。

• 被拒绝的遗赠

超类传下来很多行为和状态，而子类只是用了其中的很小一部分。

这通常意味着你的类层次有问题。用代理替代继承关系。

• 过多的注释

代码太难懂了，不得不用注释解释。

往往需要大量的注释才可以弄的代码基本都需要重构

代码是最好的解释，当然并不意味着代码不需要注释

上面这些代码的坏味道会在后续读书实践过程中，有更深的认识后再进行修改和补充

下一步好好研究重构列表，先通读一遍再说

转载请注明：汪明鑫的个人博客 » 重构 代码的坏味道