2016年8月19日
摘要：
当一个类有很多方法希望将它们“提拔”到基类以供同层次的其他类使用时，会经常使用该重构。下面的类包含两个方法，我们希望提取这两个方法并允许其他类使用。 public class Dog { public void eatFood() { // eat some food} public void gr 阅读全文
摘要：
重构没有什么出处，是我平时经常使用而总结出来的。欢迎您发表任何改进意见或建议。我相信一定还有其他比较好的重构可以解决类似的问题。 我曾无数次面对的一个代码坏味道就是，使用异常来控制程序流程。您可能会看到类似的代码： public class Microwave { private Microwave 阅读全文
摘要：
有些单元测试需要恰当的测试“缝隙”（test seam）来模拟/隔离一些不想被测试的部分。如果你正想在代码中引入这种单元测试，那么今天介绍的重构就十分有用。在这个例子中，我们的客户端代码使用一个静态类来实现功能。但当需要单元测试时，问题就来了。我们无法在单元测试中模拟静态类。解决的方法是使用一个接口 阅读全文
摘要：
重构来自于Martin Fowler的重构目录。你可以在这里找到包含简介的原始文章。 在我看来，这是一个比较罕见的重构，但有时却终能派上用场。当你尝试进行提取方法的重构时，需要引入大量的方法。在一个方法中使用众多的本地变量有时会使代码变得丑陋。因此最好使用提取方法对象这个重构，将执行任务的逻辑分开 阅读全文
摘要：
把一个类的多个职责进行拆分，这贯彻了SOLID中的单一职责原则（SRP）。尽管对于如何划分“职责”经常存在争论，但应用这项重构还是十分简单的。我这里并不会回答划分职责的问题，只是演示一个结构清晰的示例，将类划分为多个负责具体职责的类。 public class Video { public void 阅读全文
摘要：
我们要介绍的重构是提取方法。这个重构极其简单但却大有裨益。首先，将逻辑置于命名良好的方法内有助于提高代码的可读性。当方法的名称可以很好地描述这部分代码的功能时，可以有效地减少其他开发者的研究时间。假设越少，代码中的bug也就越少。重构之前的代码如下： public class Receipt { p 阅读全文
摘要：
重构没有固定的形式，多年来我使用过不同的版本，并且我敢打赌不同的人也会有不同的版本。 该重构适用于这样的场景：switch语句块很大，并且会随时引入新的判断条件。这时，最好使用策略模式将每个条件封装到单独的类中。实现策略模式的方式是很多的。我在这里介绍的策略重构使用的是字典策略，这么做的好处是调用者 阅读全文
摘要：
我们来介绍一个常常被忽视的重构：提取接口。如果你发现多于一个类使用另外一个类的某些方法，引入接口解除这种依赖往往十分有用。该重构实现起来非常简单，并且能够享受到松耦合带来的好处。 public class ClassRegistration{ public Double Total;//getter 阅读全文
摘要：
继承的误用十分普遍。它只能用于逻辑环境，但却经常用于简化，这导致复杂的没有意义的继承层次。看下面的代码： public class Sanitation{ public String WashHands(){ return "Cleaned!";}} public class Child exten 阅读全文