《重构》阅读比较----代码的坏味道

已于 2022-04-24 09:21:43 修改
阅读量340 收藏
点赞数
分类专栏： 《重构》阅读笔 文章标签： c++ 开发语言 自动驾驶
于 2022-04-23 22:48:48 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_38650944/article/details/124370082
版权

1. Duplicated Code(重复代码)

2. Long Method(过长函数)

        程序越长越难以理解，所以需要分解成多个小函数，关键在于有一个好名字。当我们需要以注释来说明点什么的时候，就把需要说明的东西写进一个独立函数中，并以其用途（非实现手法）命名。我们可以对一组甚至一行代码做这件事，哪怕替换后的函数调用动作比函数自身还长，只要函数名称能解释其用途。

        确定需要提炼代码的技巧就是寻找注释。则可以将这段代码替换成一个函数，并且在注释的基础上给这个函数命名。

        条件表达式和循环也是提炼的信号。可以使用Decompose contidtional处理条件循环表达式。至于循环，你应该将循环和其内的代码提炼到一个独立函数中。

3. Large Class(过大的类)

        如果利用单个类做太多事情，则其内会出现太多实例变量。一旦如此，Duplicayted Code就会接踵而至。

        可以利用Extract Class(149)将几个变量一起提炼至新类。提炼时选择类内彼此相关的变量，将他们放在一起。通常类内的数个变量有着相同的前缀或字尾，就意味着有机会把它提炼到某个组件内。如果这个组件适合一个子类，则Extract Subclass(330)往往比较简单。

4. Long parameter list(过长参数列)

        将过长参数列表换成对象进行传递。

5. Divergent Change(发散式变化)

        针对某一外界变化的所有相应修改，都应该只发生在单一类中。因此，你应该找出某特定原因而造成的所有变化，然后运用Extract Class(149)将他们提炼到另一个类中。

6.Shotgun Surgery(霰弹式修改)

        一种变化对应多个不同类内的许多小修改，则应该使用MOve Method(142)和Move Field(146)将所有需改的代码放进同一个类中。如果没有合适的类安置，就创造一个。通常可以运用Iiline Class(154)把一系列的相关行为放进同一个类。

7. Feature Envy(依恋情节)

        函数对某个类的性去高过对自己所处类的兴趣，最通常的焦点是数据。当我们看到某个函数计算某个值而调用另一个对象的半打取值函数，则应该将这个函数移到另一个地方。可以使用Move Method(142)。有的函数中只有一部分受这种依恋之苦，则使用Extract Method（110）把这一部分提炼到独立函数中，再使用Move Method(142)带他去该去的地方。

        如果多个一个函数会用到多个类的功能，则应该判断哪个类拥有最多彼此函数使用的数据，然后将这个函数和那些数据摆在一起。如果先以Extracy=t Method(110)将这个函数分解为几个较小函数并分贝放置在不同地点。

        将总是一起变化的东西放在一块儿。

8. Data Clumps(数据泥团)

        总是绑在一起出现的数据应该拥有他们自己的对象。然后可以着手寻找Feature Envy,可以帮你只出能够移至新类中的种种程序行为。

9. Primitive Obsession(基本类型偏执)

        在小任务上运用小对象，比如结合数值和币值的money类，起始值和结束值组成的range类。则可以将原本单独存在的数据值替换成对象，进入炙手可热的对象世界。

        如果有总被放在一起的字段，则可以Extract Clas(149)，若果在参数列表中看到基本型数据，可以试试Introduce parameter Object(295),如果发现自己正从数组中挑选数据，则可以运用Replace Array With Object(186)。

10. Switch Statements(switch惊悚现身)

        少用switch，而使用多态。因为如果给switch添加case，则必须找到所有的switch语句并修改它。

11. Parallel InheritanceHierarchies(平行继承体系)

        每当为某个类增加子类，必须为另一个类相应增加一个子类，则可以让一个继承体系的是里引用另一个继承体系的是里。如果再运用Move Method(142)和Move Field(146)，就可以将引用端的继承体系消弭于无形。

12. Lazy Class(冗余类)

        类的价值不够，就让他消失。如果某些子类没有做足够工作，试试Collapse Hierarchy(344)。对于几乎没用的组件，应该以Inline Class(154)对付他们。

13. Speculative Generality(夸夸其谈未来性)

        不加入当前不需要的代码。

14. Temporary Field(令人迷惑的暂时字段)

        

15.Message Chains(过度耦合的消息链)

16.Middle Man(中间人)

17. Inappropriate Intimacy(狎呢关系)

18.Alternative Classes with Diffferent Interfaces(异曲同工的类)

19.Incomplete Library Class(不完美的类)

20.Data Class(纯稚的数据类)

21. Refused Bequest(被拒绝的遗赠)

22. Comments(过多的注释)

        如果需要注释来说明做了什么，试试Extract Method(110)；如果函数已经提炼出来了，还需要注释解释行为，则试试Rename Method(273)；如果需要注释说明某些系统的需求规格，试试Introduce Assertion(267)。

qq_38650944
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
重构－改善既有代码的设计
11-19
一直很喜欢重构这本书，但是由于自己记性不太好，书看过之后其中的方法总是记不住，于是想如果有电子版的重构书就好了，工作中遇到重构的问题可以随时打开查阅。在网上搜索了许久，发现重构这本书有英文chm版本的，而中文版的电子书只有扫描的PDF版本，用起来非常不方便。于是萌生想做一本重构工具书的想法，本来打算自己重新将重构书的内容再整理归类一下，后来发现原书的目录编排就很适合做工具书，包括坏味道分类，重构手法归类等，都有了一个比较系统的整理。因此，我利用空余时间制作了这样的一本中文的chm版重构，希望对大家有所帮助，也算对中国软件业做出一点小小的贡献。 本书基本上是取自”重构”中文版一书的内容，但格式上参照的是chm英文版的格式，还有一些格式小修改，比如第一章的重构前后代码对比。因为时间匆促，个人能力有限，本书难免存在一些缺漏，如果大家发现有问题，随时可以给我发邮件，我会尽快更新错误的内容。 最后再次感谢几位大师 Martin Fowler、Kent Beck等，还有翻译的侯捷和熊节先生，为我们带来这么精彩的一本书。谢谢。 免责声明：本书仅供个人学习研究之用，不得用于任何商业目的，不得以任何方式修改本作品，基于此产生的法律责任本人不承担任何连带责任。
《重构 改善既有代码的设计》之代码的坏味道
02-14
附件是在读完《重构 改善既有代码的设计》之后，为代码的坏味道所撰写的总结文档。
重构-改善既有代码的设计
06-10
第1章　重构，第一个案例 1 1.1　起点 1 1.2　重构的第一步 7 1.3　分解并重组statement() 8 1.4　运用多态取代与价格相关的条件逻辑 34 1.5　结语 52 第2章　重构原则 53 2.1　何谓重构 53 2.2　为何重构 55 2.3　何时重构 57 2.4　怎么对经理说 60 2.5　重构的难题 62 2.6　重构与设计 66 2.7　重构与性能 69 2.8　重构起源何处 71 第3章　代码的坏味道 75 3.1　Duplicated Code（重复代码） 76 3.2　Long Method（过长函数） 76 3.3　Large Class（过大的类） 78 3.4　Long Parameter List（过长参数列） 78 3.5　Divergent Change（发散式变化） 79 3.6　Shotgun Surgery（霰弹式修改） 80 3.7　Feature Envy（依恋情结） 80 3.8　Data Clumps（数据泥团） 81 3.9　Primitive Obsession（基本类型偏执） 81 3.10　Switch Statements（switch惊悚现身） 82 3.11　Parallel InheritanceHierarchies（平行继承体系） 83 3.12　Lazy Class（冗赘类） 83 3.13　Speculative Generality（夸夸其谈未来性） 83 3.14　Temporary Field（令人迷惑的暂时字段） 84 3.15　Message Chains（过度耦合的消息链） 84 3.16　Middle Man（中间人） 85 3.17　Inappropriate Intimacy（狎昵关系） 85 3.18　Alternative Classes with Different Interfaces（异曲同工的类） 85 3.19　Incomplete Library Class（不完美的库类） 86 3.20　Data Class（纯稚的数据类） 86 3.21　Refused Bequest（被拒绝的遗赠） 87 3.22　Comments（过多的注释） 87 第4章　构筑测试体系 89 4.1　自测试代码的价值 89 4.2　JUnit测试框架 91 4.3　添加更多测试 97 第5章　重构列表 103 5.1　重构的记录格式 103 5.2　寻找引用点 105 5.3　这些重构手法有多成熟 106 第6章　重新组织函数 109 6.1　Extract Method（提炼函数） 110 6.2　Inline Method（内联函数） 117 6.3　Inline Temp（内联临时变量） 119 6.4　Replace Temp with Query（以查询取代临时变量） 120 6.5　Introduce Explaining Variable（引入解释性变量） 124 6.6　Split Temporary Variable（分解临时变量） 128 6.7　Remove Assignments to Parameters（移除对参数的赋值） 131 6.8　Replace Method with Method Object（以函数对象取代函数） 135 6.9　Substitute Algorithm（替换算法） 139 第7章　在对象之间搬移特性 141 7.1　Move Method（搬移函数） 142 7.2　Move Field（搬移字段） 146 7.3　Extract Class（提炼类） 149 7.4　Inline Class（将类内联化） 154 7.5　Hide Delegate（隐藏“委托关系”） 157 7.6　Remove Middle Man（移除中间人） 160 7.7　Introduce Foreign Method（引入外加函数） 162 7.8　Introduce Local Extension（引入本地扩展） 164 第8章　重新组织数据 169 8.1　Self Encapsulate Field（自封装字段） 171 8.2　Replace Data Value with Object（以对象取代数据值） 175 8.3　Change Value to Reference（将值对象改为引用对象） 179 8.4　Change Reference to Value（将引用对象改为值对象） 183 8.5　Replace Array with Object（以对象取代数组） 186 8.6　Duplicate Observed Data（复制“被监视数据”） 189 8.7　Change Unidirectional Association to Bidirectional（将单向关联改为双向关联） 197 8.8　Change Bidirectional Association to Unidirectional（将双向关联改为单向关联） 200 8.9　Replace Magic Number with Symbolic Constant（以字面常量取代魔法数） 204 8.10　Encapsulate Field（封装字段） 206 8.11　Encapsulate Collection（封装集合） 208 8.12　Replace Record with Data Class（以数据类取代记录） 217 8.13　Replace Type Code with Class（以类取代类型码） 218 8.14　Replace Type Code with Subclasses（以子类取代类型码） 223 8.15　Replace Type Code with State/Strategy（以State/Strategy取代类型码） 227 8.16　Replace Subclass with Fields（以字段取代子类） 232 第9章　简化条件表达式 237 9.1　Decompose Conditional（分解条件表达式） 238 9.2　Consolidate Conditional Expression（合并条件表达式） 240 9.3　Consolidate Duplicate Conditional Fragments（合并重复的条件片段） 243 9.4　Remove Control Flag（移除控制标记） 245 9.5　Replace Nested Conditional with Guard Clauses（以卫语句取代嵌套条件表达式） 250 9.6　Replace Conditional with Polymorphism（以多态取代条件表达式） 255 9.7　Introduce Null Object（引入Null对象） 260 9.8　Introduce Assertion（引入断言） 267 第10章　简化函数调用 271 10.1　Rename Method（函数改名） 273 10.2　Add Parameter（添加参数） 275 10.3　Remove Parameter（移除参数） 277 10.4　Separate Query from Modifier（将查询函数和修改函数分离） 279 10.5　Parameterize Method（令函数携带参数） 283 10.6　Replace Parameter with Explicit Methods（以明确函数取代参数） 285 10.7　Preserve Whole Object（保持对象完整） 288 10.8　Replace Parameter with Methods（以函数取代参数） 292 10.9　Introduce Parameter Object（引入参数对象） 295 10.10　Remove Setting Method（移除设值函数） 300 10.11　Hide Method（隐藏函数） 303 10.12　Replace Constructor with Factory Method（以工厂函数取代构造函数） 304 10.13　Encapsulate Downcast（封装向下转型） 308 10.14　Replace Error Code with Exception（以异常取代错误码） 310 10.15　Replace Exception with Test（以测试取代异常） 315 第11章　处理概括关系 319 11.1　Pull Up Field（字段上移） 320 11.2　Pull Up Method（函数上移） 322 11.3　Pull Up Constructor Body（构造函数本体上移） 325 11.4　Push Down Method（函数下移） 328 11.5　Push Down Field（字段下移） 329 11.6　Extract Subclass（提炼子类） 330 11.7　Extract Superclass（提炼超类） 336 11.8　Extract Interface（提炼接口） 341 11.9　Collapse Hierarchy（折叠继承体系） 344 11.10　Form Tem Plate Method（塑造模板函数） 345 11.11　Replace Inheritance with Delegation（以委托取代继承） 352 11.12　Replace Delegation with Inheritance（以继承取代委托） 355 第12章　大型重构 359 12.1　Tease Apart Inheritance（梳理并分解继承体系） 362 12.2　Convert Procedural Design to Objects（将过程化设计转化为对象设计） 368 12.3　Separate Domain from Presentation（将领域和表述/显示分离） 370 12.4　Extract Hierarchy（提炼继承体系） 375 第13章　重构，复用与现实 379 13.1　现实的检验 380 13.2　为什么开发者不愿意重构他们的程序 381 13.3　再论现实的检验 394 13.4　重构的资源和参考资料 394 13.5　从重构联想到软件复用和技术传播 395 13.6　小结 397 13.7　参考文献 397 第14章　重构工具 401 14.1　使用工具进行重构 401 14.2　重构工具的技术标准 403 14.3　重构工具的实用标准 405 14.4　小结 407 第15章　总结 409
第三章 代码的坏味道（一）
Huaerge的专栏
10-25 607
3.1 Duplicated Code (重复的代码) 问题一：同一个class内的两个函数含有相同的表达式(expression). 解决办法：采用Extract Method(110)提炼出重复的代码，然后让这两个地点都调用被提炼出来的那一段代码。 问题二：两个互为兄弟(sibling)的subclasses内含相同表达式 解决办法：对两个classes都使用Extract Method(110)，然后再对被提炼出来的代码使用Pull Up Method(332),将它推入s
重构技术导读-《重构 改善既有代码的设计》
阿利在努力
03-31 813
《重构技术导读》 李超利 2018.03.28 任何一个傻瓜都能写出计算机可以理解的代码。唯有写出人类容易理解的代码，才是优秀的程序员。 《重构 改善既有代码的设计》重构序言 所谓的重构其实是这样的一个过程，在不改变代码外在行为的前提下，对代码做出修改，以改进程序的内部结构。重构是一种经千锤百炼形成的有条不紊的程序整理方法，可以最大限度地减少整理过程中引入的错误的几率。本质上说，重构...
代码坏味道 之 10 switch 惊悚现身 switch statments
giantmfc123
04-15 700
《重构：改善既有代码的设计》中提到过一些代码的坏味道，针对这些坏味道，需要进行重构。 switch 惊悚现身 switch statments 问题1：同样的switch散步于不同地点，如果要添加一个新的case句子，就要找到所有的switch 并修改它们。 解决方案：使用多态来替换switch。 解决方案：switch语句常常根据类型码进行选择，如果与该类型码相关的函数或类，使用extr...
《重构 改善既有代码的设计 1》重构原则
学Java，找哪吒
12-20 8489
前言 重构 既有代码的设计，一本经典神书，两年前入手，一年前看了一半，感觉一般般，今天起，再次拜读，希望会有不一样的收获！ /** * @startTime 2020-12-16 23:22 * @endTime 2020-12-16 23:59 * @startPage 1 * @endPage 55 * @efficiency 56/1 = 56页/天 * @needDays 412/56 = 7天 * @overDay 2020-12-16 + 7天 = 2020-12-22 */ 第
Eclipse重构——Move Method(I)
crylearner的专栏
04-11 2550
Motivation 出现依恋情节或者职责不清，应将行为移动到正确的类中。 Mechanics 1  检查源函数中所使用一切特性（包括field和函数） 2  检查子类和父类是否也定义了该函数 3  先委托，然后根据实际情况，决定是否将对源函数的调用替换为对目标函数的调用。 Eclipse refactor菜单下直接有Move 选项，可以直接使用该选项完成Move Me
在对象之间搬移特性之一 ：Move Method（搬移函数）
yuwei629的专栏
05-03 1042
你的程序中，有个函数与其所驻class之外的另一个class进行更多交流：调用后者，或被后者调用。 在该函数最常引用（指涉）的class中建立一个有着类似行为的新函数。将旧函数变成一个单纯的委托函数（delegating method），或是将旧函数完全移除。 动机（Motivation） 「函数搬移」是重构理论的支柱。如果一个class有太多行为，或如果一个class与
重构技术示例：02.移动方法(Move Method)
m0_47721810的博客
06-15 546
函数应该放在它所使用的数据的所属对象内 初始代码 public class Customer { private String name; private Vector _rentals = new Vector(); public Customer(String name) { this.name = name; } public void addRental(Rental rental) { _rentals.add(rent
重构，改善现有代码——代码坏味道
02-19
该文档是以前整理的笔记本，主要是针对代码坏问道的一些描述和一些解决办法。东西都是摘录的，虽然距离现在差多十几年，但是感觉还是可用的，所以分享一下。
重构-第3章 代码的坏味道-读书笔记
04-07
NULL 博文链接：https://aqxiebin.iteye.com/blog/1579688
Move Method（搬移函数）
q351477的博客
07-09 1428
动机 “搬移函数”是重构理论的支柱。如果一个类有太多行为，或如果一个类与另一个类有太多合作而形成高度耦合，我就会搬移函数。通过这样的手段，可以使系统中的类更简单，这些类最后也将更干净利落地实现系统交付的任务。 做法 检查源类中被源函数所使用的一切特性（包括字段和函数），考虑它们是否也该搬移（如果某个特性只被你打算搬移的那个函数用到，就应该将它一并搬移。如果另有其他函数使用了这个特性，你可以考虑将使用该特性的所有函数一起搬移。有时候，搬移一组函数比逐一搬移简单些）。 检查源类的子类和超类，看看是否有该函数的
重构对象-Inline Class将类内联化四
Bruce小鬼
03-17 684
正好与相反。如果一个类不再承担足够责任、不再有单独存在的理由（这通常是因为此前的重构动作移走了这个类的责任），我就会挑选这一“萎缩类”的最频繁用户（也是个类），以Inline Class (154)手法将“萎缩类”塞进另一个类中。
《重构》（笔记二）
twlssl的专栏
04-22 369
第六章 重新组织函数 6.1.Extract Method（提炼函数）（110） 你有一段代码可以被组织再一起并独立出来。 将这段代码放进一个独立函数中，并让函数名解释该函数的用途。 动机：简短而良好命名的函数。 做法：创建一个新函数（“做什么来命名”）。 将提炼出来的代码从原函数复制到新建的目标函数中。 仔细检查提炼出的代码，检查“作用域限于原函数”的变量。 检查是否有局部变量的
重构：坏味道
a71143的博客
11-26 164
坏味道（smell） 常用的重构手法（Common Refactoring） Alternative Classes with Different Interfaces, p85 Rename Method (273), Move Method (142) Comments, p87 Extrac...
重构笔记——搬移函数
热门推荐
皮斯特劳沃
01-13 1万+
本文是在学习中的总结，欢迎转载但请注明出处：http://blog.csdn.net/pistolove/article/details/42679983         我们都知道，类往往因为承担过多的责任而变得臃肿不堪。这种情况下，一般会使用"提炼类"这种手法将一部分责任分离出去。如果一个类变得"不负责任"，一般会使用“内联类”这种手法将它融入另一个类。如果一个类使用了另一个类，一般会运用"隐藏委托关系"手法将这种关系隐藏起来通常是有帮助的。有时候隐藏委托关系会导致拥有者的接口经常性地变化，
代码的坏味道之十 ：Switch Statements（switch惊悚现身）
yuwei629的专栏
05-02 2316
面向对象程序的一个最明显特征就是：少用switch (或case）语句。从本质上说， switch语句的问题在于重复（duplication）。你常会发现同样的switch语句散布 于不同地点。如果要为它添加一个新的子句，你必须找到所有switch语句 并修改它们。面向对象中的多态（polymorphism ）概念可为此带来优雅的解决办法。 大多数时候，一看到switch语句你就应该考虑以「
C++中如何自己封装一个Callable
最新发布
JAN6055的博客
05-04 363
有时候静态编译太不灵活，我们需要更灵活的运行时操作。又或真假设你在开发一个脚本，想注册本地的C++函数到脚本语言的标准库中。例如gdscript的Callable。下面是一个我的一个简单的实现。我们假设脚本语言中的变量类型是std::any。根据情况不同实现细节也可能不同。
重构与模式中有哪些代码的坏味道
04-12
对于重构与模式中代码的坏味道，常见的有以下几种： 1. Duplicated Code（重复代码）：相同的代码出现在多个地方，导致代码维护和修改困难。 2. Long Method（长方法）：函数或方法过长，难以阅读和理解。 3. ...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值