方法过长（Long Method）下面首先引用一下《Refactoring to Patterns》中的描述：Fowler和Beck在对这种坏味的描述中，解释了方法短胜于长的几个充分理由。主要的理由是逻辑的共享。两个很长的方法很可能包含重复代码。如果将这些方法分解为多个小方法，就能发现通常有很多方式能够使它们共享逻辑。Fowler和Beck还说明，小的方法可以帮助理解代码。如果对一段代码的意图不太理解，可以将它提炼为小的、命名准确的方法，这样再理解原来的代码将更容易。包含大量小方法的系统更容易扩展和维护，因为它们更容易理解，重复更少。方法到底多小才合适呢？我觉得应该在10行代码以内，大多数方法的代码应该只有1~5行。如果系统的大多数方法都比较小，那么可以有少数方法稍大一些，只要它们比较容易理解，而且不包含重复代码。有些程序员不愿意编写小的方法，因为他们害怕对许多小方法的一连串调用会带来性能开销。这是非常不明智的选择，原因如下：首先，优秀的设计人员都不会对代码进行不成熟的优化；其次，将许多小的方法调用串起来，所增加的性能开销一般微乎其微------这一点可以使用性能分析程序验证；第三，即使碰巧因此遇到性能问题，还可以通过重构来改进性能，无需放弃小方法原则。我只要遇到长方法，马上就有应用组合方法重构将它分解为一个Composed Method的冲动。这项工作通常包含提炼方法F的应用。如果正在转换为Composed Method的代码要将某个信息累加到一个公共变量中，可以考虑应用将聚集操作搬移到Collecting Parameter重构。如果方法很长，是因为它包含了一个用来分派和处理请求的大switch语句，可以使用用Command替换条件调度程序重构将其缩短。如果使用switch语句从接口不同的许多类收集数据，可以通过应用将聚集操作搬移到Visitor重构缩短方法的长度。如果方法很长，是因为它包含算法的许多版本和运行时用来选择版本的条件逻辑，那么可以应用用Strategy替换条件逻辑重构缩短方法的长度。
条件逻辑太复杂（Conditional Complexity）下面首先引用一下《Refactoring to Patterns》中的描述：如果条件逻辑很容易理解，而且只包含几行代码，那么其本身是无辜的。不幸的是，它很少能够这样善始善终。例如，实现几个新功能后，条件逻辑就突然变得复杂而又开销高昂。《重构》F 一书中和本目录中的几个重构正是用来解决这一问题的。如果条件逻辑控制的是应该执行一种计算操作几个变形中的某一个，则可以考虑应用用Strategy替换条件逻辑重构。如果条件逻辑控制的是应该执行类的核心行为之外某个特殊行为的若干段中的某一段，则可以使用将装饰功能搬移到Decorator重构。如果控制对象状态转换的条件表达式比较复杂，可以考虑通过应用用State替换状态改变条件语句重构简化逻辑。处理空操作情形经常需要创建条件逻辑。如果在整个系统中有重复的相同的空条件逻辑，则可以使用引入Null Object重构进行清理。