继承是面向对象中的一个概念，在小酌重构系列[7]——使用委派代替继承这篇文章中，我“父子关系”描述了继承，这是一种比较片面的说法。后来我又在UML类图的6大关系，描述了继承是一种“is a kind of”关系，它更偏向于概念层次，这种解释更契合继承的本质。本篇要讲的3个重构策略提取基类、提取子类、合并子类都是和继承相关的，如果大家对继承的理解已经足够深刻了，这3个策略用起来应该会得心应手。 阅读全文
“分离职责”是经常使用的一个重构策略，当一个类担任的职责太多时，应按职责将它拆分成多个类，每个类分别承担“单一”的职责，也就是让每个类专心地做“一件事情”。就一个类而言，应该仅有一个引起它变化的原因，这是所谓的SRP原则。本篇文章基于SRP原则展开描述了SRP原则的定义，为什么要遵循SRP原则，以及实践SRP原则的难点。最后，我们通过一则示例来说明“分离职责”这个重构策略。 阅读全文
单元测试是针对代码单元的“独立”测试，编写单元测试有助于改善代码的质量。在编写单元测试时，难免有一些功能是依赖于其他代码的。通常我们只想测试这些功能本身，而不想测试它所依赖的代码。“依赖的代码”是编写单元测试时的一个难题，我们可以通过2种方式来解决这个问题：Mock依赖的代码和分解依赖。然而Mock不是万能的，我们不能在单元测试中Mock静态类，但是通过“分解依赖”可以解决这个问题，本文将通过一个示例来演示这2种方式。 阅读全文
世间唯一“不变”的是“变化”本身，这句话同样适用于软件设计和开发。
在软件系统中，模块（类、方法）应该依赖于抽象，而不应该依赖于实现。
当需求发生“变化”时，如果模块（类、方法）依赖于具体实现，具体实现也需要修改；
如果模块（类、方法）依赖于接口，则无需修改现有实现，而是基于接口扩展新的实现。本篇首先介绍了面向接口以及开闭原则的概念，然后提到了“提取接口”这个重构策略，并用一个示例展示了这个重构策略。 阅读全文
UML类图用于展现一组对象、接口、协作和它们之间的关系。类图描述的是一种静态关系，在系统的整个生命周期都是有效的，是面向对象系统的建模中最常见的图。UML一共包含6大关系，它们分别是Inheritance(继承)、Implementation(实现)、Dependency(依赖)、Association(关联)、Aggretation(聚合)和Composition(组合)。在这6大关系中，依赖、关联、聚合和组合是比较容易混淆的，我也会讲解它们之间的区别。 阅读全文
子类可以继承父类的字段、属性和方法，使用“继承”可以较大程度地复用代码。
在使用继承时，务必要确定代码中定义的“父类”和“子类”确实存在客观的“父子关系”，而不要去做“为了代码复用而使用继承”的事情，这是舍本逐末的做法，也是滥用继承的体现。
滥用继承会破坏类之间客观存在的关系，也会模糊代码所体现的语义。 阅读全文
如果方法有超过3个以上的参数，调用方法时就会显得冗词赘句。这时将多个参数封装成一个对象，调用方法会显得干净整洁。
这就是本文要讲的重构策略“引入参数对象”——将方法的参数封为类，并用这个类的对象替换方法中原有的参数。另外，在一些应用场景中，当方法拥有很多参数，且这些参数表示不同的意义时，“参数对象”的命名就成了一个难题，我们可以用一种偷懒的做法，将参数对象命名为“xxxContet”，即“xxx上下文”。 阅读全文
当一个方法包含大量的布尔参数时，方法是很脆弱的，由此还可能会产生两个问题：
1. 方法不容易被理解
2. 给方法的使用者造成一定困扰，可能会产生一些预期之外的结果
本文要介绍的重构策略“为布尔方法命名”，可以有效地避开这两个问题。 阅读全文
“分解方法”的思想和前面讲到的“提取方法”、“提取方法对象”基本一致。
它是将较大个体的方法不断的拆分，让每个“方法”做单一的事情，从而提高每个方法的可读性和可维护性。
分解方法可以看做是“提取方法”的递归版本，它是对方法反复提炼的一种重构策略。 阅读全文
本文要介绍的是4种重构策略，它们分别是提升方法、降低方法、提升字段和降低字段。在使用这4种重构策略之前，我觉得有必要先介绍一个重要的概念——语义。语义可以简单地看作是数据对应的现实世界中的事物所代表的概念和含义，以及这些含义直接的关系，是数据在某个领域上的解释和逻辑表示。语义具有领域特征，不属于任何领域的语义是不存在的。接下来，我将通过示例来描述这4种示例。 阅读全文
