当我们已经对设计模式倒背如流时,却往往发现在实际代码编写中有生搬硬套的感觉。设计模式是前人经验的总结,直接拿来用合不合适呢?这让我想起了大学一位老师告诉我们的一条学习的道路“知识,理论,智慧”。设计模式是很一种优雅的“智慧”,但对于我们初学者来说还仅仅是留存于文字的“知识”。把“知识”融合到自己的开发中,在不断探索和总结中形成自己“理论”,再应用到实际中,那么这才是是真正属于我们自己的“智慧”。重构恰恰是由“知识”到“理论”的必经之路,而书中的各种重构方法无疑是这条路上清晰的路标。
代码的坏味道大家一看都不会陌生,绝对是在我们的编程中如影随形的,现在把相应的重构方法和设计模式总结出来,方便自己参考查阅,也希望对大家有所帮助。
友情提示:下面所列出的不是公式,不是别的重构方法不能用,也不是非要重构到相应的设计模式,因为不论是重构还是应用设计模式,一切的目的都是为了软件构架的“优雅”,而不是炫耀技术。另外,两位作者在描述重构步骤的时候,都不断重复着“编译并通过测试”的步骤,这无疑是在强调测试的重要性,和重构的递进性,切不可一措而蹴。
代码的坏味道 |
一般重构方法 |
使用模式重构 |
重复代码 |
提炼方法 提取类 方法上移 替换算法 链构造方法
|
构造Template Method 以Composite取代一/多之分 引入Null Object 用Adapter统一接口 用Fatory Method引入多态创建 |
过长方法 |
提取方法 组合方法 以查询取代临时变量 引入参数对象 保持对象完整 |
转移聚集操作到Vistor 以Strategy取代条件逻辑 以Command取代条件调度程序 转移聚集操作到Collecting Parameter |
过长参数列 |
以方法取代参数 引入参数对象 保持对象完整 |
|
条件逻辑过度复杂 |
分解条件式 合并条件式 合并重复的条件片段 移除控制标记 以卫语句取代嵌套条件式 以多态取代条件式 引入断言 |
以Strategy取代条件逻辑 转移装饰功能到Decorator 以State取代状态改变条件语句 引入Null Object |
分支语句 |
提取方法 转移方法 以子类取代类型代码 以多态取代条件式 已明确方法取代参数 |
以State/Strategy取代类型代码 引入Null Object 以Command替换条件调度程序 转移聚集操作到Visitor |
基本类型迷恋 程序代码过于依赖基本类型(int,string,double,array等低层次语言要素) |
以对象取代数据值 以类型取代类型代码 以子类取代类型代码 提取类 引入参数对象 以对象取代数组 |
以State取代状态改变条件语句 以Strategy取代条件逻辑 以Composite取代隐含树 以Interpreter取代隐式语言 转移装饰功能到Decorator 用Builder封装Composite |
数据泥团 在类的字段和参数列中,总是一起出现的数据 |
提取类 引入参数对象 保持对象完整 |
|
令人迷惑的临时字段 |
提取类 |
引入Null Object |
组合爆炸 许多段代码使用不同种类或数量的数据或对象做同样的事情(例如使用特定条件和数据库查询) |
|
以Interpreter取代隐式语言 |
过大类 |
提取类 提取子类 提取接口 复制被监视数据 |
以Command取代条件调度程序 以State取代状态改变条件语句 以Interpreter取代隐式语言 |
冗赘类 不再做很多工作或没有用的类 |
折叠继承关系 内联Singleton |
|
不恰当的暴露 在客户代码中不应看到类的字段和方法,却是公开可见的 |
封装字段 封装群集 移除设置方法 隐藏方法 |
用Factory封装类 |
发散式变化 类经常因为不同的原因在不同方向上发生变化,显然是违反了单一职责原则 |
提取类 |
|
霰弹式修改 如果遇到变化,必须在不同的类中作出相应的修改 |
转移方法 转移字段 内联类 |
将创建知识搬移到Factory |
依恋情结 方法对于某个类的兴趣高过对自己所处的宿主类 |
转移方法 提取方法 |
引入Strategy 引入Visitor |
平行继承体系 当为一个类增加一个子类时,也必须在另一个类中增加一个相应的子类 |
转移方法 转移字段 |
|
夸夸其谈未来性 |
折叠继承关系 内联类 移除参数 移除方法 |
|
过度耦合的消息连 不断的向一个对象索求另一个对象 |
隐藏委托 提取方法 转移方法 |
使用抽象引入Chain Of Responsibility |
中间转手人 类接口中有很多方法都委托给其他类 |
移除中间转手人 内联方法 以继承取代委托 |
|
狎昵关系 类之间彼此依赖于其private成员 |
转移方法 将双向关联改为单向 提取类 隐藏委托 以继承取代委托 |
|
异曲同工的类 |
重命名方法 转移方法 提取超类 |
用Adapter统一接口 |
不完善的程序库类 |
引入外加方法 引入本地扩展 |
用Adapter统一接口 用Facade封装类 |
纯稚的数据类 只拥有字段的数据类 |
封装字段 封装集合 移除设置方法 转移方法 隐藏方法 |
|
被拒绝的遗赠 继承父类时,子类想要选择继承的成员 |
以委托取代继承 |
|
过多的注释 为糟糕的代码写大量的注释 |
使用一起重构方法,使方法本身达到自说明的效果,让注释显得多余 |
|
怪异解决方案 在同一系统中使用不同的方式解决同一问题 |
替换算法 |
用Adapter统一接口 |
分享到:
相关推荐
**代码的坏味道与重构方式对应表** 代码的坏味道是指在编程过程中可能出现的不良编程习惯,这些习惯可能导致代码难以理解和维护。以下是一些常见的代码坏味道及其对应的重构方法: 1. **重复代码 (DRY - Don't ...
### 《重构 改善既有代码的设计》之代码的坏味道 #### 代码的坏味道简介 重构是一种改进代码质量的重要手段,它不仅能够提升代码的可读性和可维护性,还能帮助开发者更好地理解现有系统架构。《重构 改善既有代码...
通过重构,我们可以消除代码的坏味道,使得设计模式的引入更为顺畅。例如,当发现大量重复代码时,可以重构为模板方法模式,将共性部分抽象出来;当需要处理多个对象间的交互时,可以考虑使用观察者模式,通过重构将...
标题“代码坏味道整理”指的...博客链接提供的资源可能包含对这些坏味道的更深入讨论,以及如何通过重构技术来改善代码质量。通过学习和应用这些原则,开发者可以提升他们的编程技巧,编写出更加健壮、易于维护的代码。
重构,正如标题所言,包括了“重构介绍”、“重构原则”以及“代码的坏味道”等多个方面,旨在提高代码的可读性、可维护性和整体质量。 首先,我们来探讨“重构介绍”。重构是一种系统性的修改现有代码的过程,目的...
在第三章中,作者详细列举了多种"代码的坏味道",也就是代码中常见的问题和反模式,旨在帮助开发者识别这些问题并进行有效的重构。 "源码"标签表明我们将关注代码的实际结构和质量,而"工具"标签则暗示可能涉及到...
2. **重构的步骤和技巧**:学习一系列实用的重构手法,包括如何识别代码坏味道,以及如何逐步改进代码结构。 3. **设计模式的解析**:理解各种经典设计模式的原理、适用场景及其在重构过程中的应用。 4. **实例分析*...
这一过程包括识别代码中的坏味道(code smell)——那些表明代码可能存在潜在问题的迹象,并应用一系列小型、安全的重构步骤来消除这些问题。 书中的重构模式(Refactoring Patterns)提供了具体的指导,例如: 1....
这可能包括识别代码坏味道、使用提取方法、引入解释性变量、移动函数等重构技术。通过这种方式,读者可以在短时间内提升对重构的理解和实践能力。 《重构与模式》作为一本英文版的书籍,更深入地探讨了重构与设计...
他提出了一个全面的重构步骤框架,包括识别坏味道的代码、选择合适的重构模式、实施重构以及验证重构结果。 首先,"识别坏味道的代码"是重构的起点。代码坏味道通常指的是那些难以理解、冗余、复杂或不易维护的代码...
识别代码的“坏味道”是重构的重要步骤。例如,重复代码是常见的问题,可以通过提炼函数或应用设计模式如Template Method来消除。过长的函数降低了代码可读性,可以将其拆分为多个独立的功能。过大类的责任不明确,...
1. **提高代码质量**:重构可以消除代码中的坏味道,提升代码可读性和可维护性。 2. **增强系统的可扩展性**:通过重构可以使代码更易于理解和修改,便于添加新功能。 3. **降低维护成本**:高质量的代码意味着更低...
书中可能会介绍各种重构技术,如提取方法、移动函数、替换条件为类等,这些技术有助于消除坏味道,提升代码质量。 2. **设计模式**:设计模式是面向对象编程中被广泛接受的最佳实践,是解决特定设计问题的模板。...
2. **C#重构技术**:详细讲解针对C#代码的重构模式,如提取方法、移动字段、替换条件为函数等,以及如何利用Visual Studio等IDE的内置重构工具。 3. **ASP.NET重构实践**:探讨在Web应用程序中进行重构的挑战和策略...
1. **重构的动机**:重构的主要目标是消除代码中的坏味道,如过长的方法、重复的代码、复杂的条件语句等,以提升代码质量,降低维护成本。 2. **重构的原则**:遵循小步前进的原则,每次重构只做一小部分改动,并...
Fowler在书中详细列举了多种重构模式,这些模式都是经过实践验证的代码优化策略。 书中的中文PDF和英文CHM版本为读者提供了双语学习的机会。中文版使国内开发者能够无障碍地理解重构的概念和技术,而英文版则保留了...
通过这些技巧,可以将程序中的坏味道(代码中的一些不良设计)转换成良好设计。Martin Fowler还强调了重构的时机,指出重构并非一蹴而就,而应该是一个持续的过程。程序员应该在开发新功能或者修复bug的同时,不断地...