文章吧-经典好文章在线阅读:《重构》读后感10篇

当前的位置:文章吧 > 经典文章 > 读后感 >

《重构》读后感10篇

2018-01-10 20:58:02 来源:文章吧 阅读:载入中…

《重构》读后感10篇

  《重构》是一本由Martin Fowler著作,中国电力出版社出版的平装图书,本书定价:68.00元,页数:464,文章吧小编精心整理的一些读者的读后感,希望对大家能有帮助

  《重构》读后感(一):重构可以帮你写出更好的代码

  《重构》是一本简单实用的好书,每个靠写代码领工资的软件工程师都应该读一读。运用重构技术可以帮你写出更好的代码—–这会让你和你同事阅读、修改代码时轻松很多。

  大学毕业后我用vim + C语言工作一年多,Visual Studio + C++工作两年半,现在用Eclipse + Java工作了一年半。我的感觉是Java较之C++可以更快地写出更好的代码,这其中的原因自然有很多。在我看来Eclipse自带的Refactoring工具在其中功不可没,它让代码重构变得轻松有趣、一键搞定。没装Visual Assistant的Visual Studio连提取个函数都得手工把代码拷来拷去,乏味无趣。谁说IDE不重要?工欲善其事必先利其器,好的工具绝对让你事半功倍

  本书写作于1999年,用的JDK版本是1.1,彼时Eclipse还没有诞生,代码重构时的做法还是一步一步按部就班地手工修改代码。现在Eclipse中的Refactoring菜单下已经集成了书中提到的众多常用重构手法,应该是从本书得到了不少借鉴

  附Refactoring菜单:

  Rename Alt + Shift + R

  Move Alt + Shift + V

  Change Method Signature Alt + Shift + C

  Extract Method Alt + Shift + M

  Extract Local Variable Alt + Shift + L

  Inline Alt + Shift + I

  Extract Constant

  Convert Anonymous Class to Nested

  Move Type to New File

  Convert Local Variable to Field

  Extract Superclass

  Extract Interface

  Use Supertype Where Possible

  ush Down

  ull Up

  Extract Class

  Introduce Parameter Object

  Introduce Indirection

  Introduce Factory

  Introduce Parameter

  Encapsulate Field

  以上所有的重构操作都可以Ctrl + Z一键撤销

  以下是读书笔记:

  第一章 重构,第一个案例

  JUnit:测试在重构中非常重要,我们需要依赖测试检查是否引入新bug。

  VN、单元测试、回归测试

  小幅重构、及时测试,易于发现错误

  自动化重构工具:Eclipse

  代码应该表现自己目的,变量名称是代码清晰关键

  唯有写出人类容易理解的代码,才是优秀的程序员

  重构手法:

  Extract Method

  Move Method

  委托(delegate)

  保留旧函数,让它内部调用新函数(向后兼容)

  Replace Temp with Query

  Query Method(可以加入cache机制)

  运用多态(polymorphism)代替switch语句

  Replace Type Code with State/Strategy

  Replace Conditional with Polymorphism

  第二章 重构原则

  1,所谓程序设计就是与计算机交谈,所以编程的核心就是『准确地说出你的意思』。

  2,利用重构来帮助理解不熟悉的代码,重构是理解软件设计的最快方式

  3,『我不是个伟大的程序员:我只是有着很多好习惯的优秀程序员而已』

  4,事不过三,过则重构。

  5,每次提交代码前都找人Code review。

  6,间接层的价值

  允许逻辑共享(Pull up method, Pull up field)

  分离“意图”与“实现”

  封装变化

  将条件逻辑加以编码( 多态)

  7,哪怕你完全了解系统,也请使用性能测量工具来测试它的性能,不要臆测。(Benchmark)

  第三章 代码的坏味道

  1, Duplicated Code(重复的代码)

  Extract Method, Pull up Method, Template Method模式

  2, Long Method(过长函数)

  Rename Method; Extract Method;

  3, Large Class(过大类)

  Extract Class; Extract SubClass; Extract Interface;

  4, Long Parameter List(过长参数列表)

  Replace Parameter With Method; Introduce Parameter Object

  5, Divergent Change(发散式变化)

  找出所有同一原因引起变化, 运用Extract Class将它们提炼到另一个Class 中

  6, Shotgun Surgery(霰弹式修改)

  运用Move Field, Move Method将所有需要修改的代码放进同一个类。

  7, Feature Envy(依恋情结)

  将总是一起变化的东西放一起。高内聚、低耦合。

  8, Data Clumps(数据泥团)

  Introduce Parameter Object; Preserve Whole Object

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

  Replace Data Value with Object; Replace Type Code with Subclass; Replace Type code with State/Strategy

  10, Switch Statements(switch语句)

  多态; Replace Type Code with Subclass; Replace Type Code with State/Strategy; Replace Conditional with Polymorphism; Introduce Null Object

  11, Parallel Inheritance Hierarchies(平行继承体系)

  Move Method; Move Field

  12, Lazy Class

  Inline Class; Collapse Hierarchy

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

  如果用不到, 就不要去做。

  14, Temporary Field

  Introduce Null Object

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

  16, Middle Man(中间转手人)

  Remove Middle Man; Inline Method

  17, Inappropriate Intimacy(狎昵关系

  高内聚、低耦合; Move Method; Move Field; Replace Inheritance with Delegation

  18, Alternative Classes with Different Interfaces(异曲同工类)

  Move Method; Extract Superclass

  19, Incomplete Library Class(不完美的程序类库)

  Introduce Foreign Method; Introduce Local Extension

  20, Data Class(纯数据类)

  Encapsulate Field

  21, Refused Bequest(被拒绝的馈赠)

  ush Down Method; Push Down Field

  22, Comments(过多的注释)

  Extract Method; Rename Method; Introduce Assertion

  第四章 构筑测试体系

  1,重构的前提是要有一套可靠的测试环境.(单元测试、回归测试、集成测试)

  2,Class应该包含它们自己的测试代码.

  确保所有测试都完全自动化,让它们自己检查测试结果

  3,频繁运行测试,极限编程XP。

  4,测试你最担心出错的部分;考虑可能出错边界条件。

  5,使用工具。(IDE, JUnit, PowerMock…)

  第五章 重构名录

  1,介绍重构手法时采用的标准格式:

  gt; 名称(name)

  gt; 概要(summary)

  gt; 动机(motivation)

  gt; 做法(mechanics)

  gt; 范例(examples)

  2,重构技巧:小步前进,频繁测试。

  第六章 重新组织你的函数

  1,Extract Method(提取函数)

  用函数的意图给它命名。

  2,Inline Method,Inline Temp

  去掉无用的间接层

  3,Replace Temp with Query; Introduce Explaining Variable

  4,Split Temporary Variable

  一个变量只承担一个责任

  5,Remove Assignments to Parameters(不要对函数参数赋值)

  在pass by value传值方式中,对函数参数的任何修改,都不会对调用端产生任何影响。Java只使用pass by value.(函数指针)

  6,Replace Method with Method Object

  7,Substitute Algorithm(替换你的算法)

  优先使用标准库(STL, Collection集合包, Apache Libs)

  第七章 在对象间搬移特性

  1,Move Method,Move Field

  2,Extract Class,Inline Class

  ingle Responsibility Principal

  3,Hide Delegate,Remove Middle Man

  4,Introduce Local Extension

  运用subclass或是wrapper添加原始类的功能(Is-A, Has-A)

  第八章 重新组织数据

  1,Self Encapsulate Field(自封装值域)

  get/set方法

  2,Replace Data Value with Object(以对象取代数据值)

  3,Change Value to Reference(将实值对象改为引用对象)

  Change Reference to Value(将引用对象改为实值对象)

  4,Replace Magic Number with Symbolic Constant

  以有意义的符号常量取代magic number,提升可读性

  5,Replace Type Code with Class(以类取代型别码)

  Replace Type Code with State/Strategy(以State/Strategy取代型别码)

  tate模式,Strategy模式,Factory Method模式

  6,Replace Subclass with Fields(以值域取代子类)

  创建子类的动机:添加新特性(field),改变行为(method)

  第九章 简化表达式

  1,Decompose Conditional 分解条件式

  2,Consolidate Conditional Expression 合并条件式

  Consolidate Duplicate Conditional Fragments 合并重复条件代码片段

  3,Remove Control Flag

  以break语句或return语句取代控制标记

  4,Replace Nested Conditional with Guard Clauses 以卫语句取代嵌套表达式

  卫语句要么从函数中返回,要么抛出一个异常

  5,Replace Conditional with Polymorphism 以多态取代条件式

  6,Introduce Null Object 引入Null对象

  将null值替换为Null Object。Example:Collections.emptyList() ;

  7,Introduce Assertion 引入断言

  assert用来确认一定为真的先决条件

  在交流上,断言帮助理解假设条件

  在调试上,断言帮助找出bug

  第十章 简化函数调用

  1,Rename Method 重新命名函数

  函数名称应准确表达意图。

  2,Add Parameter 添加参数

  Remove Parameter 移除参数

  3,Separate Query fromModifier 将查询函数与修改函数相分离

  一个函数只做一件事。Exception:使用cache提高查询速度

  4,Parameterize Method 令函数携带参数

  Replace Parameter with Explicit Methods 以明确函数取代参数

  tringUtils.isEmpty(string); StringUtils.isNotEmpty(string);

  5,Preserve Whole Object 保持对象完整

  Introduce Parameter Object

  6,Replace Parameter with Methods 以函数取代参数

  7,Remove Setting Method;Hide Method

  8,Replace Constructor with Factory Method 以工厂函数代替构造函数

  Factory Method

  9,Replace Error Code with Exception 以异常代替错误码

  异常将程序正常逻辑与错误处理分开,使得程序更容易理解。unchecked异常、checked异常

  10,Replace Exception with Test 以测试代替异常

  异常只应用于意料错误之外的行为,不能替代成为条件检查

  第十一章 处理概括关系

  1,Pull Up Field 值域上移

  ull Up Method 函数上移

  ull Up Constructor Body 构造函数本体上移

  ull Down Method 函数下移

  ush Down Field 值域下移

  2,Extract Subclass 提炼子类

  ubclass只能表现一组变化,delegation委托可以表现不同变化

  3,Extract Superclass 提炼超类

  Template Method模式

  4,Extract Interface 提炼接口

  Java单继承多接口

  5,Collapse Hierarchy 折叠继承体系

  inline class

  6,Replace Inheritance with Delegation 以委托代替继承Has-A

  7,Replace Delegation with Inheritance 以继承取代委托Is-A

  《重构》读后感(二):重构

  仓廪实而知礼节,衣食足而知荣辱,这物质文明与精神文明的层级关系也一语道破了程序设计的层次级关系。程序设计也是如此,先满足了功能需求,然后再对代码进行重新整理、组织,达到易读、易改、易扩展。这种对代码重新整理的过程就叫代码重构。

  重构在不同的研发模式中的作用不尽相同。比如,在敏捷开发的研发模式中,重构的作用相当重要。敏捷开发运用迭代法进行产品开发,在迭代过程中分析、方案、代码同时发生,并且弱化方案,强化代码设计。在开发过程中,每次功能迭代程序员都根据现有代码进行重构,尽量运用已有的代码或函数,或者改造现有代码使其满足新功能需要。这样使代码实现高利用率,改善软件的质量、性能,使其程序的设计模式和架构更趋合理,提高软件的扩展性和维护性。

  在过程式研发模式中,前期产品开发阶段重构的作用不太明显,而到后期产品维护阶段重构则较为重要。因为过程式研发在代码设计之前做了一系列工作——需求、方案,这些工作要求产品的功能和方案固定化,并且如果方案做的特别细的话,每个函数的实现方式,甚至代码基本逻辑都已固定,到代码实现阶段只要把方案转化成代码就是。也就是说,在方案阶段已经把重构的工作做的差不多。在后期维护过程或功能添加的过程中,则会参考之前的代码。

  我们目前用过程式研发模式,而我的研发水平处于实仓廪阶段,在方案设计时只是注重功能实现,而没有更多地考虑重构,后期维护也只是注重功能增加。久而久之,代码将会架构模糊,函数重用率低,质量低下,功能增加困难。看了《重构-改善既有代码的设计》之后,昨天我试着把事件模块做些简单的重构,不到一天竞重构掉了近200行代码。由此可见在重构方面做的还很不够。思想决定行动,意识决定高度,正如在实仓廪阶段也要不仅仅为了吃个饱,要把产品当成一种艺术品来做,在细处打磨。现在已经有重构的意识,接下来会在添加功能、修补错误和复审代码时尽量运用重构法则,对代码进行整体把握,强化重构。砍柴不误磨刀工。

  说了这么多,再说说什么重构是什么,什么时候需要重构(来自《重构-改善既有代码的设计》)。

  重构:为保持代码易读,易修改,在不改变代码外在的前提下,对代码做出修改,以改进程序内部结构,提高其可理解性,降低修改成本。

  要重构的代码:可有可无的临时变量,重复代码,过长函数,函数功能过大,过长参数列,发散式变化,散弹式修改,数据泯团。

  ,“任何一个傻瓜都能写出计算机可以理解的代码,惟有写出人类容易理解的代码,才是优秀的程序员”——作者如是说。

  《重构》读后感(三):从现代编程角度看此书已经有些过时

  这本书使用的例子程序来自java1.2版本,你就知道此书的年龄有多老。

  然而年纪大并不是缺点,就像设计模式那么大的年纪仍然发光发热,成为不朽经典。更何况本书顾问还有四巨头之一。

  之所以说它老旧,是因为,书中的例子在现代的eclipse编码工具作用下已没有意义,而这部分的内容将占据本书的二分之一。

  其次,作为编程两年以上经验的人员老说,本书很多东西是你扫一眼就懂的。

  但是书中仍然有很多经典的思想让其栩栩生辉:

  1. 将长函数分为短函数。

  2. 总是将人看作的编码的目标对象而不是机器。

  3. 重构时与设计模式的结合。

  4. 单元测试思想。

  5. 重构无止境

  。。。

  总的来说,实际经验偏少的同学应该仔细品味,会让你少走弯路,甚至建议公司购置一本为新人培训;对于经验丰富的编程人员来说也未尝不是一个鞭策自己编码规范的好书。

  最后,该书应该重构了。。。

  《重构》读后感(四):再读《重构》

  Martin Fowler 的《重构-改善既有代码的设计》这本书,是我大学老师推荐给我的。 当时我在撰写代码过程中,发现当代码量到某个数量级时候(1000+行), 就会逐渐失去对代码的控制能力。昆哥推荐了两本书《UML和模式应用》和《重构》这本书。

  这本书是2年前购买的,可惜以我当时的代码感知和撰写能力,看起来颇为吃力。 半途就看得云里雾里而中断了。最近我又重新拾起这本书, 将书中所写的境况与我这两年多来遇到的问题相互印证,才感受到这本经典的力量。

  Martin 其人:

  ThoughtWorks的首席科学家,当今世界软件开发领域最具影响力的五位大师之一。

  他在UML推广普及、领域建模、企业应用开发和敏捷方法等方面建树卓著,被称为软件开发的教父。

  大学时候有段时间我对 Martin 的敏捷非常痴迷。现在对技术的选择没以前那么冲动了, 但是毫不妨碍我对 Martin 的敬仰之情。

  1. 重构原则

  1.1. 重构的定义

  对软件内部结构的一种调整,目的是在不改变”软件之可察行为“前提下,提高其可理解性,降低其修改成本。

  重构就是在代码写好之后改进它的设计。

  重构和添加新功能并不冲突,但是当开发者身份在两者之间切换时候,不能混淆在一起。

  1.2. 重构的意义

  优秀设计的根本是:消除重复部分!(DRY = Don’t repeat yourself)

  重构让代码更清晰,更容易理解

  清晰的代码可以更方便的找到bug,重构可以写出更强健的代码

  良好的设计可以在长远时间上提高开发速度

  1.3. 重构的时间

  随时进行重构(在我看来,重构更是一种开发的习惯

  事不过三,代码重复不要超过三次(否则就要”抽“出来)

  添加功能时候并一一重构(个人理解是,添加新功能之前,分析并重构,从而更方便添加新功能)

  修补错误时

  code review时

  1.4. 重构和开发进度

  重构的意义之一也是提高开发进度。杀手锏是”不要告诉经理“。

  1.5. 重构的难题

  数据层(数据模型)的变更压力

  修改接口

  那些难以通过重构改变的设计改动

  代码不能运行

  项目期限压力 dead line

  1.6. 重构与设计

  编程不是机械的开发,(软件开发是艺术行为!)

  设计和重构的平衡(预先设计的难度和重构灵活性的平衡)

  1.7. 重构与性能

  重构确实会在短期内降低代码执行效率,但优化阶段是可以调整的,而且调整会更容易。

  提前优化是万恶之源

  1.8. 那些Bad Smell

  重复的代码(这才是真正万恶之源,鄙视一切Ctrl+C/P)

  过长函数,会导致责任不明确/难以切割/难以理解等一系列问题

  过大类,职责不明确,垃圾滋生地

  过长参数列(面向对象不是说说而已)

  发散式变化,一个类会响应多种需求而被修改

  散弹式修改(其实就是没有封装变化处,由于一个需求,多处需要被修改)

  依赖情节(一个类对其他类过多的依赖)

  数据泥团(如果数据有意义,就将结构数据变成对象)

  type code,使用Class替代

  witch,少用,考虑多态

  过多平行的类,使用类继承并联起来

  冗余类,去除它

  夸夸其谈的未来性(Matin的文字,侯俊杰的翻译真是…出彩…)

  临时值域,封装它

  过度耦合的消息链,使用真正需要的函数和对象,而不要依赖于消息链

  过度的deleate

  过度使用其他类private值域

  重复作用的类

  不完美的类库,(类库老了,使用者也没办法阿)

  纯数据类(类需要行为)

  不纯粹的继承(拒绝父类的接口的类)

  过多注释,注释多了,就说明代码不清楚了

  1.9. 从测试开始

  无测试,无重构,只依赖手工测试,重构时候人会崩溃的。

  重构的保真就是自动化测试(如果真的要无聊的手工测试,我也不反对)

  单元测试

  功能测试

  1.10. Kent Back说

  如果我纯粹为今天工作,明天我将完全无法工作。

  间接层的价值:

  * 允许逻辑共享

  * 分开解释”意图“和”实现“

  * 将变化加以隔离

  * 将条件逻辑加以编码

  计算机科学是这样一门学科:它相信所有问题都可以通过一个间接层来解决。 --Dennis DeBruler

  我相信,撰写代码时候不仅仅考虑当下功能,要考虑到有可能出现的情况, 在可能的平衡下面,为将来的扩展做好准备。(也许不仅仅是自己的明天, 还要考虑团队成员的今天工作内容)

  2. 重构名录

  2.1. 重新组织函数

  Extract Method(提炼函数)将一段独立的,不依赖上下文的代码组织并独立出来。Inline Method(将函数内联化)当函数内部代码简短而容易理解时候,去除这个非必要的间接层。Inline Temp(将临时变量内联化)去除只被赋值一次的临时变量。(当有意义时候,应该保留)Replace Temp with Query(以查询取代临时变量)将临时变量提取到一个独立函数,并将原来变量引用替换为函数调用。 (我还是担心性能的问题,另外将临时变量限定在一个段落p中,可以避免额外的引用)Introduce Explainning Variable(引入解释性变量)将复杂表达式的结果放入临时变量,并用变量名来解释表达式用途。 (自注释代码的表现)Split Temporary Variable(剖析临时变量)除了循环变量和临时集合变量,临时变量赋值不能超过一次。Remove Assignments to Parameters(移除对参数的赋值动作)不对函数参数进行赋值动作,如果要赋值,创建一个新的临时变量。Replace Method with Method Object(以函数对象取代函数)把函数变成对象,再把临时变量变成对象值域。该方法在分解函数时候常用。 (Martin 对小型函数特别迷恋,我认为这个方法更应该用在有逻辑意义的方法上面)Substitute Algorithm(替换算法)用更清晰的算法。 (码农都知道)

  2.2. 在对象之间搬移特性

  (面向对象编程原则之一就是职责归属,搬移其实也就意味着职责重新规划)

  Move Method(搬移函数)将函数移动到被最多次调用的类里面去。 (往往在逻辑意义上,这个函数就应该归属于这个类)Move Field(搬移值域)将值域移动到被最多次调用的类里面去。Extract Class(提炼类)将开发过程中逐渐变得臃肿的类拆分成数个类,形成清楚的抽象,明确的职责。Inline Class(将类内联化)将不再担任足够职责的类搬到另外一个类中,并移除这个原始类。Hide Delegate(隐藏委托关系)将直接调用变成间接,在中间添加一层,从而从容面对变更,隔离变化。 (“哪里变化,封装哪里”这是设计模式的一个经典原则)Remove Middle Man(移除中间人)和Hide Delegate相反,移除做了过多简单委托的类。 (应该Hide Delegate需要加入成本,多维护一层,这需要控制一种平衡)Introduce Foreign Method(引入外加函数)当类无法进行修改时候,使用静态函数接受这种类型的类实例,Introduce Local Extenstion(引入本地扩展)使用子类继承/wrapper类来实现额外的函数。

  2.3. 重新组织数据

  elf Encapsulate Field(自封装值域)使用getter/setter。 (个人觉得这样很繁琐,.net中的属性方式处理的不错)Replace Date Value with Object (以对象取代数据值)当数据项有额外的数据和行为时候,将它变成一个类Change Value to Reference(将实值对象改为引用对象)有一些类型,比如日期、星期,不需要保存太多副本。Change Reference to Value(将引用对象改为实值对象)和楼上相反的情况,引用会带来复杂的内存分配,在分布式系统中,实值对象特别有用。Replace Array with Object(以对象取代数组)不应该将不同的元素存放到数组中,应该使用值域。Duplicate Observed Data(复制被监视数据)通过观察者模式,将业务数据和GUI数据进行同步控制Change Unidirectional Association to Bidirectional(将单向关联改为双向)使用双向连接,从而能让两个类能互相使用对方特性。Change Bidirectional Assicuation to Unidirectional(将双向关联改为单向)当一个类不再需要另外一个类特性时候作修改。Replace Magic Number with Symbolic Constant(以符号常量/字面常量取代魔法数)使用有意义的名称,比如pi,gravity。Encapsulate Field(封装值域)使用getter/setter。Encapsulate Collection(封装集群)避免直接修改容器对象,而是封装出类方法来修改。将变化控制在既有方法内。Replace Record with Data Class(以数据类取代记录)将传统编程中的结构体转换为数据类。Replace Type Code with Class(以类别取代型别码)使用类型集合类来替换型别码。Replace Type Code with Subclass(以子类取代型别码)使用多态来替换型别码,发挥面向对象编程的优势。 (小心处理ORM映射)Replace Type Code with State/Strategy(以State/Strategy取代型别码)使用State/Strategy模式来因对type code会发生变化的情况。 将状态类作为父类,再进行继承。Replace Subclass with Fields(以值域取代子类)当子类的差异仅仅体现在返回常量数据的函数上时候,进行这样的替换。

  2.4. 简化条件表达式

  简化的核心思想,是将过程式的if/else替换为面向对象的多态。

  Decompose Conditional(分解条件式)将复杂的条件式提炼为独立函数。Consolidate Conditional Expression(合并条件式)将多个条件式判断提炼成一个独立函数。这和上面的分解条件式都需要一个前提: 这几个条件式是要有逻辑关联的。Consolidate Duplicate Conditional Fragments(合并重复的条件判断)将所有分支里面都拥有的代码提炼到分支判断之后运行。Remove Control Flag(移除控制标志)使用 break/return 取代控制标记。单一出口,多出口。控制标记让程序接口看上去混乱。Replace Nested Conditional with Guard Clauses(以卫语句取代嵌套条件式)保留正常情况下面下的顺序执行,提前对非正常情况进行单独检查并返回。 (我更倾向于使用Exception)Replace Conditional with Polymorphism(以多态取代条件式)将条件式的每个分支放入一个subclass内覆写函数中,然后将原始函数生命为抽象函数。 (这个方法之前的5种重构手段是代码小手段,引入多态才能充分发挥OOP优势)Introduce Null Object(引入Null对象)将无效值替换为null object,从而可以让程序正常运行。 (这好象是一种hack方法,我倾向使用Exception,作者的用以可能是通过Null来减少判断代码)Introduce Assertion(引入断言)通过断言来发现程序错误,实际使用中,可以配合 debug mode 使用。

  2.5. 简化函数调用

  Rename Method(重命名函数)A good name is better than a line of comment.Add Parameter(添加参数)你没看错,就是添加参数。 (啊?Matin老师,不带这么水的阿)Remove Parameter(移除参数)不要就丢掉。Separate Query from Modifier(将查询参数和修改参数分离)将一个即查询状态又修改状态的函数分离开来,职责分离清楚。 (我以前很喜欢写多面手函数~)Parameterize Method(令函数携带参数)同一逻辑功能函数,通过重载接受不同参数。而不要建立多个同样的函数。Replace Parameter with Explicit Methods(以明确函数取代参数)将单一函数分解为多个函数从而去掉参数,前提是这几个函数的逻辑功能区别较大。Preserve Whole Object(保持对象完整)传递完整的对象,取代几个参数的传递。Replace Parameter with Methods(以函数取代参数)如果目标函数需要的是几个参数操作的结果,就直接传递这个结果,而不是数个参数。Introduce Parameter Object(引入参数对象)当几个参数经常同时出现,就封装他们。 (他们之间往往就有逻辑关系)Remove Setting Method(移除设值函数)如果类的某个值域初始化后不再改变,就去掉它的setting方法。 (我理解为原则:“减少疑惑,保持唯一”)Hide Method(隐藏某个函数)使用 private 标记未被其他类调用的方法。Replace Constructor with Factory Method(以工厂函数取代构造函数)引入工厂模式。Encapsulate Downcast(封装向下转型动作)当知道什么类型时候,将其封装在产生函数里面,减少引用者的困扰。Replace Error Code with Exception(以异常取代错误码)如其名。 (关于异常使用的时机,抛出的方式,捕捉的粒度,我困惑了很久。 最后的总结的经验是:在什么层级处理并且仅处理该层级的异常。等有时间详细成文送出)Replace Exception with Test(以测试取代异常)异常不是条件判断。

  2.6. 处理概括关系

  关于 OOP 继承的那些事儿。

  ull Up Field(值域上移)子类重复的值域放到父类去。 (其实还是基于责任归属的问题)Pull Up Method(函数上移)子类中重复函数移到父类。Pull Up Construction Body(构造函数本体上移)共用的构造函数片段上移。Push Down Method(函数下移)将父类中近被某个子类调用的函数下移。Push Down Field(值域下移)同上。Extract Subclass(提炼子类)当某个类只有部分特性被用到,就需要提取出子类。Extract Superclass(提炼超类)和上面相反。Extract Interface(提炼接口)将相同的子集提取接口。Collapse hierarchy(折叠继承体系)父类和子类并无太大区别时候,合体吧亲。From Template Mehod(塑造模板函数)将子类的同功能不同实现函数上移到父类,并在子类提供同名不同实现被调用的子函数。Replace Inheritance with Delegation(以委托取代继承)将父类变成一个值域,在调用这个值域的方法。is-a → has-a (继承太多就会出问题)Replace Delegation with Inheritance(以继承取代委托)和上面相反的应用,当子类和父类出现明显的继承关系时候使用。

  2.7. 大型重构

  这一章讲的内容有点高屋建瓴,这里就不概括了,建议读原文。

  Tease Apart Inheritance(梳理并分解继承体系)

  Convert Procedural Design to Objects(将过程化设计转化为对象设计)

  eparate Domain from Presentation(将领域和表述/显示分离)

  Extract hierarchy(提炼继承体系)

  少年,coding时候重构你的代码吧!

  版权所有 © 2010 转载本站文章请注明: 转载自Log4D

  原文链接: http://log4d.com/2012/02/refactory

  您可以随意地转载本站的文章,但是必须在醒目位置注明来源及本站链接,不可以将本站文章商业化使用,或者修改、转换或者以本作品为基础进行创作。

  3a1ff193cee606bd1e2ea554a16353ee

  《重构》读后感(五):重构万岁~

  英文版 :

  花了一个月的时间读完了这本书的英文版本。对英语不太有自信的朋友(譬如我),建议对照着中文版来看。因为有些单词翻译过来还是不明白意思,譬如, ‘nibble away’这个词,google翻译为‘蚕食远’,而中文版翻译为‘慢慢处理’。

  章节介绍:

  第一章展示的小程序一下子就拉近了读者和重构之间的距离,顿时有种重构走下神坛的感觉。

  第二章介绍理论知识,略带乏味。

  第三章的bad smells一点点的让我想起,当初自认为写的很健壮的代码,但现在看来很有问题的。

  5-12章的精彩自不用多说。尤其是第12章big refactorings,帮我瞬间拉回到四个最为普通的案例来。继承和委托应该使用哪一个,各自的优势是什么?如何将一个过程式的设计转变为面向对象式的?如何将表现和逻辑相分离?哇!!!看的太精彩太过瘾了!这些可都是程序员心中萦绕已久的问题啊!

  13,14,15章因为我资质较浅,没能参透... ...

  16章真的像作者说的一样,起到了画龙点睛的效果。尤其是作者提到的当你无法再继续重构下去的时候, 等下来歇息一下,想一想,等想好了再继续出发。还有就是书中几乎每一页都有提到的'step by step'简单精炼至极。

  合上这本书后,按耐不住激动之情,马上来这里写下这些文字,以纪念这一个月来陪伴我度过无聊生活的‘朋友’。我相信我不会从此冷漠它,接下来的编程生涯我会带着他一起走完。

  《重构》读后感(六):完美主义者的书

  我觉得这本书吧,技巧性十足,但实用性不够。为什么呢?因为他的解决方法是建立在你知道问题出在哪里的基础上,但往往我们的难点在于不知道问题具体在哪里。

  这本书适合学习,学习一些好的设计方法,以便将来什么时候来用。我买这本书的时候,正好在重构一个比较大的项目,但读了几天与我的项目严重脱钩。

  重构不光在于重构代码、重构类,还需要考虑重构功能、重构交互、重构接口,这本书指导不了什么。

  另外,这本书中追求的完美解决方法,我宁可一步一步来改进达到这个效果。

  总之内容太细,我读了不到1/3就没有再继续读下去。一些比较泛泛的经验分享非常少。嗯适合什么人读呢?正在学习设计模式的人吧

评价:

[匿名评论]登录注册

【读者发表的读后感】

查看《重构》读后感10篇的全部评论>>

评论加载中……