重构的原因，在于需求的变化。需求没有变化，也就没有必要瞎折腾来重构，除非你真很蛋疼。 需求变化有两种原因:
一，是真的变化了。
二，对需求的认识深化了。
旧的需求，转化到新的需求，设计就要跟着变化。当然也不是所有情况都需要大变动，很多需求变化，没有涉及到“筋骨”，就可以保持设计的骨架，而添加新的内容。 一个优秀的设计，应该精良预示到这种简单的需求变化。
如果真的要改变，那哪些设计会比较容易更改呢？ 类设计有两种观点:
一是从自身出发，该类应该有哪些操作，就建立这些操作。
二是从需求出发，别人需要该类有什么操作，他就应该提供这些操作。
我的看法是，从需求出发，建立的是概念切面，也就是接口。从自身出发，建立的是具体实现。当类调用其他类，使用的是接口，而当编写类自身代码时，又应该从自身出发。
接口比类可能要小，也可能要大。而当接口比类要大，显然需要多个类才能支持完整的接口，这时候可能就需要建立简单的包装类。
(当接口比类小，那么说明系统还不需要更多地控制，这个时候应该选择暂时封闭相关部分。如果把类看作一个整体，成员函数就是传统上的子程序概念。而作为接口的时候，成员函数是流程的局部。）
接口往往是很稳定，但是，当需求变化的时候，设计变更的时候，变化的是什么？就是接口。 接口虽然变了，但是类还生存，并且，因为类是从自身出发的，有理由相信在新的接口面前也不需要变化。我们可以设计新的接口，并大量使用已有的实现在完成新的接口的支持，当然，免不了要添加新的类，和废置很多旧的类，因为这就是需求在变化了。