【代码重构（Refectoring）系列教程】代码臃肿（Bloaters）--Long Method

长方法（Long Method)

●症状和特点

   一个方法包含的过多的行数。一般来说，任何超过10行的方法都应该让你开始对他产生优化的想法。

●问题产生的原因

   就像加州旅馆一样，某些东西总是被添加到一个函数体中，然而没有任何东西会从函数体中删除。因为编写代码总是比去阅读它容易，因此这种“味道”经常不被发现，直到整个方法变成了一个丑陋的，巨大的“野兽”。
   创建一个新的函数总是比在一个函数中添加内容更费脑筋。“只需要两行而已，没有为此创建一整个函数了”，这意味着新的几行被添加到函数中，一段绞成一团的代码也就因此产生了。

●解决方法

   根据经验来讲，如果你需要对方法中的某个地方进行评论，你应该将这块代码放到一个新的方法中。如果需要对代码解释的话，即使是一行代码也应该被分离到一个新的方法之中。如果这个方法起了一个具有描述性的名字的话，没人需要通过代码来知道这一段代码做了什么。
  ✦为了减少方法体的长度，可以使用提炼函数法。
  ✦如果要提炼的方法涉及到变量和参数，可以使用使用查询方法替换变量法，引入参数对象法，保持整体对象法。
  ✦如果上述的方法都不适用，可以通过以方法对象替换方法法将整个方法变成一个单独的对象。
  ✦条件表达式和循环语句是一个明显的暗示：这块代码可以放到一个单独的方法之中。对于条件语句，可以使用分解条件语句法；如果循环语句很碍事，尝试使用提炼函数法。

●使用以上方法获得的好处

  在面向对象编程的代码中，拥有较短方法更能经得起时间的考验。方法或者函数越长，它就越难理解和维护。
  除此之外，长方法为讨厌的重复代码提供了完美的藏身之处。

●性能方面

  是否像很多人指责的那样：方法的增加会降低性能？其实在大多数情况下，这对性能的影响是微不足道的，因此根本无需担心它。
  除此之外，当你有了清晰易懂的代码以后，你就更加可能找到重构后可以有效提升效率的方法，如果有要提升性能的需求，你也可以因此极大提升代码的性能。