@关于间接层的概念。

间接层就是我们所提炼出来的小函数。本来事情是可以交给一个大函数一次性去执行完的，可是我们为什么还要把他分割成小函数，再委托小函数这个间接层去完成事情呢。以下是作者总结出来的三点间接层的好处。

1、 允许逻辑共享。也就是说小函数做的这些小事情，子类也同样可以做，而且跟其他事情互不干扰。

2、间接层给了我们一个解释自己意图的机会。间接层允许我们选择最适合表达我们意图的名字来命名，那在调用这些函数的时候，我一看他们的名字就知道他们可能会做些什么事情。就像Justin昨天写的那个 A()

                            {

                                     …

                                     ….

                                     ….   200 行

}

改成

A()

{

         A1();

         A2();

         A3();

}

A1()

{

         …….

}

A2(){….}

A3(){….}

这样你在整理逻辑的时候，头脑会很清醒。（因为名字是我们赋予他们的意义）

3、将变化加以隔离，当我需要修改一些逻辑的时候，我可以把我在整个项目中掀起的波澜降低很多。

@在有些开源的框架内，我的接口名字已经公布了，可是现在我在重构的时候需要改变这些接口名字，改怎么办呢？

这时候可以保留旧的接口，然后在旧的接口中用新接口来实现逻辑。一直持续到所有用户都开始使用新接口的时候，再把这个旧接口去掉。

@这个世界不存在一条万能的定律能解决一切问题（我曾经想象要是有这么一条定律就好了，这也是很多哲学家，科学家所追求过的），所以不要试图用重构来拯救整个世界。有以下几种情况重构不适用。

当代码已经腐朽到连正常功能都不能运行的时候，也许重写（从头再来一遍）比重构要来的简单。

有的时候临近发布，我们要赶眼前的时间，就不应重构了。重构其实是一剂中药，虽然药效很好，但是效果却也来的慢一些。如果是赶时间发布，那就不要寄希望于重构了。重构是我们欠的债，很多时候我们都是举债来发布的，但是债都是有利息的，“过于复杂的代码所造成的【维护和扩展的额外开销】就是利息。一定的利息我们可以承受，但是利息过高就会被拖垮。“出来混总是要还的”。最近几次发布都通宵，这也许就是我们的重构债欠的有点过多的信号。是时候来偿还一些债了。