转载自 http://www.cnblogs.com/karoc/archive/2011/09/16/2179125.html
|
坏味道
|
特征
|
情况及处理方式
|
目标
|
|
重复代码
|
1.重复的表达式
2.不同算法做相同的事
3.类似代码
|
同一个类的两个函数有相同表达式
|
重复代码提取为方法
|
相同表达式只在一个类的一个方法出现，供其他方法调用
|
|
兄弟类含有相同表达式
|
重复代码提取为方法
提升方法到父类
|
|
不相干类含有相同代码
|
提取为独立类供调用
|
|
过长函数
|
1.代码前面有注释
2.条件表达式
3.循环
|
|
提取方法
|
每个方法只做一件事，方法要定义完善、命名准确
|
|
过大的类
|
1.一个类中有太多实例变量
2.一个类中有太多代码
|
部分字段之间相关性高
|
相关的字段和方法提取为类
|
每个类负责一组具有内在的相互关联的任务
|
|
某些字段和方法只被某些实例用到
|
这些字段和方法移到子类中
|
|
过长参数列
|
1.参数列过长
2.参数列变化频繁
|
方法可以通过其他方式获取该参数
|
让参数接受者自行获取该参数
|
只需要传给函数足够的、让其可以从中获取自己需要的东西就行了
|
|
同一对象的若干属性作为参数
|
在不使依赖恶化的情况下，使用整个对象作为参数
|
|
被调用函数使用了另一个对象的很多属性
|
将方法移动到该对象中
|
|
某些数据缺乏归属对象
|
首先创建对象
|
|
发散式变化
|
一个类受多种变化的影响
|
类经常因为不同的原因在不同的方向上发生变化
|
将特定原因造成的所有变化提取为一个新类
|
针对某一外界变化的所有修改，只应发生在单一类中，而这个类中所有的内容都应反映此变化
|
|
散弹式修改
|
一种变化引发多个类的修改
|
某种变化需要在许多不同的类中做出小修改
|
把所有需要修改的代码放进同一个类中
|
针对某一外界变化的所有修改，只应发生在单一类中，而这个类中所有的内容都应反映此变化
|
|
依恋情结
|
一个函数使用其他类属性比使用自身类属性还要多
|
某个函数从另一个对象调用了几乎半打的取值函数
|
将依恋代码提取为单独方法，移动到另一对象
|
将数据和对数据的操作行为包装在一起
|
|
数据泥团
|
同时使用的相关数据并未以类的方式组织
1.两个类中相同的字段
2.许多函数中相同的参数
|
|
先将字段提取为类，再缩减函数签名中的参数
|
总是绑在一起的数据应该拥有属于它们自己的对象
|
|
基本类型偏执
|
过多使用基本类型
|
总是被放在一起的基本类型字段
|
提取类
|
将单独存在的数据值转换为对象
|
|
参数列中有基本类型
|
提取参数对象
|
|
数组中容纳了不同的对象，需要从数组中挑选数据
|
用对象取代数组
|
|
基本数据是类型码
|
使用类替换类型码
|
|
带条件表达式的类型码
|
使用继承类替换类型码
|
|
Switch语句
|
相同的switch、case语句散布于不同地方
|
根据类型码进行选择的switch
|
使用多态替代switch
|
避免到处做相同的修改
|
|
单一函数中有switch
|
使用显式的方法取代参数
|
|
平行继承体系
|
1.为某个类增加子类时，必须为另一个类增加子类
2.某个继承体系类名前缀和另一个继承体系类名前缀相同
|
|
一个继承体系中的实例引用另一个继承体系中的实例，然后迁移成员
|
避免到处做相同的修改
|
|
冗赘类
|
类无所事事
|
父类和子类无太大差别
|
将它们合为一体
|
|
|
某个类没有做太多事情
|
将这个类所有成员移到另一个类中，删除它
|
|
夸夸其谈未来性
|
|
某个抽象类没有太大作用
|
将父子类合并
|
|
|
不必要的委托
|
将这个类所有成员移到另一个类中，删除它
|
|
函数的某些参数未用上
|
移除参数
|
|
函数名称带有多余的抽象意味
|
重命名函数名
|
|
函数只被测试方法调用
|
连同测试代码一并删除
|
|
令人迷惑的暂时字段
|
1.某个实例字段仅为某种情况而设
2.某些实例字段仅为某个函数的复杂算法少传参数而设
|
|
提取单独的类，封装相关代码
|
|
|
过度耦合的消息链
|
一长串的getThis或临时变量
|
客户类通过一个委托类来取得另一个对象
|
隐藏委托
|
消除耦合
|
|
中间人
|
某个类接口有大量的函数都委托给其他类，过度使用委托
|
有一半的函数
|
移除中间人
|
|
|
少数几个函数
|
直接调用
|
|
中间人还有其他行为
|
让委托类继承受托类
|
|
狎昵关系
|
某个类需要了解另一个类的私有成员
|
子类过分了解超类
|
将继承改为委托，把子类从继承体系移出
|
封装
|
|
类之间双向关联
|
去掉不必要的关联
|
|
类之间有共同点
|
提取新类
|
|
异曲同工的类
|
两个函数做同一件事，但是签名不同
|
|
合并
|
|
|
不完美的类库
|
类库函数构造的不够好，又不能修改它们
|
想修改一两个函数
|
在调用类增加函数
|
|
|
想添加一大堆额外行为
|
使用子类或包装类
|
|
幼稚的数据类
|
某个类除了字段，就是字段访问器、设置器
|
|
1.用访问器取代public字段
2.恰当封装集合
3.移除不需要的设置器
4.搬移对访问器、设置器调用方法到此类
5.隐藏访问器、设置器
|
封装
|
|
被拒绝的馈赠
|
派生类仅使用了基类很少一部分成员函数
|
子类拒绝继承超类接口
|
使用委托替代继承
|
|
|
过多的注释
|
一段代码有着长长的注释
|
|
消除各种坏味道
|
|
分享到：
相关推荐
### 《重构 改善既有代码的设计》之代码的坏味道 #### 代码的坏味道简介 重构是一种改进代码质量的重要手段，它不仅能够提升代码的可读性和可维护性，还能帮助开发者更好地理解现有系统架构。《重构 改善既有代码...
重构，正如标题所言，包括了“重构介绍”、“重构原则”以及“代码的坏味道”等多个方面，旨在提高代码的可读性、可维护性和整体质量。 首先，我们来探讨“重构介绍”。重构是一种系统性的修改现有代码的过程，目的...
《重构-第3章 代码的坏味道》是软件开发领域的一本经典著作，由Martin Fowler所著。这本书深入探讨了如何识别并消除代码中的不良设计模式，以提高代码质量、可读性和可维护性。在第三章中，作者详细列举了多种"代码...
**代码的坏味道与重构方式对应表** 代码的坏味道是指在编程过程中可能出现的不良编程习惯，这些习惯可能导致代码难以理解和维护。以下是一些常见的代码坏味道及其对应的重构方法： 1. **重复代码 (DRY - Don't ...
标题“代码坏味道整理”指的是在编程过程中，代码可能会出现的一些不良习惯或低效的编程实践，这些被称为“代码坏味道”。这些坏味道通常会使代码难以理解、维护和扩展，降低了软件的质量。为了提高代码可读性和可...
识别代码的“坏味道”是重构的重要步骤。例如，重复代码是常见的问题，可以通过提炼函数或应用设计模式如Template Method来消除。过长的函数降低了代码可读性，可以将其拆分为多个独立的功能。过大类的责任不明确，...
重构的实践中，识别代码中的“坏味道”至关重要。所谓“坏味道”，是指那些指向代码质量问题的不良迹象。例如，“神秘命名”、“重复代码”、“过长函数”和“发散式变化”等，这些都是代码库中经常需要关注的重构...
"编码中的21种代码坏味道" 在设计和编码中，存在着21种代码坏味道，这些坏味道可能会给后续维护带来极大影响。如果我们能够识别和消除这些坏味道，那么我们的代码将变得更加简洁、可维护和可扩展。 Duplicated ...
这一过程包括识别代码中的坏味道（code smell）——那些表明代码可能存在潜在问题的迹象，并应用一系列小型、安全的重构步骤来消除这些问题。 书中的重构模式（Refactoring Patterns）提供了具体的指导，例如： 1....
本文以"重构代码笔记1"为出发点，深入探讨了24种常见的代码坏味道及其对应的重构策略。 首先，神秘命名（Mysterious Name）是重构的常见起点，通过改变函数声明和变量名，使其更具描述性，如将`cash0`更改为`cash_...
重构之所以重要，是因为它能够帮助开发者逐渐摆脱历史遗留代码的束缚。许多经验丰富的开发者在完成项目后会发现，他们得到的代码虽然能够运行，但效率低下且难以维护和扩展。这种现象被形象地称为“代码的债务”。...
重构-改善既有代码的设计之代码的坏味道举例说明.md
### 重构：改善既有代码的设计 #### 书籍概述与核心价值 《重构：改善既有代码的设计》这本书由Martin Fowler撰写，是一本关于软件工程领域的经典著作。它详细介绍了如何通过一系列小步骤对现有代码进行改进，进而...
15-21天，笔记可能深入到C#中的高级重构技术，如重构面向过程代码为面向对象代码，使用 LINQ 来简化数据操作，以及如何通过依赖注入来提高组件之间的灵活性。 22-28天，作者可能会探讨如何在实际项目中应用重构，...
《重构改善既有代码的设计》是针对提升Java代码质量的重要参考书籍，它的核心思想在于如何通过重构技术来改善和优化现有的代码设计，使其更为简洁、易于维护和扩展。"重构"一词在软件工程领域指的是在不改变软件外部...
他提出了一个全面的重构步骤框架，包括识别坏味道的代码、选择合适的重构模式、实施重构以及验证重构结果。 首先，"识别坏味道的代码"是重构的起点。代码坏味道通常指的是那些难以理解、冗余、复杂或不易维护的代码...