代码的坏味道【4】



返回总目录



十四、Temporary Field(令人迷惑的暂时字段)

1、某个实例变量仅为某种特定的情况而设

2、某些实例字段仅为某个函数的复杂算法少传参数而设

将这些变量和相关函数提炼到一个独立的类中。

十五、Message Chains(过度耦合的消息链)

如果你看到用户向一个对象请求另一个对象,然后再向后者请求另一个对象,然后在请求另一个对象……这就是消息链。

实际代码就是一长串的getThis()或者一长串临时变量。

使用隐藏“委托关系”(这个后面会讲)来进行重构。当然了,可以在消息链的任何位置运用。

十六、Middle Man(中间人)

过度运用委托。

1、某个类接口有一半的函数都委托给其他类,这时应“移除中间人”:让客户直接调用委托类。

2、如果只有少数几个函数,那就直接调用

3、如果中间人还有其他行为,以继承取代委托,让委托类继承受托类。

十七、Inappropriate Intimacy(狎昵关系)

两个类过于亲密必须拆散。

1、可以提炼一个类,将两者的共同点提炼到这个类中。

2、可以去掉类之间不必要的关联。

3、将继承改为委托,把子类从继承体系移出

十八、Alternative Classes with Different Interfaces(异曲同工的类)

两个函数做同一件事,但是签名不同。将两个函数合并,并根据用途重新命名。

十九、Incomplete Library Class(不完美的类库)

类库函数构造的不够好,又不能修改它们

1、如果只想修改类的一两个函数,可以引入外加函数。

2、如果想要添加一大堆额外行为,建立一个新类包含这些额外行为,让其成为子类。

二十、Data Class(纯稚的数据类)

所谓Data Class:类只有一些字段,以及访问这些字段的函数。

1、如果拥有public字段,则将其封装起来

2、如果拥有集合类字段,则将其封装起来

3、对于不能修改的字段,去除set方法

二十一、Refused Bequest(被拒绝的遗赠)

派生类仅使用了基类很少一部分成员函数

如果子类复用了父类的行为(实现),却又不愿意支持基类的接口,那就使用委托替代继承。

二十二、Comments(过多的注释)

常常有这种情况:一段代码有着长长的注释,而这些注释之所以存在是因为代码很shit。

这时候我们可以先找到各种“坏味道”,然后重构它。

当你感觉需要撰写注释时,请先尝试重构,试着让所有的注释都变得多余。

记得有一句话是这么说的:注释的最高境界——代码即注释。

当然了,这也不是说,我们不应该写注释。只是注释要写对地方。

小结

到这里所有的“坏味道”已经讲完了。平常我们在写代码的时候,一定要注意这些坏味道。

“如果尿布臭了,就换掉它”。这句话同样适用于我们的代码。

“代码的坏味道”的系列文章主要是对常见的22种坏味道的了解和熟悉,以促使我们在开发过程中,能够经常性地分析和思考程序,寻找已经散发出坏味道的地方并对其进行适当重构,使得代码更加“漂亮”。

在后续的文章中,我会介绍一系列的重构手法来消除这些坏味道。

 To Be Continued...

时间: 2024-10-14 07:55:38

代码的坏味道【4】的相关文章

代码的坏味道

代码的坏味道Duplicated Code 重复代码Long Method 过长函数Large Class 过大的类Long Parameter List 过长参数列:类或者结构Divergent Change 发散式变化:一个类受多种变化的影响Shotgun Surgery 霰弹式修改:一种变化引发多个类相应修改.Feature Envy 依恋情结:一个类里的方法对另一个类的数据需求很大,需要移动方法的位置.Data Clumps 数据泥团:总是绑在一起出现的数据真应该拥有它们自己的对象.Pr

22种代码的坏味道,一句话概括

22种代码的坏味道,一句话概括: 假设一段代码是不稳定或者有一些潜在问题的,那么代码往往会包括一些明显的痕迹. 正如食物要腐坏之前,常常会发出一些异味一样. 我们管这些痕迹叫做"代码异味". 參考资料: http://blog.csdn.net/sulliy/article/details/6635596 http://sourcemaking.com/refactoring/bad-smells-in-code Code smells Duplicated Code --------

重构摘要3_代码的坏味道

如果尿布臭了,就换掉它. 1.Duplicated Code 重复代码 Extract Method Pull Up Method Form Template Method --> Template Method 模式 Substitute Algorithm --> 函数算法替代 2.Long Method 过长的函数 "间接层"所带来的全部利益--解释能力.共享能力.选择能力--都是有小函数支持的. 真正关键在于一个好名字. 每当感觉需要以注释来说明点什么的时候,我们就

重构笔记——代码的坏味道(上)

在重构入门篇中,简单地介绍了重构的定义.为何重构.何时重构等.我想对于重构是如何运作的,你已经有了较好的理解了.但是对于代码中的坏味道,你可能 知道的并不多.坏味道可能是无形中产生的,也可能是开发人员偷懒造成的,还可能是其它某些因素导致的.不管怎么样,代码中的坏味道对程序没有半点好处,它 会促使程序腐烂,甚至变质.对于开发人员,真的是很有必要对这些坏味道进行了解和熟悉,理解它们产生的场景.针对当前程序,发现坏味道,对代码进行重构, 以消除坏味道,提高代码质量,提高自己水平. 下面让我们一起来熟悉

代码的坏味道之二——译自《重构》

巨型类 当一个类尝试做的太多,它常常展示出过多的实例变量.当一个类有太多实例变量,重复代码的出现就不远了. 你可以提取类来打包一部分变量.选择在部件中有意义的变量放在一起.例如,“存款总量”和“存款货币”很可能在同一部件中.更宽泛的说,在一个类中变量的某个子集共同的前缀和后缀预示着组成同一个部件的机会.如果这个部件有成为子类的意义,你会发现提取子类往往更容易. 有时一个类不会一直使用它全部的实例变量.如果如此,你可能可以提取类或者提取子类若干次. 相比于一个类有太多实例变量,一个类有太多代码是重

代码的坏味道之五 ——译自《重构》

夸夸其谈未来性Speculative Generality Brian Foote 为一个我们都很敏感的味道建议的名字.你会遇到它当有人说“哦,我认为我们某一天会需要能力去做那一类的事”然后这样一来希望得到各种钓钩和特别的例子去处理并不需要的事情.结果往往是更难懂也难维护.如果所有的这些机制被用上,那这样做还是值得的.如果不是这样,也就不值得.这个机制就是这样产生的,所以处理掉它. 如果你有抽象类并没有做很多事,用Collapse Hierarchy.不必要的委托可以用Inline Class去

代码的坏味道之三——译自《重构》

散弹式修改(Shotgun Surgery) 散弹式修改和发散式变化类似,但却相反.每当你做一种修改你却必须对很多不同的类做很多小的变化,你面临的就是散弹式修改.当变化到处都是时,有的变化就不好找到了,这样很容易漏掉重要的更改. 这种情况下你要使用移动方法(Move Method)和移动字段(Move Field)来把所有的变化放到一个类里.如果没有现成的类合适,就创建一个类.通常你会用到内联化类(Inline Class)把一系列行为放到一起.你会有一点发散式变化的问题,但你可以轻松处理它.

代码的坏味道之四 ——译自《重构》

基本类型偏执Primitive Obsession 大多数编程环境有两种类型的数据.记录类型允许你把数据结构化成有意义的集合.基本类型是你建设用的砖块.记录类型总是会产生一定量的额外开销.这可能是数据库中的表,或者被很尴尬的创建当你希望他们只为一或两件东西存在. 关于对象一个很有意义的东西是,他们模糊甚至打破了基本类型和大型类之间的界线.你可以很轻松的写小的无法和语言中内建类型相区别的类.Java对数字有基本类型,但字符和日期这些在其他环境也是基本类型的,在Java里是类. 新接触对象的人通常不

代码的坏味道之一——译自《重构》

重复代码 臭味集合里面排第一的就是重复代码了.如果你在不止一处发现了同样结构的代码,你可以确定如果你找到一种方法来统一他们的话,你的程序将会改善. 最简单的重复代码问题是当你在同一个类中有两个方法有相同的表达时出现的.那么你需要做的所有步骤只是提取方法然后在两处调用代码. 另一种常见的重复问题是当你在两个兄弟类中有相同的表达.你可以通过在两个类中提取方法然后拉升方法(Pull up Method)来消灭重复.如果这段代码相似但不相同,你需要通过提取方法来分离相同和不同的部分.你可能会发现你可以使

关于重构(四)--代码的坏味道

代码的坏味道主要有: Duplicated Code---(重复的代码):如果你在两个以上的地点看到相同的程序结构,那可以:设法将它们合二为一,程序会变得更好. Long Method ------(过长函数): 1 private void bindSaleInfo(string swhere) 2 { 3 ArrayList proList = getProductInfo(swhere); 4 string colorStr = ""; 5 StringBuilder rowHt