当前位置: 首页 > 编程学习 > 软件工程 > 面向对象 > 正文

重构之法:代码的坏味道

2018-04-22 来源:博客园/Jioong

坏味道意指代码中出现的可以被改进的地方。当你嗅到坏味道的时候,也就意味着重构的时机到了。

重构就是对软件内部结构的一种调整,目的是在不改变软件可观察行为的前提下,提高其可理解性,降低其修改成本。

以下是《重构》中列出的“坏味道“。

1. 重复代码

重复是代码腐朽之源。重复意味着当发生变化时,总是有很多的地方需要修改,也就是说需要对很多不同的地方负责。即使有着高级工具的辅助,对于跨函数、跨类之间的大量重复的同步修改都不会是一件轻而易举,并且能保证不会犯错的事情。

每一处重复都意味着维护时的一份责任。消除重复就可以最大化的减少职责,也降低出错的可能性。

抛开出错的可能性不谈,重复一般意味着业务逻辑的抽象还不够合理。

2. 过长函数

没有什么是增加一层“间接层”不能解决的。如果有,那就增加两层。

程序越长越难以理解。这可能与每个人大脑的结构有一定的关系,可能有些人的大脑的“栈”比较深,适应那些长函数。但对于大部分程序员、大部分人而言,太长的函数会导致“栈溢出”。

将一个长函数拆分成多个小的函数,无疑会增加更多的函数间调用。在直觉上,这样需要增加额外的开销。但是,现代OO语言几乎已经完全免除了进程内的函数调用的开销。

3. 过大的类

过大的类的一个标识就是,类中出现大量的实例变量。

不是从一个类的代码行数来判断是否类过大。而是需要从的职责来判断,如果它拥有不同的职责,那么就需要将不同的职责拆分到不同的类中。

单一职责原则。

4. 过长的参数列表

过长的参数列表会导致难以理解,太多参数会造成前后不一致、不易使用。

传递太多的参数数据,会带来另外一个问题:很难记住参数的顺序。也就是说,不容易记住每一个参数位置传入的值分别是什么意思。如果传入的是一个对象,则可以通过对象的实例变量来取值。屏蔽了参数顺序间的问题。

但,有时候如果不希望造成“被调用对象”与“较大对象”间的某种依赖关系,这时将数据从对象中拆解出来单独作为参数也是合理的。

5. 发散式变化

一个类受多种变化的影响。

针对某一外界变化的所有修改,都只应该发生在单一类中,而这个新类内的所有内容都应该反应此变化。

应该找出某特定原因而造成的所有变化,然后将它们提炼到一个类中。

6. 霰弹式修改

一种变化引发多个类相应的修改。

也就是,逻辑概念上相近的代码被分散四处。这样导致很难寻找,也会很容易忘记某个修改。

应该把所有需要修改的代码放进同一个类中。

7. 依恋情结

函数对某个类的兴趣高过对自己所处类的兴趣。这里所谓的兴趣就是指,对那个类的函数、数据的调用。

一个函数会用到几个类的功能,将它置于何处的原则:判断哪个类拥有最多被此函数使用的数据,然后就将这个函数将那些数据摆在一起。

8. 数据泥团

总是捆绑出现在一起的数据应该拥有属于它们自己的对象。

9. 基本类型偏执

不要执着于使用基本数据类型。

10. switch 语句

减少使用 switch 语句。从本质上说,它意味着重复。

可以考虑使用多态来替换它。但是对于在单一函数中出现的使用多态,有点小题大做。

11. 平行继承体系

当为某个类增加一个子类,必须也为另一个类相应的增加一个子类,便是出现了这个问题。

消除的策略是:让一个继承体系的实例引用另一个继承体系的实例。

12. 冗余类

对于无用的类,应该消除。这里的“无用”可能是因为重构使得它原有的工作被别的类瓜分了。

13. 夸夸其谈未来性

不要为了出于应对变化的目的,来将一个类打造的“过于”灵活。

变化是程序员最大的敌人。问题不在于“变化会出现”,而在于“难以预料变化出现的方式”。“变化”的粉墨登场总是会让我们措手不及。

提前就想要做好应对变化的准备,大部分时候都是挖了一条“马奇诺防线”。投入巨大,收效甚微。

我们需要让代码具有灵活性,但是过于的灵活带来的问题就是代码复杂度的增加。

14. 令人迷惑的暂时字段

对象在所有的时候被认为需要它的所有变量。对于那些仅为某种特殊情况而设置的实例变量,会使得代码难以理解。

15. 过度耦合的消息链

消息链就是“开火车”,一长串的“.”会让你lost。

“不要与陌生人讲话。”

16. 中间人

“中间人”就是把别人对它的调用“委托”给其他的对象。

17. 狎昵关系

对于过分亲密的类,需要移动它们的函数和实例变量来帮它们划清界限。

继承往往会造成过度亲密,因为子类对超类的了解总是超过后者的主观愿望。

18. 异曲同工的类

两个函数做同一件事,却有不同的签名,需要根据它们的用途重新命名。

19. 不完美的库类

复用别人的库时,可能库不够好,而往往我们不可能修改其中的类使其完成我们希望的工作。

20. 纯粹的数据类

它们就是数据容器。不明白为什么这会被认为是一种“坏味道”。我们经常用到的"bean"。

21. 被拒绝的遗赠

子类应该继承超类的函数和数据。但如果不想要继承所有的数据呢?该怎么拒绝这样的“传承”。

22. 过多的注释

如果需要添加注释来解释函数,或许意味着需要拆分出一些小的函数,或给函数重命名。

代码的坏味道有如厨房的油污,开始时不会觉得有多大的影响,但时间长了就会累积成“恶心”又难以“清除”的污渍。我们需要保持每天的清扫,而不是定期的“大扫除”。上面的“味道”就是一点一点的“油星”溅在“厨房”里,看到它们就顺手擦掉吧!