大话重构读书笔记——实践篇一

第一步: 从分解大函数开始

1. 什么是大函数?

大函数就是那些业务逻辑特别复杂、程序代码特别多、一提起来就让人头疼不已的超级方法。超级大函数很难让人读懂,更难于维护与变更,毫无疑问是软件退化的重灾区。

2. 如何解决超级大函数问题?

最有效的办法就是分解,按照功能一步一步分解,还原其应有的优化结构。这个过程我们常用的方法叫“抽取方法”。重构是一个探索的过程。

3.抽取方法:

  a. 将代码原子化时,为该函数取个易懂的名称。起初我们对这段代码的理解可能不那么深,因此往往选择用结果变量为其命名,随着我们对代码的深入理解,可以运用“重命名方法”根据代码意图重新为其命名。

  b. 被抽走的代码一定是功能内聚的,也就是说它们执行的是一个说得清道得明、清楚明确的功能。同时,它一定是只执行一个清晰的功能。

  c. 提高代码复用成为了代码优化的一个重要内容,因此,重复代码也是抽取函数的重要标志。

  d. 一些块操作的语句,如条件语句、循环语句、try语句,都可能成为抽取函数的标志。最典型的就是if语句,包含在if语句中的常常是一个相对独立的功能。

4. 常见问题

  a. 最大的困难,就是如何处理抽取函数与原函数的数据交换,即函数参数的设定。

  b. 若需要多个返回值时的处理

  c. 抽取方法的命名问题

第二步: 拆分大对象

1. 面对超级大函数我们采取的办法是拆分,以功能为核心将其拆分成一个一个独立的函数。

2. 以职责驱动设计思想为核心,调整我们的程序结构,构建高内聚、低耦合的软件系统。

3. 什么是职责驱动设计?

职责驱动设计就是要求我们设计的所有类和接口都要有自己的职责定义。而每个类和接口内部的所有方法和属性都是围绕着该职责来进行的,是高度相关的。

4. 我们判断功能之间是否相关的一个非常重要的原则,就是它们是否是引起软件变更的同一个原因。

5. 拆分大对象的过程

将原对象中的某些方法移动到其他对象中,这个方法称作“抽取类”。其移动原则就是职责驱动设计。

6. 如何判断一个类中是否有跟自己职责不相关的行为?

  a. 分析领域模型:需求分析后期、设计开发初期应当完成的一项模型分析。站在用户的角度,分析业务领域相关的事物、事物的属性、事物拥有的行为以及事物之间的关系。我们对领域模型的分析,是确保我们软件系统的设计能够与真实世界相对应的一种保障。

  b. 分析业务变更原因:一个职责就是软件变化的一个原因,这也是软件设计原则SRP,单一职责原则的精髓之所在。在设计时,应当将以上业务抽取出来分配给应该拥有该职责的类。

  c. 寻找信息专家

7. 什么是信息专家?

信息专家就是软件系统中拥有某些有用数据的业务对象。

8. 当业务需求在许多地方是相同的时候,容易造成大量重复代码,应该如何处理?

  a. 第一步是划分相同业务及不同业务,落实到程序就是相同代码和不同代码。将不同代码保留在原程序中,相同代码抽取成新的函数。

  b. 第二步是拆分,将相同业务类拆分后形成抽象类于正常类间的继承关系。该过程称为“抽取父类”。

9. 大对象拆分的原则是面向职责的分析与设计,但实际工作中情况并不总是如此。

时间: 2024-11-14 13:04:33

大话重构读书笔记——实践篇一的相关文章

大话重构读书笔记——实践篇二

第三步:提高代码复用率 经过重构的第一步,我们将令人头疼的大函数分解成了大小适中的一个个小函数,经过重构第二步,我们将无所不能的大对象拆分成了功能内聚的一个个小对象.随后,我们需要考虑的问题就是优化我们的代码了. 1. DRY原则:Don't Repeat Yourself. 2. 如何识别相似或相近功能? a. 处理同一流程中某个环节而采用的不同方式,如购物付款方式不同,但结果相同,此时,可将付款结果合并成一个类或方法,将不同的付款流程抽象成一个接口下的多个实现类. b. 在不同业务中某个功能

大话重构读书笔记——进阶篇二

我们怎样拥抱变化 软件系统应对快速变化的终极利器,是以领域模型为核心建立的软件架构. 软件发展的基本特征就是变更,不论是源于需求的变更还是源于技术的变更. 运用领域模型,通过图形化的分析,可以让我们快速掌握真实世界的规律,进而指导软件的设计与开发.领域模型是联系真实世界与软件世界的枢纽,首先通过对真实世界的分析绘制领域模型,然后照着领域模型设计软件,就可以保证真实世界与软件世界的对应关系. 一般来说,领域模型是基于用户业务领域知识的分析,这些领域知识源于用户对软件系统的业务需求,却超越了业务需求

大话重构读书笔记——进阶篇一

什么时候重构? 重构是一种习惯,一种编程习惯.这种习惯让我们迅速由菜鸟转变为大牛,可以编写出高质量.优秀的程序. 问题的关键就是降低修改成本与风险的方法,而这个方法就是系统重构. 走出重构的第一步对每一个人来说都是一次心灵的考验,甚至许多人总是徘徊于路口踌躇不前,但一旦跨出去了,它将成为你生命的一部分. 没有经过重构的,原生态的代码是没办法复用的,当我们发现代码需要复用时,切忌不要使用过去那种简单粗暴的复制黏贴,合理运用重构方法,加之以仔细.认真.即时的测试,就可以保证既有代码的正确,并使整个系

大话重构读书笔记——保险索下的系统重构

1. 保险索是什么? 保险索就是每次重构后正确的测试方法. 2. 什么是程序代码正确的测试方法? 在不同的场景标准是不一样的.但与其他测试不同,系统重构在测试代码正确性方面有自己独特的方法,那就是不改变软件外部行为. 3. Mock 在测试过程中,对于某些不容易构造或不容易获取的对象,用一个虚拟对象来替代以使测试得以继续的方法 4. 自动化测试不是银弹,不是所有代码都适合自动化测试: a. 与web容器或其他设备驱动相关的代码是不适合自动化测试的,因为我们在测试的时候不希望去启动web容器或其他

大话设计模式读书笔记2——策略模式

策略模式是一种定义一系列算法的方法,从概念上来看,所有这些算法完成的都是相同的工作,只是实现不同,它可以以相同的方式调用所有的算法,减少了各种算法类与使用算法类直接的耦合. UML 图: 根据<大话设计模式>——第二章 商场促销这个案例代码来简单的记录一下策略模式的使用方式: /// <summary> /// 现金收费抽象类 /// </summary> public abstract class CashSuper { /// <summary> ///

大话数据结构读书笔记

大话数据结构读书笔记 编程基础: 数据结构 算法 1 线性表 //顺序储存结构的结构代码: #define MAXSIZE 20//储存空间的起始分配量 typedef int ElemType;//ElemType类型根据实际类型而定,这里假设是int typedef struct{ ElemType data[MAXSIZE];//数组储存元素,最大值为MAXSIZE int length;/线性表当前长度: }SqList; //顺序存储结构需要三个属性: //1存储空间的起始位置:数组d

大话设计模式读书笔记1——简单工厂模式

最近几日,重温了一下<大话设计模式>这本书,当时读的仓促,有很多没有注意的地方,现在仔细翻看起来,发现这值得细细品味的一本书!! 好东西就要记下来!!! 第一章笔记:从一个简单的计算器程序来看简单工厂模式. 变化的地方就要封装,用一个单独的类来做创造实例的过程这就是工厂. UML图: /// <summary> /// 运算类 /// </summary> public class Operation { public double Number1 { get; set

大话设计模式读书笔记2——单例模式

单例模式是一种常用的软件设计模式.在它的核心结构中只包含一个被称为单例类的特殊类.通过单例模式可以保证系统中一个类只有一个实例而且该实例易于外界访问,从而方便对实例个数的控制并节约系统资源.如果希望在系统中某个类的对象只能存在一个,单例模式是最好的解决方案. 我们来看一下单例模式下的饿汉模式代码: /// <summary> /// 饿汉模式 /// </summary> public class Singleton { //私有的构造器 private Singleton() {

大话设计模式读书笔记--设计模式总结

前言 大话设计模式看了两遍,之前看过一遍,理解的不深刻, 这次用了一个月多点的时间再次温习,利用下班后的时间回来学习,把学习心得记录下来,加深了对面向对象的理解 之前是看到一个需求搞清楚业务流程之后立刻就去做了,很少从设计层面的角度考虑,现在在开发程序时,开始有了设计的思想,也有了达到可维护,可复用,可扩展目的具体的实现方法 每当看到经过优化代码的效果时,就想起一句话:精彩的代码是如何想出来的,比看到精彩的代码更加令人兴奋 下面是用自己的话进行的总结,以便加深记忆和理解 创建型 抽象工厂 定义: