坏味道--被拒绝的馈赠(Refused Bequest) 特征 子类仅仅使用父类中的部分方法和属性.其他来自父类的馈赠成为了累赘. 问题原因 有些人仅仅是想重用超类中的部分代码而创建了子类.但实际上超类和子类完全不同. 解决方法 如果继承没有意义并且子类和父类之间确实没有共同点,可以运用 以委托取代继承(Replace Inheritance with Delegation) 消除继承. 如果继承是适当的,则去除子类中不需要的字段和方法.运用 提炼超类(Extract Superclass) 将

重构第二式:搬移方法 (Refactoring 2: Move Method) 毋容置疑,搬移方法(Move Method)应该是最常用的重构手段之一,正因为太常用而且较为简单,以至于很多人并不认为它是一种很有价值的重构,但事实并非如此,在最初的代码诞生之后,有些方法可能会被放在一些不合适的地方,例如,一个方法被其他类使用比在它所在的类中的使用还要频繁或者一个方法本身就不应该放在某个类中时,我们应该考虑将它移到更合适的地方.搬移方法,顾名思义就是将方法搬移至合适的位置,如将方法搬移到更频繁地使用

2009年,Sean Chambers在其博客中发表了31 Days of Refactoring: Useful refactoring techniques you have to know系列文章,每天发布一篇,介绍一种重构手段,连续发文31篇,故得名“重构三十一天:你应该掌握的重构手段”.此外,Sean Chambers还将这31篇文章[即31种重构手段]整理成一本电子书, 以下是博客原文链接和电子书下载地址: 博客原文:http://lostechies.com/seanchamber

软件重构是改善代码可读性.可扩展性.可维护性等目的的常见技术手段.圈复杂度作为一项软件质量度量指标,能从一定程度上反映这些内部质量需求(当然并不是全部),所以圈复杂度往往被很多项目采用作为软件质量的度量指标之一. C语言开发的项目中,switch/case代码块是一个很容易造成圈复杂度超标的语言特性,所以本文主要介绍下降低switch/case圈复杂度的重构方法(如下图).switch圈复杂度优化重构可分为两部分:程序块的重构和case的重构.程序块重构是对代码的局部优化,而case重构是对代码

第5章 重构列表 5.1 重构的记录格式103 5.2 寻找引用点105 5.3 这些重构手法有多成熟106 第6章 重新组织函数 6.1 (P110)Extract Method(提炼函数) 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 T

准备下周分享会的内容,无意间看到.net版本的重构31天,花了两个小时看了下,可以看成是Martin Fowler<重构>的精简版 原文地址:http://www.lostechies.com/blogs/sean_chambers/archive/2009/07/31/31-days-of-refactoring.aspx 原文代码地址:https://github.com/schambers/days-of-refactoring 圣殿骑士写的.net版本的读书笔记地址:http://ww

什么时候需要重构,当你在项目代码里面嗅到这个味道的时候,就要进行重构.   首个介绍的味道是重复代码的味道.   它表现出来的特征是这些:   1.一个类里面,两个函数中,含有相同的代码,类似的代码:或者三个函数中,含有相同的代码,类似的代码.这是重复代码的味道.   2.两个互为兄弟的子类内含有相同的表达式.这也是重复代码的味道.   3.两个不相关的类,出现了重复代码.这也是重复代码的味道.     如何处理,如何重构   1.对于两个函数,出现重复代码,使用Extract Method方法

提炼为常量是从暂时变量高速提炼出静态常量,这也是我们经常使用的重构手段. 很多其它有用技巧请查看<AndroidStudio有用指南> 操作步骤: ➤ 菜单条: Refactor -> Extract -> Constant- ➤ 快捷键(Mac): option + Command + C 实例演示: 提炼常量之前: public void getInfo(){ String name = "老毕"; searchByName(name); print(nam

概述 Null Object 是Martin 大师提出的一种重构手段,其思想就是通过多态(派生一个Null对象)来减少逻辑(if … then …else)的判断. 而.NET中已经有Null Object 的使用原型了——“类型.Empty”. //1) String.Empty //2) return Enumerable.Empty<ModelValidationResult>(); //3) return GetRouteDataValue<IEnumerable<Rout

想象一下,当程序所有的业务逻辑都完成的时候,你可能还来不及喘口气,紧张的测试即将来临.你的Boss告诉你,虽然程序没问题,但某些方法为什么执行这么慢,性能堪忧.领会了Boss的意图之后,漫长的排查问题开始了.你会写日志,或者是其他工具来追踪原因.那么如何以一种优雅的形式,并且不侵入业务代码的形式来跟踪呢?这正是本文的内容. 跟踪问题 通过观察,你发现方法Do执行缓慢,可能有性能问题,因为这是一个线上的版本,你无法进行Debug,所以你通过日志的形式来追踪执行步骤: class Foo1 { vo

前言 从13年接触DDD之后开始做应用架构已经整整四个年头. 四年里关于DDD的感触良多,慢慢有了一些心得. 关于DDD的介绍已经有很多的文章和书籍,这里我推荐三本最重要的书籍. <领域驱动设计-软件核心复杂性应对之道>(DDD) <实现领域驱动设计>(IDDD) <领域驱动设计模式,原理与实践>(PPPDDD) 具体的DDD介绍这三本书已经很清楚了,但是学完这些之后我认为DDD才刚刚开始. DDD给我更多的是一种设计启发,无论是里面的战术设计,还是战略设计都可以展开到

之前买了一本书,叫<架构探险-从零开始写Java Web框架 >(不推荐购买-),一本标题党书籍!但是我很推崇作者写代码的方式,就是基于TODO的方式进行开发! 个人认为以基于TODO的方式进行开发,至少有如下几点优势: 有助于理解需求 有助于梳理业务流程 有助于任务拆解和代码封装 TODO即注释 更易于进入心流体验 同时还能避免如下两种情况: 下面我以Blog的创建流程为例,来演示基于TODO的开发方式,并说明为何基于TODO的开发方式有如上优势! 后端的开发框架请见Web开发框架推导! 流

clean code,顾名思义就是整洁的代码,或者说清晰.漂亮的代码,相信大多数工程师都希望自己能写出这样的代码. 也许这是个千人千面的话题,每个工程师都有自己的理解.比如我,从一个天天被骂代码写得烂的人,逐渐学习成长,到现在也能写的出“人模人样”的代码来了.这期间算是积累了一点经验心得,想和大家分享,抛砖引玉. 本文主要针对面向对象编程的clean code来阐述,面向过程代码的思路会比较不同,不在本文的讨论范畴. 代码整洁的大前提 代码大部分时候是用来维护的,而不是用来实现功能的 这个原则适

有大量的文章解释什么是设计模式,如何实现设计模式,网络上不需要再写一篇这样的文章.相反,在本文中我们更多的讨论什么时候用和为什么要用,而不是用哪一个和如何使用. 我将会为这些设计模式描绘不同的场景和案例,和提供一个简短的定义帮助你们中对这些指定的模式不熟悉的人.让我们开始吧. 这篇文章覆盖了Robert C. Martin书中提到的一些敏捷设计模式.这些设计模式都是最初由四人组在1994年定义和发表的设计模式的现代改写版.Martin的模式更多是对四人组模式的承接,能更好的与现在的编程技术协作.

有大量的文章解释什么是设计模式,如何实现设计模式,网络上不需要再写一篇这样的文章.相反,在本文中我们更多的讨论什么时候用和为什么要用,而不是用哪一个和如何使用. 我将会为这些设计模式描绘不同的场景和案例,和提供一个简短的定义帮助你们中对这些指定的模式不熟悉的人.让我们开始吧. 这篇文章覆盖了Robert C. Martin书中提到的一些敏捷设计模式.这些设计模式都是最初由四人组在1994年定义和发表的设计模式的现代改写版.Martin的模式更多是对四人组模式的承接,能更好的与现在的编程技术协作.

团队新来了个校招实习生静静,相互交流后发现竟然是我母校同实验室的小学妹,小学妹很热情地认下了我这个失散多年的大湿哥,后来... 小学妹:大湿哥,咱们项目里的 Controller 怎么都看不到参数校验处理的代码呀?但是程序运行起来,看到有是有校验的? 大湿哥:哦哦,静静,你看到 Controller 类和方法上的 @Validated,还有其他参数的 @NotBlank.@Size 这些注解了吗? 小学妹:看到了,你的意思是这些注解跟参数校验的处理有关系? 大湿哥:对呀!是不是觉得咱们项目上 C

定义 重构的定义:在不改变软件可观察行为的前提下,改善其内部结构. 其中,不改变软件行为,是重构最基本的要求.要想真正发挥威力,就必须做到“不需了解软件行为”. 如果一段代码能让你容易了解其行为,说明它还不是那么迫切需要被重构. 需要重构的代码,你只能看到其中的“坏味道”,接着选择手段消除这些“坏味道”,然后才有可能理解他的行为. 构建测试体系 确保每个类每个方法都有对应的测试代码.一套测试就是一套BUG检测器,能够大大缩减查找BUG所需时间. 编写测试代码最有效的时机,实在开始编程以前.能使你

第1章 重构, 第一个案例 1.1 起点 1.2 重构的第一步 1.3 分解并重组 statement() 1.4 运用多态取代与价格相关的条件逻辑 1.5 结语 第2章 重构原则 2.1 何谓重构 2.2 为何重构 2.3 何时重构 2.4 怎么对经理说 2.5 重构的难题 2.6 重构与设计 2.7 重构与性能 2.8 重构与性能 2.9 重构起源何处 第3章 代码的坏味道 3.1 Duplicated Code (重复代码) 3.2 Long Method (过长函数) 3.3 Large

好久没写代码了,终于好不容易接到了开发任务,一看时间还挺充足的,我就慢慢整吧,若是遇上赶进度,基本上直接是功能优先,完全不考虑设计.你可以认为我完全没有追求,当身后有鞭子使劲赶的时候,神马设计都是浮云,按时上线才是王道,毕竟领导是不会关注过程和代码质量的,领导只看结果,这也许就是我等天朝码农的悲哀. 需求:是这样的,要开发一个短信发送的模板,不同客户可能会使用不同的模板,而不同的客户使用的变量参数也是不同的.之前为了应急,线上已经完成了一个短信模板发送短信的功能,短信模板表也创建了,而且在表中已

作者:@狼狼的蓝胖子 网址:http://www.cnblogs.com/lrzw32/p/5100745.html 写CSS的同学们往往会体会到,随着项目规模的增加,项目中的CSS代码也会越来越多,如果没有及时对CSS代码进行维护,CSS代码不断会越来越多.CSS代码交错复杂,像一张庞大的蜘蛛网分布在网站的各个位置,你不知道修改这行代码会有什么影响,所以如果有修改或增加新功能时,开发人员往往不敢去删除旧的冗余的代码,而保险地增加新代码,最终的坏处就是项目中的CSS会越来越多,最终陷入无底洞.