关于重构,代码的坏味道,应该重构的代码

应该重构的代码 设计模式

1.重复的代码: 函数

重复代码在同一个类中的不一样方法中,则直接提炼为一个方法 spa

若是重复代码在两个互为兄弟的子类中,则将重复的代码提到父类中 设计

若是代码相似,则将相同部分构成单独函数,或者用 Template Method 设计模式 对象

重复代码出如今不相干的类中,则将代码提炼成函数或者放在独立的类中  继承

2.过长的函数: it

下降了可读性,应该将独立的功能提炼成新函数 class

3. 过大类 变量

使得责任不清晰,容易形成重复代码,混乱,应该将过大类的功能拆分红多个功能单一的小类 重构

4.过长的参数列

过长的参数列难以理解,并且容易传错参数。应该将参数列表用参数对象替换

5.发散式变化:

一个类因为不一样的缘由而被修改。应该将类拆分红多个,每一个类只由于一种变化而修改。

6.霰弹式修改

 与发散式变化相反,遇到变化时须要修改许多不一样的类。应该将相似的功能放到一个类中

7.依恋情结:

函数对某个类的兴趣高过对本身所处的类,一般是为了取其余类中的数据。应该将函数部分功能移到它感兴趣的类中

8.数据泥团:

在多个地方看到相同的数据项。例如:

      多个类中相同的变量,多个函数中相同的参数列表,而且这些数据老是一块儿出现。应该将这些数据项放到独立的类中

9.基本类别偏执:

对象技术的新手一般不缘由在小任务上运用小对象,好比结合数值和币别的money class,等,应该Replace Data Value with Object。

10.分支语句:

大量的分支、条件语句致使过长的函数,而且可读性差。应将它变成子类或者使用 State和 Strategy模式

11.平行继承体系

是霰弹式修改的特殊状况。通常是当你为某个类增长了一个子类,必须也为另外一个类相应的增长一个子类。若是你发现某个继承体系的class名称前缀和另外一个继承体系的class名称前缀彻底相同。变素有问题了。 应该让一个继承体系的实体(instance)指涉(参考,引用,refer to)另外一个继承体系的实体。

12 冗赘类(lazy class)

几乎没有用的组建 应该进行inline class

13.夸夸其谈将来性

如今用不到,以为将来能够用到的代码,要警戒。应该将用不上的代码去掉

14.过分耦合的消息链

 一个对象请求另外一个对象,后者又请求另外的对象,而后继续。。。。,造成耦合的消息链。应该公布委托对象供调用

15 纯粹的数据类

  将数据类中数据以Public方式公布,没对数据访问进行保护。应该 将数据封装起来,提供Get/Set方法。

16 过多的注释

 代码有着长长的注释,但注释之因此可能是由于代码很糟糕。先重构代码,再写上必要的注释

17 使人迷惑的暂时值域

如某个instance变量仅为某特定状况而设,在变量未被使用的状况下猜想当初设置目的很是困难。应该创建一个新的class,把全部和这个变量相关的代码都放到里面。

l

待续。。

相关文章
相关标签/搜索