2016年8月19日
摘要：
在传统的代码库中，我们常常会看到一些违反了SRP原则的类。这些类通常以Utils或Manager结尾，有时也没有这么明显的特征而仅仅是普通的包含多个功能的类。这种God类还有一个特征，使用语句或注释将代码分隔为多个不同角色的分组，而这些角色正是这一个类所扮演的。 久而久之，这些类成为了那些没有时间放置到恰当类中的方法的垃圾桶。这时的重构需要将方法分解成多个负责单一职责的类。public class... 阅读全文
摘要：
契约式设计（DBC，Design By Contract）定义了方法应该包含输入和输出验证。因此，可以确保所有的工作都是基于可用的数据，并且所有的行为都是可预料的。否则，将返回异常或错误并在方法中进行处理。要了解更多关于DBC的内容，可以访问wikipedia。 在我们的示例中，输入参数很可能为null。由于没有进行验证，该方法最终会抛出NullReferenceException。在方法最后，我... 阅读全文
摘要：
基于c2的wiki条目。Los Techies的Chris Missal同样也些了一篇关于反模式的post。 简单地说，当你使用大量的嵌套条件判断时，形成了箭头型的代码，这就是箭头反模式（arrowhead antipattern）。我经常在不同的代码库中看到这种现象，这提高了代码的圈复杂度（cyclomatic complexity）。 下面的例子演示了箭头反模式public class Sec... 阅读全文
摘要：
有 时当 使用 一个 包含 多 个 参 数 的 方 法 时 ， 由 于参 数 过 多 会 导 致 可 读 性 严 重 下 降 ， 如 ： 有 时当 使用 一个 包含 多 个 参 数 的 方 法 时 ， 由 于参 数 过 多 会 导 致 可 读 性 严 重 下 降 ， 如 ： 有 时当 使用 一个 包 阅读全文
摘要：
这个重构是一种元重构（meta-refactoring），它只是不停地使用提取方法重构，直到将一个大的方法分解成若干个小的方法。下面的例子有点做作，AcceptPayment方法没有丰富的功能。因此为了使其更接近真实场景，我们只能假设该方法中包含了其他大量的辅助代码。 下面的AcceptPaymen 阅读全文
摘要：
在代码中，通常需要一些复杂的对象创建工作，以使这些对象达到一种可以使用的状态。通常情况下，这种创建不过是新建对象实例，并以我们需要的方式进行工作。但是，有时候这种创建对象的需求会极具增长，并且混淆了创建对象的原始代码。这时，工厂类就派上用场了。关于工厂模式更全面的描述可以参考这里。最复杂的工厂模式是 阅读全文
摘要：
当一个类中的某些方法并不是面向所有的类时，可以使用该重构将其迁移到子类中。我这里举的例子十分简单，它包含一个Registration类，该类处理与学生注册课程相关的所有信息。 public class Registration { public NonRegistrationAction actio 阅读全文
摘要：
我们通过提取子类来下放职责。，当我们意识到不再需要某个子类时，可以使用Collapse Hierarchy重构。如果某个子类的属性（以及其他成员）可以被合并到基类中，这时再保留这个子类已经没有任何意义了。 public class Website { public String title; pub 阅读全文
摘要：
这大概是处理一个方法在多处使用时最常见的重构。如果不加以注意的话，你会慢慢地养成重复的习惯。开发者常常由于懒惰或者在想要尽快生成尽可能多的代码时，向代码中添加很多重复的内容。我想也没必要过多解释了吧，直接看代码把。 我们用共享方法的方式来删除重复的代码。看！没有重复了吧？请务必在必要的时候执行这项重 阅读全文
摘要：
当代码中充斥着若干条件判断时，代码的真正意图会迷失于这些条件判断之中。这时我喜欢将条件判断提取到一个易于读取的属性或方法（如果有参数）中。重构之前的代码如下： public class RemoteControl { private String[] Functions;//getter sette 阅读全文