《重构:改善既有代码的设计》-学习笔记二(+实战解析

return finalPrice;

}

private double discountedPrice ( int discountLevel) {

if (discountLevel == 2) return getBasePrice() * 0.1;

else return getBasePrice() * 0.05;

}

private int getBasePrice(){

return _quantity * _itemPrice;

}

优化1,2,3,4步骤,去掉discountLevel参数,独立函数返回值要为discountLevel 最后赋值的值

public double getPrice() {

double finalPrice = discountedPrice ();

return finalPrice;

}

private double discountedPrice () {

if (getDiscountLevel() == 2) return getBasePrice() * 0.1;

else return getBasePrice() * 0.05;

}

private double getDiscountLevel(){

if (_quantity > 100) return 2;

else return 1;

}

private double getBasePrice(){

return _quantity * _itemPrice;

}

从上述代码可看出,getPrice主函数finalPrice参数已经可以直接优化了。

public double getPrice() {

return discountedPrice ();

}

可以发现getPrice函数直接调用discountedPrice 函数,所以可用Inline Method(将函数内联化)

合并这两个函数

public double getPrice() {

if (getDiscountLevel() == 2) return getBasePrice() * 0.1;

else return getBasePrice() * 0.05;

}

private double getDiscountLevel(){

if (_quantity > 100) return 2;

else return 1;

}

private double getBasePrice(){

return _quantity * _itemPrice;

}

我们只关心主函数的计算过程,一些过程性的计算,像上述这样,独立函数出来。代码逻辑会十分清晰,可读性很好。

存在一个重要的例外。如果明显不希望封装的对象与主对象之间存在某种依赖关系,可以把参数数据从封装对象中抽出来,当成函数的参数。也是合理的。

但是要注意,当参数列太多或者参数变化频繁时,就要考虑优化了。

Divergent Change(发散式变化)

===========================

你发现你想要修改的一个函数,却必须同时修改诸多不相关的函数,例如,当你想要添加一个新的产品类型,你需要同步修改对产品查找,显示,排序的函数。

有以上这些情况的话,就需要优化代码了

针对某一外界 变化的所有相应修改,都只应该发生在单一class中,而这个新class内的所有内容都应该反应该外界变化。

通过提炼类的方式,找出因着某特定原因而造成的所有变化,独立类。

问题原因:

通常,这种发散式修改是由于编程结构不合理或者“复制-粘贴式编程”。

优化思路


运用提炼类拆分类的行为。

如果不同的类有相同的行为,你可以考虑通过继承来合并类和提炼子类。

效果:

提高代码组织结构

减少重复代码

Shotgun Surgery(散弹式修改)

==========================

注意霰弹式修改 与 发散式变化 区别 : 发散式变化是在一个类受多种变化影响, 每种变化修改的方法不同, 霰弹式修改是 一种变化引发修改多个类中的代码;****

优化思路


1、代码集中到某个类中 : 使用 Move Method(搬移函数) 和 Move Field(搬移字段) 把所有需要修改的代码放进同一个类中;

2、 代码集中到新创建类中 : 没有合适类存放代码, 创建一个类, 使用 Inline Class(内联化类) 方法将一系列的行为放在同一个类中;

3、造成分散式变化 : 上面的两种操作会造成 Divergent Change(分散式变化), 使用Extract Class 处理分散式变化;

Feature Envy(依恋情结)

======================

函数对某个class的兴趣高过对自己所处之 class的兴趣。无数次经验里,我们看到某个函数 为了计算某值,从另一个对象那儿调用几乎半打的取值函数。

影响:数据和行为不在一处,修改不可控。

解决方案:让数据和行为在一起,通过 Extract Method(提炼函数)和Move Method(搬移函数)的方法来处理,这函数到该去的地方。

例子:参考一个优秀博主提供的例子

https://blog.csdn.net/wxr0323/article/details/7884168

优化思路


1、函数全部数据来自另外一个类

做法:将数据提炼到一个独立函数中  Move method。

2、函数部分数据来自另外一个类

做法:将“部分数据”提炼到一个函数中 Move method。

3、函数的数据来自不同类

做法:将数据分类,分别提炼各自的独立的函数,在将这些函数移到各自属于的类中。

Data Clumps(数据泥团)

=====================

数据泥团指的是经常一起出现的数据,比如每个方法的参数几乎相同,处理方式与过长参数列的处理方式相同,用_Introduce Parameter Object(引入参数对象)将参数封装成对象。_

优化思路


1、观察经常一起出现的数据;

2、通过提炼类的方法,放到属于他们的对象中;

3、用对象来代替这些数据;

4、编译测试。

eg:未优化代码

例子参考一个优秀博主提供的例子

https://blog.csdn.net/geniusxi/article/details/78581542

public class Car{

// 奔驰

public void printBenz(String brand, String model, Integer price, double power) {

printBasicInfo(brand, model, price, power);

getTax(power, price);

}

// 宝马

public void printBmw(String brand, String model, Integer price, double power) {

printBasicInfo(brand, model, price, power);

getTax(power, price);

}

// 提炼打印基本信息方法

private void printBasicInfo(String brand, String model, Integer price, double power) {

System.out.println(“品牌” + brand);

System.out.println(“型号:” + model);

System.out.println(“动力:” + power);

System.out.println(“价格:” + price);

}

// 提炼计算税费的方法

private double getTax(double power, Integer price){

double salePrice = price;

if (price > 200000) {

salePrice = price * 0.98;

}

if (power <= 1.6) {

return salePrice * 0.05;

} else {

return salePrice * 0.1;

}

}

}

优化1,2步骤

上面代码方法中,我们发现方法的参数大致相同,这时候我们可以用参数对象化来处理。

public class CarEntity {

private String brand;

private String model;

private Integer price;

private Double power;

public String getBrand() {

return brand;

}

public void setBrand(String brand) {

this.brand = brand;

}

public String getModel() {

return model;

}

public void setModel(String model) {

this.model = model;

}

public Integer getPrice() {

return price;

}

public void setPrice(Integer price) {

this.price = price;

}

public Double getPower() {

return power;

}

public void setPower(Double power) {

this.power = power;

}

}

优化3,4步骤

// 奔驰

public void printBenz(CarEntity carEntity) {

printBasicInfo(carEntity);

// 计算税费

getTax(carEntity);

}

// 宝马

public void printBmw(CarEntity carEntity) {

printBasicInfo(carEntity);

getTax(carEntity);

}

private void printBasicInfo(CarEntity carEntity) {

System.out.println(“品牌” + carEntity.getBrand());

System.out.println(“型号:” + carEntity.getModel());

System.out.println(“动力:” + carEntity.getPower());

System.out.println(“价格:” + carEntity.getPrice());

}

// 计算税费

private double getTax(CarEntity carEntity) {

// 打折后价格

double salePrice = carEntity.getPrice();

if (carEntity.getPrice() > 200000) {

salePrice = carEntity.getPrice() * 0.98;

}

if (carEntity.getPower() <= 1.6) {

return salePrice * 0.05;

} else {

return salePrice * 0.1;

}

}

经过以上的优化,代码就更加健壮了。

Primitive Obsession(基本型别偏执)

===============================

写代码时总喜欢用基本类型来当参数,而不喜欢用对象。当要修改需求和扩展功能时,复杂度就增加了。

优化思路


1、如果你有一组应该总是被放在一起的属性或参数,可以用提炼类的方式来处理;

2、如果你在参数列中看到多个基本型数据,可以引用参数对象;

3、如果你发现自己正从array中挑选数据,可以用对象取代数组。

优化步骤1和2之前的例子说明了很多次,不再重复。

优化步骤3

第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
一直很喜欢重构这本书,但是由于自己记性不太好,书看过之后其中的方法总是记不住,于是想如果有电子版的重构书就好了,工作中遇到重构的问题可以随时打开查阅。在网上搜索了许久,发现重构这本书有英文chm版本的,而中文版的电子书只有扫描的PDF版本,用起来非常不方便。于是萌生想做一本重构工具书的想法,本来打算自己重新将重构书的内容再整理归类一下,后来发现原书的目录编排就很适合做工具书,包括坏味道分类,重构手法归类等,都有了一个比较系统的整理。因此,我利用空余时间制作了这样的一本中文的chm版重构,希望对大家有所帮助,也算对中国软件业做出一点小小的贡献。 本书基本上是取自”重构”中文版一书的内容,但格式上参照的是chm英文版的格式,还有一些格式小修改,比如第一章的重构前后代码对比。因为时间匆促,个人能力有限,本书难免存在一些缺漏,如果大家发现有问题,随时可以给我发邮件,我会尽快更新错误的内容。 最后再次感谢几位大师 Martin Fowler、Kent Beck等,还有翻译的侯捷和熊节先生,为我们带来这么精彩的一本书。谢谢。 免责声明:本书仅供个人学习研究之用,不得用于任何商业目的,不得以任何方式修改本作品,基于此产生的法律责任本人不承担任何连带责任。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值