重构:简化函数调用

1、将查询函数和修改函数分离

  情景:某个函数既返回对象状态值,又修改对象状态

    任何有返回值的函数,都不应该有看得到的副作用

2、以明确函数取代参数

  情景:你有一个函数,其中完全取决于参数值采取不同的行为

  方案:针对该参数的每一个可能值,建立一个独立函数;

3、保持完整对象

  情景:从某个对象中取出若干值,作为某一次函数调用时的参数

  方案:改为传递整个对象

4、以函数取代参数

  情景:对象调用某个函数,并将所得结果作为参数,传递给另一个参数。而接受该参数的函数本身也能调用前一个函数

  方案:让参数接受者去除该项参数,并直接调用前一个函数

5、引入参数对象

  情景:某些参数总是很自然地同时出现

  方案:以一个对象取代这些参数

6、以工厂函数取代构造函数:

  情景:希望在创建对象时不仅仅是做简单的建构动作

7、封装向下转型

  情景:某个函数返回的对象,需要由函数调用者执行向下转型(downcast)

  方案:将向下转型动作移到函数中

8、以异常取代错误码

  情景:某个函数返回一个特定的代码,用以表示某种错误情况

  方案:改用异常

时间: 2024-08-10 23:19:44

重构:简化函数调用的相关文章

[代码重构]简化函数调用

在对象技术中,最重要的概念莫过于“接口”,容易被理解和被使用的接口是开发良好面向对象软件的关键.本章介绍的重构手法是用来使接口变得更简洁易用的. 简化函数调用 1. 重构手法 1.1 函数改名 概要: 函数的名称未能揭示函数的用途. 修改函数名称. 动机: a. 让函数名称准确表达它的用途 示例: 重构前: public String getTelephoneNumber() { return mOfficeAreaCode + "-" +mOfficeNumber; } 重构后: /

重构摘要10_简化函数调用

<重构-改善既有代码的设计>Martin Fowler 摘要: 第十章 简化函数调用 Rename Method 函数改名 改一个自表达的名字吧!骚年 Add Parameter 添加参数 某个函数需要从调用端得到更多信息. 为此函数添加一个对象参数,让该对象代价函数所需信息.并发编程大多数参数很长,不放在一个类中,因为这样你可以保证传递给函数的参数都是不可修改的. Remove Parameter 移除参数 移除不必要的某个参数 Separate Query from Modifier 将查

重构手法(二)之简化函数调用

1.Rename Method(函数改名) 2.Add Parameter(添加参数) 3.Remove Parameter(移除参数) 4.Separate Query form Modifier(将查询参数和修改参数分离) 5.Parameterize Method(令函数携带参数) 6.Replace Parameter with Explicit Methods(以明确函数取代参数) 7.Preserve Whole Object(保持对象完整) 8.Replace Parameter

重构 - 简化方法的调用

Rename Method 方法名是对方法体的抽象,是化繁为简的支柱 Add Parameter 注意:在添加参数的时候,先考虑是否可以把数据移动到方法所在的类中 Remove Parameter Separate Query from Modifier 目标:查询的方法不要做修改 Parameterize Method Replace Parameter with Explicit Methods 现象:一个方法被分成几部分,参数值决定要执行哪个部分: 改进:把这个方法替换成多个方法,每个方法

重构-----改善既有代码的设计

1重构原则 1.1 定义: 1).调整软件内部结构,目的是在不改变软件软件可查行为前提下,提高其可理解性,降低其修改成本. 2).使用一系列重构准则,在不改变软件可查行为前提下,调整其结构 1.2 何时重构 1).三次法则 2).添加功能时 3).修补错误时 4).复审代码时 1.3 何时不该重构 1).代码太乱,重构效率低于重写效率时 2).项目接近期限时停止重构 2.代码的坏味道 2.1 Duplicated Code 2.2 Long Method 2.3 Large Class 2.4

《重构—改善既有代码的设计》笔记

为什么要重构 改进软件设计,消除重复代码 保持代码易读.易修改 提高编程速度(良好设计师维持软件开发速度的根本) 发现BUG 什么时候重构 事不过三,三则重构(三次法则) 添加功能时一并重构 修改错误时一并重构 复审代码时一并重构 问题代码 重复的代码 过长函数 过大类 过长参数列表 发散式变化 霰弹式修改 依恋情节 数据泥团 基本型别偏执 switch惊悚现身 冗赘类 夸夸其谈未来性 令人迷惑的暂时值域 过度耦合的消息链 中间转手人 狎昵关系 异曲同工的类 不完美的程序库类 纯稚的数据类 被拒

阅读《重构》的一些思考

终于在断断续续的情况下把这本经典巨作看完了. 这本书的全名叫做<重构-改善既有代码的设计>,原有的代码设计存在不足的地方让人感到不好维护,所以才需要去改善既有代码的设计,其实听起来会不会有点亡羊补牢的感觉?这里也提醒了我们一点:从设计代码的初期就要深思熟虑,虽然后续的改动基本无法避免,但良好的初期设计将对后续维护提供帮助.重构不是最终目的,我们的目的是让代码变得更好. 关于书的内容组织 不得不称赞的一点是作者的写作思路是非常清晰的.整本书的开始是由一个小型案例讲起,让读者了解重构是一项什么样的

重构笔记——代码的坏味道(上)

在重构入门篇中,简单地介绍了重构的定义.为何重构.何时重构等.我想对于重构是如何运作的,你已经有了较好的理解了.但是对于代码中的坏味道,你可能 知道的并不多.坏味道可能是无形中产生的,也可能是开发人员偷懒造成的,还可能是其它某些因素导致的.不管怎么样,代码中的坏味道对程序没有半点好处,它 会促使程序腐烂,甚至变质.对于开发人员,真的是很有必要对这些坏味道进行了解和熟悉,理解它们产生的场景.针对当前程序,发现坏味道,对代码进行重构, 以消除坏味道,提高代码质量,提高自己水平. 下面让我们一起来熟悉

《重构》读书笔记 与 Eclipse 重构功能使用

第二章 重构原则 重构是什么? 重构(名词):对软件内部结构的一种调整,目的是在不改变[软件之可察行为]前提下,提高其可理解性,降低其修改成本. 重构(动词):使用一系列重构准则(手法),在不改变[软件之可察行为]前提下,调整其结构. 两顶帽子:添加新功能和重构,不能同时进行. 为何重构? 改进软件设计:可能设计之初根据已有需求,是世界上最优的设计.但是可能过程中增删许多功能,原有设计已经不满足现有需求. 使软件更易理解: 通常多添加注释不一定是好的选择,因为可能代码会被别人修改,而忽略修改注释