转： 最常用的重构指导
参考：http://www.cnblogs.com/KnightsWarrior/archive/2010/06/30/1767981.html，本文示例代码多来自此处；
参考：《重构：改善既有代码》；
完美而高档的摩天大厦应至少具备两个特点：房间内部是清洁的、结构上是无懈可击的。优秀的代码也应如此。码农要负责打扫房间，架构师负责搭建一个经得起考验的代码结构。有些人兼顾码农和架构的角色。如果你既不是码农，也不是架构师，那么就请离代码远点，离重构远点，要有多远滚多远。
一：打扫房间
1：避免重复代码
避免重复代码在大多数情况下适用，但是我有一个逆观点是：允许重复代码，如果它影响到你的架构。
2：提取方法原则，超过30行？
并不一定超过30行的代码就必须提取为方法，当然，原则上，大部分情况下应该是这样的。还有，如果提取方法让你的代码更清晰，你就应该提取方法，如下：
namespace LosTechies.DaysOfRefactoring.ExtractMethod.Before { public class Receipt { private IList<decimal> Discounts { get; set; } private IList<decimal> ItemTotals { get; set; }
public decimal CalculateGrandTotal() { decimal subTotal = 0m; foreach (decimal itemTotal in ItemTotals) subTotal += itemTotal;
if (Discounts.Count > 0) { foreach (decimal discount in Discounts) subTotal -= discount; }
decimal tax = subTotal * 0.065m;
subTotal += tax;
return subTotal; } } }
namespace LosTechies.DaysOfRefactoring.ExtractMethod.After { public class Receipt { private IList<decimal> Discounts { get; set; } private IList<decimal> ItemTotals { get; set; }
public decimal CalculateGrandTotal() { decimal subTotal = CalculateSubTotal();
subTotal = CalculateDiscounts(subTotal);
subTotal = CalculateTax(subTotal);
return subTotal; }
private decimal CalculateTax(decimal subTotal) { decimal tax = subTotal * 0.065m;
subTotal += tax; return subTotal; }
private decimal CalculateDiscounts(decimal subTotal) { if (Discounts.Count > 0) { foreach (decimal discount in Discounts) subTotal -= discount; } return subTotal; }
private decimal CalculateSubTotal() { decimal subTotal = 0m; foreach (decimal itemTotal in ItemTotals) subTotal += itemTotal; return subTotal; } } }
3：警惕超过300行的类
如果它不是个门面类，那么超过300行的类很多时候过于复杂，俗称“上帝类”，因为它妄图做太多事情，可以考虑重构成更小的类；
4：过多的方法参数
方法参数超过5个几乎总是有问题的，可以把参数提取为一个实体类。当然，越接近于底层我越能容忍这种情况的发生，比如 DAL 类，查询条件多的情况下，我会允许带很多参数。
5：没有必要的注释
很多人拿微软的 FCL（基础类库） 来举反例，说 MS 的注释简直全面俱到。对不起，你要看清它在开发什么，它在开发 API，供我等小白使用的，所以它必须提供一份全面俱到的 API 说明。大多数情况下，干掉你代码中的注释，把代码写的让别人能直接看得懂。如果一定要写注释，则一定要按规范格式来，不是两个反斜杠后面跟一段话就叫做注释，你给自己身上贴满创可贴试试。
6：不要用异常
用 Tester-Doer 模式取代异常，不要尝试总是使用异常。
7：要用异常
不要使用这种代码：
public bool Insert(Model model) { //some other code Dal dal = new Dal(); if (dal.Insert(model)) { return true; } else { return false; } }
直接让异常往上抛，
public bool Insert(Model model) { //some other code new Dal(.Insert(model)); }
直到某个地方愿意处理地方。
8：方法内的代码属于一个层级
穿衣服，穿裤子属于一个层级。穿衣服，造汽车，就不是同一个层级。
9：Dispose
如果某个东西需要 Close，就应该实现 IDispose。
10：Static Or Not
如果该类需要进入单元测试，则它不应该是 Static 的。如果静态了，代码就是在测试的收你得额外增加一个包装类。
11：Shotgun Surgery（霰弹式修改）
现象：当外部条件发生变化时，每次需要修改多个Class来适应这些变化，影响到很多地方。就像霰弹一样，发散到多个地方。
重构策略：使用Move Method和Move Field将Class中需要修改的方法及成员变量移植到同一个Class中。如果没有合适的Class，则创建一个新Class。实现目标是，将需要修改的地方集中到一个Class中进行处理。
12：Feature Envy（依恋情结）
现象：Class中某些方法“身在曹营心在汉”，没有安心使用Class中的成员变量，而需要大量访问另外Class中的成员变量。这样就违反了对象技术的基本定义：将数据和操作行为（方法）包装在一起。
重构策略：使用Move Method将这些方法移动到对应的Class中，以化解其“相思之苦”，让其牵手。
13：组合与继承，你有两种选择
这里无所谓说哪种好，哪种坏，看情况，以下是这两种的表现形式，你可以进行互转。
namespace LosTechies.DaysOfRefactoring.ReplaceInheritance.Before { public class Sanitation { public string WashHands() { return "Cleaned!"; } }
public class Child : Sanitation { } }
namespace LosTechies.DaysOfRefactoring.ReplaceInheritance.After { public class Sanitation { public string WashHands() { return "Cleaned!"; } }
public class Child { private Sanitation Sanitation { get; set; }
public Child() { Sanitation = new Sanitation(); }
public string WashHands() { return Sanitation.WashHands(); } } }
14：分解复杂判断
复杂的判断基础总是要分解的，因为它太容易阅读了，写注释？注释一坨 Shit？
namespace LosTechies.DaysOfRefactoring.SampleCode.ArrowheadAntipattern.Before { public class Security { public ISecurityChecker SecurityChecker { get; set; }
public Security(ISecurityChecker securityChecker) { SecurityChecker = securityChecker; }
public bool HasAccess(User user, Permission permission, IEnumerable<Permission> exemptions) { bool hasPermission = false;
if (user != null) { if (permission != null) { if (exemptions.Count() == 0) { if (SecurityChecker.CheckPermission(user, permission) || exemptions.Contains(permission)) { hasPermission = true; } } } }
return hasPermission; } } }
namespace LosTechies.DaysOfRefactoring.SampleCode.ArrowheadAntipattern.After { public class Security { public ISecurityChecker SecurityChecker { get; set; }
public Security(ISecurityChecker securityChecker) { SecurityChecker = securityChecker; }
public bool HasAccess(User user, Permission permission, IEnumerable<Permission> exemptions) { if (user == null || permission == null) return false;
if (exemptions.Contains(permission)) return true;
return SecurityChecker.CheckPermission(user, permission); } } }
15：尽快返回
实际上，该条是要求我们，可以在方法内部多使用 return，直到最后才 return，会使得最终结果看起来很复杂；
二：盖房子
1：寻找边界
架构的第一原则，是寻找边界，最直观的成果物就是建立几个解决方案，解决方案内有多少个项目。划边界的最终目的就是要告诉组员：什么样的代码应该编写到哪个解决方案中。
2：建立公共库
任何解决方案几乎都需要一个公共库，用于放置一些 Helper 类。
3：资源可以作为一个单独的项目
不同的资源可以独立成为不同的项目，图片、JS、Style字典、配置文件等，都可以作为资源。另外，第三方的 DLL 也需要作为资源独立出来，把它们注册到全局程序集中不如直接作为 Content 包含进项目来的舒爽。
4：客户端逻辑最小化
.NET 程序最让人诟病的是：混淆了也可窥测你的源码。除了这个原因，从解耦的角度看，UI 或者其它客户端项目，都应该知道更少的逻辑才好。
5：基于测试的与MVC、MVVM、MVP
如果一开始你并不知道什么是 MVC 或者 MVVM，那么没关系，先试着掌握单元测试，把代码写成基于测试的。我有一个激进的观点是，所有的架构模式，其实目的都是为了代码可测试。
6：AOP
权限认证是典型的面向切面编程。不是 Attribute 才能带来 AOP 思想，把要运行的代码交给一个 Action ，也能实现 AOP。
7：模版模式、继承与多态
继承不是多态，继承的另一个价值叫做：模版模式。如果一件 Case 有多个实现途径，它就应该是模版的，因为你总能找到一些方法放置到父类中去；
8：工厂模式与工厂
类不是被调用者 new 出来的，而是调用某个类的某个方法后被返回出来的，就叫做工厂模式。这类也叫做对象容器。对象容器也可以很复杂，复杂到叫做一个框架，比如 Unity。
9：观察者模式、事件通知
事件就是观察者模式。解耦也可以使用观察者模式来实现。
10：接口的存在都是有目的的
自从 面向接口编程 这个概念提出来后，接口就开始变得漫天飞。接口的出现不能基于某种假设，而是实际已经发生了作用。
11：避免二转手的代码
二转手的代码常常来自于所谓三层架构代码，UI-BLL-DAL，然后 BLL 中的大量方法实际就只有一句话 Dal.Update(model)，老实说，我受够了这样的代码。
12：见到条件，就考虑是否使用策略模式
“使用策略类” 是指用设计模式中的策略模式来替换原来的switch case和if else语句，这样可以解开耦合，同时也使维护性和系统的可扩展性大大增强。
如下面代码所示，ClientCode 类会更加枚举State的值来调用ShippingInfo 的不同方法，但是这样就会产生很多的判断语句，如果代码量加大，类变得很大了的话，维护中改动也会变得很大，每次改动一个地方，都要对整个结构进行编译（假如是多个工程），所以我们想到了对它进行重构，剥开耦合。
namespace LosTechies.DaysOfRefactoring.SwitchToStrategy.Before
{
public class ClientCode
{
public decimal CalculateShipping()
{
ShippingInfo shippingInfo = new ShippingInfo();
return shippingInfo.CalculateShippingAmount(State.Alaska);
}
}
public enum State
{
Alaska,
NewYork,
Florida
}
public class ShippingInfo
{
public decimal CalculateShippingAmount(State shipToState)
{
switch (shipToState)
{
case State.Alaska:
return GetAlaskaShippingAmount();
case State.NewYork:
return GetNewYorkShippingAmount();
case State.Florida:
return GetFloridaShippingAmount();
default:
return 0m;
}
}
private decimal GetAlaskaShippingAmount()
{
return 15m;
}
private decimal GetNewYorkShippingAmount()
{
return 10m;
}
private decimal GetFloridaShippingAmount()
{
return 3m;
}
}
}
重构后的代码如下所示，抽象出一个IShippingCalculation 接口，然后把ShippingInfo 类里面的GetAlaskaShippingAmount、GetNewYorkShippingAmount、GetFloridaShippingAmount三个方法分别提炼成三个类，然后继承自IShippingCalculation 接口，这样在调用的时候就可以通过IEnumerable<IShippingCalculation> 来解除之前的switch case语句，这和IOC的做法颇为相似。
using System;
using System.Collections.Generic;
using System.Linq;
namespace LosTechies.DaysOfRefactoring.SwitchToStrategy.After_WithIoC
{
public interface IShippingInfo
{
decimal CalculateShippingAmount(State state);
}
public class ClientCode
{
[Inject]
public IShippingInfo ShippingInfo { get; set; }
public decimal CalculateShipping()
{
return ShippingInfo.CalculateShippingAmount(State.Alaska);
}
}
public enum State
{
Alaska,
NewYork,
Florida
}
public class ShippingInfo : IShippingInfo
{
private IDictionary<State, IShippingCalculation> ShippingCalculations { get; set; }
public ShippingInfo(IEnumerable<IShippingCalculation> shippingCalculations)
{
ShippingCalculations = shippingCalculations.ToDictionary(calc => calc.State);
}
public decimal CalculateShippingAmount(State shipToState)
{
return ShippingCalculations[shipToState].Calculate();
}
}
public interface IShippingCalculation
{
State State { get; }
decimal Calculate();
}
public class AlaskShippingCalculation : IShippingCalculation
{
public State State { get { return State.Alaska; } }
public decimal Calculate()
{
return 15m;
}
}
public class NewYorkShippingCalculation : IShippingCalculation
{
public State State { get { return State.NewYork; } }
public decimal Calculate()
{
return 10m;
}
}
public class FloridaShippingCalculation : IShippingCalculation
{
public State State { get { return State.Florida; } }
public decimal Calculate()
{
return 3m;
}
}
}
总结：这种重构在设计模式当中把它单独取了一个名字——策略模式，这样做的好处就是可以隔开耦合，以注入的形式实现功能，这使增加功能变得更加容易和简便，同样也增强了整个系统的稳定性和健壮性。
13：分解依赖
无抽象、静态类、静态方法都是不可单元测试的。那么，如果我们要写出可测试的代码，又要用到这些静态类等，该怎么办，实际上我们需要两个步骤：
1：为它们写一个包装类，让这个包装类是抽象的（继承自接口，或者抽象类，或者方法本身是Virtual的）；
2：通知客户端程序员，使用包装类来代替原先的静态类来写业务逻辑；
FCL 中的典型例子是：HttpResponseWrapper。