Welcome everyone

重构 代码的坏味道

编码 汪明鑫 141浏览 0评论

前言

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

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

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

 

目录介绍

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

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

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

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

 

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

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

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

 

 

重构的定义

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

 

代码的坏味道

  • 重复的代码

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

提取公共函数

 

  • 过长函数

拆分成若干个函数

 

  • 过大类

One Class One Responsibility

单一职责原则

 

  • 过长参数列表

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

 

  • 发散式变化

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

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

 

  • 霰弹式修改

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

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

 

  • 依恋情节

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

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

 

  • 数据泥团

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

 

  • 基本型别偏执

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

 

  • switch惊悚现身

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

 

  • 平行继承体系

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

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

 

  • 冗赘类

有些类没干什么活,就把他干掉;合并类

 

  • 夸夸其谈未来性

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

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

 

  • 令人迷惑的暂时值域

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

 

  • 过度耦合的消息链

A -> B -> C -> D

尽量避免消息链

拆函数或者移动函数

 

  • 中间人

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

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

用继承代替委托

 

  • 狎昵关系

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

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

 

  • 异曲同工的类

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

 

  • 不完美的程序库类

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

 

  • 纯稚的数据类

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

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

 

  • 被拒绝的遗赠

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

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

 

  • 过多的注释

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

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

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

 

 

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

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

 

 

 

 

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

喜欢 (0)

说点什么

您将是第一位评论人!

提醒
avatar
wpDiscuz