crylearner的专栏

《重构——改善既有代码》一书，总览下来，除去一些几乎每个工程师已知已会 和 比较偏的手法外，主要就是以下这些：一、基本手法1.       Encapsulate Field2.       Self Encapsulate Field3.       Extract Method4.       Move Field/Method5.       Rename F

修改if else 最忌惮的是天马行空，自负自己对代码的理解，直接重新改写条件语句。但另一方面，相信各位看官也注意到了，理解又是必不可少的，完全死死的做逻辑变形是异常繁琐的（这个在第二个例子中尤为明显），具体如何操作，不好意思，这就是"修改代码的艺术"。口才不行，修行还靠个人。 不要做不成熟的优化。相对来说，代码的清晰度高于性能的优化，而且很多时候两者并不是冲突的，当代码更清新了，往往有更好的优化方案。 举例中的一些代码风格，比如return快速返回，不是每个人都能接受。求同存异，这也是个人座右铭。

这里作为(II)的续篇，继续距离 复杂的嵌套if else 的处理。 为了保持篇幅不会太长，所以截断了，以一篇新的文章形式给出。化简复杂的if else语句，基本的手段针对头重脚轻的if else，使用return快速返回，从而减少嵌套层数。合并分支。有些分支的执行内容相同，往往意味着可以合并为一个分支扁平化。第二个例子，比较复杂一点，给定一个日期，即年 月 日，让

4. 修改时应当测试哪些方法作者提出了影响结构图的概念。说穿了，就是CallRelation和ReferenceRelation，就是查看某个方法(变量)被哪些方法引用，以及自身又引用了哪些方法，依次类推。这个复杂的关系网实际就是一颗风险评估树(图)。通过这棵树，我们可以知道某个修改会影响到哪些节点。这项参数，既是风险的直接量化指标，同时又是验证修改的测试指标。这是很朴素的思想，不管有意无意，你肯定已经在这么做了，不要告诉我你的boss从来没问过你这样的问题：“这个修改有风险吗？”。

《修改代码的艺术》，英文名《Working Effectively with Legacy Code》，中文翻译的文笔上绝对谈不上“艺术”二字，愧对艺术二字（当然译者不是这个意思）。书中第三部分不论是例子还是解说都有点混乱，远不如《重构——改善既有代码设计》一书。此书精华在于第一、二部分。如何学习这本书，作为一个最底层的码农，作为长期在别人代码上修修补补的苦逼二手货开发人员，我只能给的建议就是

上一篇文章中，我们提到OO中复用的方式有两种，组合和继承。一般情况下，应该尽可能使用组合的方式。现在以复用为基本需求，推演若干常见组合型模式1. Decorator模式 需求：我们已经有一群对象，现在想统一为这些对象添加若干新特性。更重要的是，这些新特性可以反复叠加于某个对象，或者只选择部分特性作用于某个对象。条件：如果这个特性的实现不依赖于具体的对象，就如同添加一个装

上一篇文章中提到，在做代码设计时，坚持OCP原则，坚持一起从需求分析开始，分析当前代码中哪些是不变的，哪些是变化的，那么我们就可以做到简单而快速的响应客户需求。现在，我们来讨论创建型模式还是从需求分析开始，使用创建型模式，实际是为了将类名和类的创建解耦。换成变与不变的说法就是，产品名称可能经常发生变化或者有扩充，但是这些产品对象的使用方式不变。假设我们现在有产品类Wall（A，B，

《重构——改善既有代码》剩下还有一些重构手法，在本blog系列《Eclipse重构——总章》中有提及，这些重构可以应用基本的Eclipse重构菜单，按照Martin Flower的建议步骤，亦步亦趋的完成。下面只是再特别强调几个。（更多的Eclipse重构菜单的使用，可以参考点击打开链接）1. [Introduce Factory]，Eclipse中有直接对应菜单， 可以直接将

《重构——改善既有代码》Motivationü  类型码不是类型安全的，终究只是一堆数字或者一个字符串。使用类代替类型码，可以做更好的编译检查。ü  如果类型码不影响宿主类的行为，则优先考虑使用Replace Type Code with ClassMechanicsü  为类型码建立一个类。类中应该定义一组静态变量，表示允许被创建的实例。ü  修改源类实现，将类型码替换为

《重构——改善既有代码》Motivation坚持这样一条原则：任何有返回值的函数，都不应该有看得到的副作用。所以查询和修改必须分开。Mechanicsü  新建一个查询函数，其返回值与原函数相同；修改原函数，令他调用查询函数，并返回查询结果。ü  将调用原函数的代码改为调用查询函数。然后在调用查询函数的那一行之前调用原函数。ü  修改原函数，删除return语句

《重构——改善既有代码》Motivation出现依恋情节或者职责不清，应将行为移动到正确的类中。Mechanics1  检查源函数中所使用一切特性（包括field和函数）2  检查子类和父类是否也定义了该函数3  先委托，然后根据实际情况，决定是否将对源函数的调用替换为对目标函数的调用。Eclipse refactor

《重构——改善既有代码》Motivation出现依恋情节或者职责不清，应将行为移动到正确的类中。Mechanics1  检查源函数中所使用一切特性（包括field和函数）2  检查子类和父类是否也定义了该函数3  先委托，然后根据实际情况，决定是否将对源函数的调用替换为对目标函数的调用。Eclipse re

Motivation出现依恋情节或者职责不清，应将行为移动到正确的类中。Mechanics1  检查源函数中所使用一切特性（包括field和函数）2  检查子类和父类是否也定义了该函数3  先委托，然后根据实际情况，决定是否将对源函数的调用替换为对目标函数的调用。Eclipse refactor菜单下直接有Move 选项，可以直接使用该选项完成Move Me

Motivation如果某个field，在其所驻class之外的另一个class中有更多的函数使用了它，那么可以考虑将这个field移动到另一个class。Mechanics1  如果field属性为public，应该先使用EncapsulateField或者Self Encapsulate Field封装该成员。2  在target class中建立该field，同时应用Self

Motivation局部变量会使代码难以被提炼，所以应该尽可能将他们替换为查询式。另外，ReplaceTemp with Query也是Extract Method的必要步骤。Mechanics1  如果临时变量被赋值多次，则应用Split Temporary Variable，将他分割成多个变量，每个新的变量只被赋值一次。2  对每一个临时变量，提取查询函数，然后替换。（如果

《修改代码的艺术》，每次读来，都会相当重构，正如作者自己就说到的：从技术上讲，书中列到的解依赖技术，都是重构技术，因为他们都保持了代码的行为。这里庄稼人再多引用《大话重构》中的一句话：先重构我们的系统，使之可以应付那个需求，然后再添加代码，实现新需求。是的，正如读书报告（I）中所阐述的，引入单元测试，本质上就是做定制需求。作为最后一篇，来总结一下最后的解依赖技术。核心思想就是泛化，这里