C#重构经典全面汇总
2015-08-13 10:04
85 查看
C#重构经典全面汇总
1、 封装集合
概念：本文所讲的封装集合就是把集合进行封装，只提供调用端需要的接口。正文：在很多时候，我们都不希望把一些不必要的操作暴露给调用端，只需要给它所需要的操作或数据就行，那么做法就是封装。这个重构在微软的代码库也经常遇到。比如最经典的属性对字段的封装就是一个很好的例子，那么下面我们将看到对集合的封装，如下代码所示，调用端只需要一个集合的信息，而我们则提供了一个IList的集合，大家都知道IList具有对集合的所有操作，所以这会带来很多隐患，最好的做法就是对它进行重构。
| using System.Collections.Generic; namespace LosTechies.DaysOfRefactoring.EncapsulateCollection.Before { public class Order { private List<OrderLine> _orderLines; private double _orderTotal; public IList<OrderLine> OrderLines { get { return _orderLines; } } public void AddOrderLine(OrderLine orderLine) { _orderTotal += orderLine.Total; _orderLines.Add(orderLine); } public void RemoveOrderLine(OrderLine orderLine) { orderLine = _orderLines.Find(o => o == orderLine); if (orderLine == null) return; _orderTotal -= orderLine.Total; _orderLines.Remove(orderLine); } } public class OrderLine { public double Total { get; private set; } } } |
| using System.Collections.Generic; namespace LosTechies.DaysOfRefactoring.EncapsulateCollection.After { public class Order { private List<OrderLine> _orderLines; private double _orderTotal; public IEnumerable<OrderLine> OrderLines { get { return _orderLines; } } public void AddOrderLine(OrderLine orderLine) { _orderTotal += orderLine.Total; _orderLines.Add(orderLine); } public void RemoveOrderLine(OrderLine orderLine) { orderLine = _orderLines.Find(o => o == orderLine); if (orderLine == null) return; _orderTotal -= orderLine.Total; _orderLines.Remove(orderLine); } } public class OrderLine { public double Total { get; private set; } } } |
2、 移动方法
概念：本文所讲的移动方法就是方法放在合适的位置（通常指放在合适的类中）。正文：移动方法是一个很简单也很常见的重构，只要是系统就会存在很多类，那么类里面包括很多方法，如果一个方法经常被另外一个类使用（比本身的类使用还多）或者这个方法本身就不应该放在这个类里面，那么这个适合应该考虑把它移到合适的类中。代码如下：
| namespace LosTechies.DaysOfRefactoring.MoveMethod.Before { public class BankAccount { public BankAccount(int accountAge, int creditScore, AccountInterest accountInterest) { AccountAge = accountAge; CreditScore = creditScore; AccountInterest = accountInterest; } public int AccountAge { get; private set; } public int CreditScore { get; private set; } public AccountInterest AccountInterest { get; private set; } public double CalculateInterestRate() { if (CreditScore > 800) return 0.02; if (AccountAge > 10) return 0.03; return 0.05; } } public class AccountInterest { public BankAccount Account { get; private set; } public AccountInterest(BankAccount account) { Account = account; } public double InterestRate { get { return Account.CalculateInterestRate(); } } public bool IntroductoryRate { get { return Account.CalculateInterestRate() < 0.05; } } } } |
| namespace LosTechies.DaysOfRefactoring.MoveMethod.After { public class AccountInterest { public BankAccount Account { get; private set; } public AccountInterest(BankAccount account) { Account = account; } public double InterestRate { get { return CalculateInterestRate(); } } public bool IntroductoryRate { get { return CalculateInterestRate() < 0.05; } } public double CalculateInterestRate() { if (Account.CreditScore > 800) return 0.02; if (Account.AccountAge > 10) return 0.03; return 0.05; } } } namespace LosTechies.DaysOfRefactoring.MoveMethod.After { public class BankAccount { public BankAccount(int accountAge, int creditScore, AccountInterest accountInterest) { AccountAge = accountAge; CreditScore = creditScore; AccountInterest = accountInterest; } public int AccountAge { get; private set; } public int CreditScore { get; private set; } public AccountInterest AccountInterest { get; private set; } } } |
3、 提升方法
概念：提升方法是指将一个很多继承类都要用到的方法提升到基类中。正文：提升方法是指将一个很多继承类都要用到的方法提升到基类中，这样就能减少代码量，同时让类的结构更清晰。如下代码所示，Turn方法在子类Car和Motorcycle
都会用到，因为Vehicle 都会有这个方法，所以我们就会想到把它提到基类中。
| namespace LosTechies.DaysOfRefactoring.PullUpMethod.Before { public abstract class Vehicle { // other methods } public class Car : Vehicle { public void Turn(Direction direction) { // code here } } public class Motorcycle : Vehicle { } public enum Direction { Left, Right } } |
都具有Turn这个方法，如果这个方法修改也只需要修改基类即可，所以给维护和以后的重构带来了方便。
| namespace LosTechies.DaysOfRefactoring.PullUpMethod.After { public abstract class Vehicle { public void Turn(Direction direction) { // code here } } public class Car : Vehicle { } public class Motorcycle : Vehicle { } public enum Direction { Left, Right } } |
4、 降低方法
概念：本文中的降低方法和前篇的提升方法整好相反，也就是把个别子类使用到的方法从基类移到子类里面去。正文：如下代码所示，Animal 类中的方法Bark只有在其子类Dog 中使用，所以最好的方案就是把这个方法移到子类Dog 中。
| namespace LosTechies.DaysOfRefactoring.PushDownMethod.Before { public abstract class Animal { public void Bark() { // code to bark } } public class Dog : Animal { } public class Cat : Animal { } } |
类。
| namespace LosTechies.DaysOfRefactoring.PushDownMethod.After { public abstract class Animal { } public class Dog : Animal { public void Bark() { // code to bark } } public class Cat : Animal { } } |
5、 提升字段
概念：本文中的提升字段和前面的提升方法颇为相似，就是把子类公用的字段提升到基类中，从而达到公用的目的。正文：如下代码所示， Account 的两个子类CheckingAccount
和SavingsAccount 都有minimumCheckingBalance 字段，所以可以考虑把这个字段提到基类中。
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace LosTechies.DaysOfRefactoring.PullUpField.Before
{
publicabstract class Account
{
}
public classCheckingAccount
: Account
{
privatedecimal _minimumCheckingBalance = 5m;
}
public classSavingsAccount
: Account
{
private decimal_minimumSavingsBalance = 5m;
}
}
重构后的代码如下，这样提的前提是这些子类有一个基类或者有很多相似的字段和方法，不然为了一个字段而单独建立一个抽象类是不可取的，所以这个就需要具体权衡。
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace LosTechies.DaysOfRefactoring.PullUpField.After
{
publicabstract class Account
{
protecteddecimal _minimumBalance = 5m;
}
public classCheckingAccount
: Account
{
}
public classSavingsAccount
: Account
{
}
}
总结：这个重构的策略比较简单，同时也是比较常用的一些做法，最主要就是要注意权衡是否真的有这个必要，看这样做究竟有没有什么好处（比如只需要改一个地方，维护简便了，同时代码量也更少了等）。
6、 降低字段
概念：本文中的降低字段和前篇的提升字段正好相反，就是把基类中只有某些少数类用到的字段降低到使用它们的子类中。正文：如下代码所示，基类Task 类中的_resolution字段只会在子类BugTask
中用到，所以就考虑把它放到BugTask 类中。
namespace LosTechies.DaysOfRefactoring.PushDownField.Before
{
publicabstract class Task
{
protectedstring _resolution;
}
public classBugTask
: Task
{
}
public classFeatureTask
: Task
{
}
}
重构后的代码如下所示，这样做的好处可以简化基类，同时让其他没有使用它的子类也变得更加简单，如果这样的字段比较多的话，使用此重构也能节约一部分内存。
namespace LosTechies.DaysOfRefactoring.PushDownField.After
{
publicabstract class Task
{
}
public classBugTask
: Task
{
privatestring _resolution;
}
public classFeatureTask
: Task
{
}
}
总结：此重构也是一个非常简单的重构，在很多时候我们都会不自觉的使用它。
7、 重命名（方法，类，参数）
概念：本文中的改名（方法，类，参数）是指在写代码的时候对类、方法、参数、委托、事件等等元素取一个有意义的名称。正文：如下代码所示，加入一个公司建立一个员工的类，类中有一个员工名字的字段和一个按照小时计算员工收入的方法，那么下面代码的取名就显得很难理解了，所以我们会重构名称。
namespace LosTechies.DaysOfRefactoring.Rename.Before
{
public classPerson
{
publicstring FN {
get; set; }
publicdecimal ClcHrlyPR()
{
//code to calculate hourly payrate
return 0m;
}
}
}
重构后代码如下所示，这样看起来就非常清晰，如果有新进项目组的成员，也会变得很乐意看这个代码。
namespace LosTechies.DaysOfRefactoring.Rename.After
{
// Changedthe class name to Employee
publicclass Employee
{
publicstring FirstName {
get; set; }
publicdecimal CalculateHourlyPay()
{
//code to calculate hourly payrate
return 0m;
}
}
}
总结：此重构经常被广大程序员所忽视，但是带来的隐患是不可估量的，也许老板要修改功能，那我们来看这段没有重构的代码（就算是自己写的，但由于时间和项目多等关系，我们也很难理解了），然后就会变得焦头烂额。相反重构后的代码就会觉得一目了然、赏心悦目。
8、 使用委派代替继承
概念：本文中的“使用委派代替继承”是指在根本没有父子关系的类中使用继承是不合理的，可以用委派的方式来代替。如下代码所示，Child 和Sanitation（公共设施）是没有逻辑上的父子关系，因为小孩不可能是一个公共设施吧！所以我们为了完成这个功能可以考虑使用委派的方式。
namespace LosTechies.DaysOfRefactoring.ReplaceInheritance.Before
{
public class Sanitation
{
public string WashHands()
{
return "Cleaned!";
}
}
public class Child
: Sanitation
{
}
}
重构后的代码如下，把Sanitation 委派到Child
类中，从而可以使用WashHands这个方法，这种方式我们经常会用到，其实IOC也使用到了这个原理，可以通过构造注入和方法注入等。
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();
}
}
}
总结：这个重构是一个很好的重构，在很大程度上解决了滥用继承的情况，很多设计模式也用到了这种思想（比如桥接模式、适配器模式、策略模式等）。
9、 提取接口
概念：本文中的“提取接口” 是指超过一个的类要使用某一个类中部分方法时，我们应该解开它们之间的依赖，让调用者使用接口，这很容易实现也可以降低代码的耦合性。正文：如下代码所示，RegistrationProcessor
类只使用到了ClassRegistration 类中的Create方法和Total 字段，所以可以考虑把他们做成接口给RegistrationProcessor
调用。
namespace LosTechies.DaysOfRefactoring.ExtractInterface.Before
{
public classClassRegistration
{
publicvoid Create()
{
// createregistration code
}
publicvoid Transfer()
{
//class transfer code
}
publicdecimal Total {
get; private set; }
}
public classRegistrationProcessor
{
publicdecimal ProcessRegistration(ClassRegistrationregistration)
{
registration.Create();
returnregistration.Total;
}
}
}
重构后的代码如下，我们提取了一个IClassRegistration 接口，同时让ClassRegistration
继承此接口，然后调用端RegistrationProcessor 就可以直接通过IClassRegistration
接口进行调用。
namespace LosTechies.DaysOfRefactoring.ExtractInterface.After
{
publicinterface IClassRegistration
{
void Create();
decimal Total{ get; }
}
public classClassRegistration
: IClassRegistration
{
publicvoid Create()
{
//create registration code
}
publicvoid Transfer()
{
//class transfer code
}
publicdecimal Total {
get; private set; }
}
public classRegistrationProcessor
{
publicdecimal ProcessRegistration(IClassRegistrationregistration)
{
registration.Create();
return registration.Total;
}
}
}
总结：这个重构策略也是一个常见的运用，很多设计模式也会在其中运用此思想（如简单工程、抽象工厂等都会通过接口来解开依赖）。
10、提取方法
概念：本文中的把某些计算复杂的过程按照功能提取成各个小方法，这样就可以使代码的可读性、维护性得到提高。正文：如下代码所示，CalculateGrandTotal方法里面包含了多个逻辑，第一计算subTotal的总和，第二subTotal 要循环减去discount，也就是计算Discounts，第三就是计算Tax。所以我们可以根据功能把他们拆分成三个小方法。
using System.Collections.Generic;
namespace LosTechies.DaysOfRefactoring.ExtractMethod.Before
{
public class Receipt
{
private IList<decimal>Discounts {
get; set;}
private IList<decimal>ItemTotals {
get; set;}
public decimalCalculateGrandTotal()
{
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;
}
}
}
重构后的代码如下，然后CalculateGrandTotal方法就直接调用CalculateSubTotal、CalculateDiscounts、CalculateTax，从而是整个逻辑看起来更加清晰，并且可读性和维护性也得到了大大提高。
using System.Collections.Generic;
namespace LosTechies.DaysOfRefactoring.ExtractMethod.After
{
public class Receipt
{
private IList<decimal>Discounts {
get; set;}
private IList<decimal>ItemTotals {
get; set;}
public decimalCalculateGrandTotal()
{
decimal subTotal= CalculateSubTotal();
subTotal =CalculateDiscounts(subTotal);
subTotal = CalculateTax(subTotal);
return subTotal;
}
privatedecimal CalculateTax(decimal
subTotal)
{
decimal tax= subTotal * 0.065m;
subTotal += tax;
return subTotal;
}
privatedecimal CalculateDiscounts(decimal
subTotal)
{
if (Discounts.Count> 0)
{
foreach(decimal
discount in Discounts)
subTotal -= discount;
}
return subTotal;
}
privatedecimal CalculateSubTotal()
{
decimal subTotal= 0m;
foreach (decimal
itemTotal in ItemTotals)
subTotal += itemTotal;
return subTotal;
}
}
}
总结：这个重构在很多公司都有一些的代码规范作为参考，比如一个类不能超过多少行代码，一个方法里面不能超过多少行代码，这在一定程度上也能使程序员把这些复杂的逻辑剥离成意义很清楚的小方法。
11、使用策略类
概念：本文中的“使用策略类” 是指用设计模式中的策略模式来替换原来的switch case和if else语句，这样可以解开耦合，同时也使维护性和系统的可扩展性大大增强。正文：如下面代码所示，ClientCode 类会更加枚举State的值来调用ShippingInfo
的不同方法，但是这样就会产生很多的判断语句，如果代码量加大，类变得很大了的话，维护中改动也会变得很大，每次改动一个地方，都要对整个结构进行编译（假如是多个工程），所以我们想到了对它进行重构，剥开耦合。
namespace LosTechies.DaysOfRefactoring.SwitchToStrategy.Before
{
public class ClientCode
{
public decimalCalculateShipping()
{
ShippingInfoshippingInfo =
new ShippingInfo();
return shippingInfo.CalculateShippingAmount(State.Alaska);
}
}
public enum State
{
Alaska,
NewYork,
Florida
}
public class ShippingInfo
{
public decimalCalculateShippingAmount(State
shipToState)
{
switch (shipToState)
{
case State.Alaska:
returnGetAlaskaShippingAmount();
case State.NewYork:
returnGetNewYorkShippingAmount();
case State.Florida:
return GetFloridaShippingAmount();
default:
return0m;
}
}
privatedecimal GetAlaskaShippingAmount()
{
return 15m;
}
privatedecimal GetNewYorkShippingAmount()
{
return 10m;
}
privatedecimal 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 decimalCalculateShipping()
{
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 decimalCalculateShippingAmount(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 decimalCalculate()
{
return 15m;
}
}
public class NewYorkShippingCalculation
: IShippingCalculation
{
public State
State { get {return
State.NewYork;} }
public decimalCalculate()
{
return 10m;
}
}
public class FloridaShippingCalculation:
IShippingCalculation
{
public State
State { get {return
State.Florida;} }
public decimalCalculate()
{
return 3m;
}
}
}
总结：这种重构在设计模式当中把它单独取了一个名字——策略模式，这样做的好处就是可以隔开耦合，以注入的形式实现功能，这使增加功能变得更加容易和简便，同样也增强了整个系统的稳定性和健壮性。
12、分解依赖
概念：本文中的“分解依赖” 是指对部分不满足我们要求的类和方法进行依赖分解，通过装饰器来达到我们需要的功能。正文：正如下面代码所示，如果你要在你的代码中加入单元测试但有一部分代码是你不想测试的，那么你应用使用这个的重构。下面的例子中我们应用静态类来完成某些工作，但问题是在单元测试时我们无法mock静态类，所以我们只能引入静态类的装饰接口来分解对静态类的依赖。从而我们使我们的调用类只需要依赖于装饰接口就能完成这个操作。
namespace LosTechies.DaysOfRefactoring.BreakDependencies.Before
{
public classAnimalFeedingService
{
privatebool FoodBowlEmpty {
get; set; }
publicvoid Feed()
{
if (FoodBowlEmpty)
Feeder.ReplenishFood();
//more code to feed the animal
}
}
publicstatic class Feeder
{
publicstatic void ReplenishFood()
{
//fill up bowl
}
}
}
重构后代码如下，我们添加一个接口和一个实现类，在实现类中调用静态类的方法，所以说具体做什么事情没有改变，改变的只是形式，但这样做的一个好处是增加了了代码的可测试性。在应用了分解依赖模式后，我们就可以在单元测试的时候mock一个IFeederService对象并通过AnimalFeedingService的构造函数传递给它。这样就可以完成我们需要的功能。
namespace LosTechies.DaysOfRefactoring.BreakDependencies.After
{
public classAnimalFeedingService
{
public IFeederService
FeederService { get;
set; }
public AnimalFeedingService(IFeederService
feederService)
{
FeederService =feederService;
}
privatebool FoodBowlEmpty {
get; set; }
public void Feed()
{
if (FoodBowlEmpty)
FeederService.ReplenishFood();
//more code to feed the animal
}
}
publicinterface IFeederService
{
void ReplenishFood();
}
public classFeederService
: IFeederService
{
publicvoid ReplenishFood()
{
Feeder.ReplenishFood();
}
}
publicstatic class Feeder
{
publicstatic void ReplenishFood()
{
//fill up bowl
}
}
}
总结：这个重构在很多时候和设计模式中的一些思想类似，使用中间的装饰接口来分解两个类之间的依赖，对类进行装饰，然后使它满足我们所需要的功能。
13、提取方法对象
概念：本文中的“提取方法对象”是指当你发现一个方法中存在过多的局部变量时，你可以通过使用“提取方法对象”重构来引入一些方法，每个方法完成任务的一个步骤，这样可以使得程序变得更具有可读性。正文：如下代码所示，Order 类中的Calculate方法要完成很多功能，在之前我们用“提取方法”来进行重构，现在我们采取“提取方法对象”来完成重构。
using System.Collections.Generic;
namespace LosTechies.DaysOfRefactoring.ExtractMethodObject.Before
{
public class OrderLineItem
{
public decimal Price {
get; private set; }
}
public class Order
{
private IList<OrderLineItem> OrderLineItems {
get; set; }
private IList<decimal> Discounts {
get;set; }
private decimal Tax {
get; set; }
public decimal Calculate()
{
decimal subTotal = 0m;
// Total up line items
foreach(OrderLineItem
lineItemin OrderLineItems)
{
subTotal += lineItem.Price;
}
// Subtract Discounts
foreach
(decimaldiscount in
Discounts)
subTotal -= discount;
// CalculateTax
decimal
tax = subTotal * Tax;
// Calculate GrandTotal
decimal
grandTotal = subTotal + tax;
return grandTotal;
}
}
}
正如下代码所示，我们引入了OrderCalculator类，该类实现了所有的计算方法，Order类将自身传递给 OrderCalculator类并调用Calculate方法完成计算过程。
using System.Collections.Generic;
namespace LosTechies.DaysOfRefactoring.ExtractMethodObject.After
{
public class OrderLineItem
{
public decimal Price {
get; private set; }
}
public class Order
{
public IEnumerable<OrderLineItem> OrderLineItems {
get; private set; }
public IEnumerable<decimal> Discounts {
get;private set; }
public decimal Tax {
get; private set; }
public decimal Calculate()
{
return new OrderCalculator(this).Calculate();
}
}
public class OrderCalculator
{
private decimal SubTotal {
get; set; }
private IEnumerable<OrderLineItem> OrderLineItems {
get; set; }
private IEnumerable<decimal> Discounts {
get;set; }
private decimal Tax {
get; set; }
public OrderCalculator(Order
order)
{
OrderLineItems = order.OrderLineItems;
Discounts = order.Discounts;
Tax = order.Tax;
}
public decimal Calculate()
{
CalculateSubTotal();
SubtractDiscounts();
CalculateTax();
return SubTotal;
}
private void CalculateSubTotal()
{
// Total up line items
foreach
(OrderLineItemlineItem
in OrderLineItems)
SubTotal += lineItem.Price;
}
private void SubtractDiscounts()
{
// Subtract Discounts
foreach
(decimaldiscount in
Discounts)
SubTotal -= discount;
}
private void CalculateTax()
{
// Calculate Tax
SubTotal +=SubTotal * Tax;
}
}
}
总结：本文的重构方法在有的时候还是比较有用，但这样会造成字段的增加，同时也会带来一些维护的不便，它和“提取方法”最大的区别就是一个通过方法返回需要的数据，另一个则是通过字段来存储方法的结果值，所以在很大程度上我们都会选择“提取方法”。
14、分离职责
概念：本文中的“分离职责”是指当一个类有许多职责时，将部分职责分离到独立的类中，这样也符合面向对象的五大特征之一的单一职责原则，同时也可以使代码的结构更加清晰，维护性更高。正文：如下代码所示，Video类有两个职责，一个是处理video rental，另一个是计算每个客户的总租金。我们可以将这两个职责分离出来，因为计算每个客户的总租金可以在Customer计算，这也比较符合常理。
using System.Collections.Generic;
using System.Linq;
namespace LosTechies.DaysOfRefactoring.BreakResponsibilities.Before
{
public class Video
{
public voidPayFee(decimal
fee)
{
}
public voidRentVideo(Video
video, Customer customer)
{
customer.Videos.Add(video);
}
publicdecimal CalculateBalance(Customer
customer)
{
returncustomer.LateFees.Sum();
}
}
public class Customer
{
public IList<decimal>LateFees {
get; set;}
public IList<Video>Videos {
get; set;}
}
}
重构后的代码如下，这样Video 的职责就变得很清晰，同时也使代码维护性更好。
using System.Collections.Generic;
using System.Linq;
namespace LosTechies.DaysOfRefactoring.BreakResponsibilities.After
{
public class Video
{
public voidRentVideo(Video
video, Customer customer)
{
customer.Videos.Add(video);
}
}
public class Customer
{
public IList<decimal>LateFees {
get; set;}
public IList<Video>Videos {
get; set;}
public voidPayFee(decimal
fee)
{
}
publicdecimal CalculateBalance(Customer
customer)
{
return customer.LateFees.Sum();
}
}
}
总结：这个重构经常会用到，它和之前的“移动方法”有几分相似之处，让方法放在合适的类中，并且简化类的职责，同时这也是面向对象五大原则之一和设计模式中的重要思想。
15、移除重复内容
概念：本文中的“移除重复内容”是指把一些很多地方都用到的逻辑提炼出来，然后提供给调用者统一调用。正文：如下代码所示，ArchiveRecord和CloseRecord都会用到Archived =
true; 和DateArchived = DateTime.Now; 这两条语句，所以我们就可以对它进行重构。
using System;
namespace LosTechies.DaysOfRefactoring.RemoveDuplication.Before
{
public class MedicalRecord
{
public DateTimeDateArchived {
get; private set; }
public bool Archived {
get; private set; }
public void ArchiveRecord()
{
Archived = true;
DateArchived = DateTime.Now;
}
public void CloseRecord()
{
Archived = true;
DateArchived = DateTime.Now;
}
}
}
重构后的代码如下所示，我们提炼了SwitchToArchived方法来封装公用的操作，然后给ArchiveRecord和CloseRecord统一调用。
using System;
namespace LosTechies.DaysOfRefactoring.RemoveDuplication.After
{
public class MedicalRecord
{
public DateTimeDateArchived {
get; private set; }
public bool Archived{
get; private set;}
public void ArchiveRecord()
{
SwitchToArchived();
}
public void CloseRecord()
{
SwitchToArchived();
}
private void SwitchToArchived()
{
Archived = true;
DateArchived = DateTime.Now;
}
}
}
总结：这个重构很简单，绝大多数程序员都会使用这种重构方法，但有时由于习惯、时间、赶进度等原因而忽略它，所以会使得整个系统杂乱无章，到处都是Ctrl+C和Ctrl+V的痕迹。
16、封装条件
概念：本文中的“封装条件”是指条件关系比较复杂时，代码的可读性会比较差，所以这时我们应当根据条件表达式是否需要参数将条件表达式提取成可读性更好的属性或者方法，如果条件表达式不需要参数则可以提取成属性，如果条件表达式需要参数则可以提取成方法。正文：如下代码所示，PerformCoolFunction里面的if条件判断比较复杂，看起来有点杂乱，所以就把它提出来。
using System;
namespace LosTechies.DaysOfRefactoring.EncapsulateConditional.Before
{
public classRemoteControl
{
privatestring[] Functions {
get; set; }
privatestring Name {
get; set; }
privateint CreatedYear {
get; set; }
publicstring PerformCoolFunction(string
buttonPressed)
{
//Determine if we are controlling some extra function
// that requires specialconditions
if (Functions.Length > 1 && Name ==
"RCA" && CreatedYear > DateTime.Now.Year - 2)
return"doSomething";
}
}
}
如下代码所示，我们把条件表达式封装成HasExtraFunctions属性，这样先前的条件判断就成了if
(HasExtraFunctions) ，所以这样就在很大程度上提高了可读性。
using System;
namespace LosTechies.DaysOfRefactoring.EncapsulateConditional.After
{
public classRemoteControl
{
privatestring[] Functions {
get; set; }
privatestring Name {
get; set; }
privateint CreatedYear {
get; set; }
privatebool HasExtraFunctions
{
get {return
Functions.Length > 1 && Name== "RCA" && CreatedYear>
DateTime.Now.Year - 2; }
}
publicstring PerformCoolFunction(string
buttonPressed)
{
//Determine if we are controlling some extra function
// that requires specialconditions
if (HasExtraFunctions)
return"doSomething";
}
}
}
总结：这个重构在很大程度上能改善代码的可读性，尤其是在一个逻辑很复杂的应用中，把这些条件判断封装成一个有意义的名字，这样很复杂的逻辑也会立刻变得简单起来。
17、提取父类
正文：Dog 类中的EatFood和Groom有可能被其他类用到，因为他们都是动物的一些公有性质，所以这个时候我们就会考虑对它进行提炼。namespace LosTechies.DaysOfRefactoring.ExtractSuperclass.Before
{
public classDog
{
publicvoid EatFood()
{
//eat some food
}
public void Groom()
{
//perform grooming
}
}
}
代码如下所示，提取了Animal 方法来封装公用的EatFood和Groom类，从而使其他继承了Animal 类的子类都可以使用这两个方法了。
namespace LosTechies.DaysOfRefactoring.ExtractSuperclass.After
{
public classAnimal
{
publicvoid EatFood()
{
//eat some food
}
publicvoid Groom()
{
//perform grooming
}
}
public classDog
: Animal
{
}
}
总结：这个重构是典型的继承用法，很多程序员都会选择这样做，但是要注意正确的使用，不要造成过度使用了继承，如果过度使用了，请考虑用接口、组合和聚合来实现。
18、使用条件判断代替异常
概念：本文中的“使用条件判断代替异常”是指把没有必要使用异常做判断的条件尽量改为条件判断。正文：如下代码所示，在日常的编码中我们经常需要用到异常来控制程序流，Start方法里面用try
catch 做条件判断，我们知道这里没有必要使用这种方式，因为你不需要做类型不可控的类型转换，也不需要处理异常行为，所以我们应该对它进行重构。
namespace LosTechies.DaysOfRefactoring.ReplaceException.Before
{
public classMicrowave
{
private IMicrowaveMotorMotor {
get; set;}
publicbool Start(object
food)
{
boolfoodCooked =
false;
try
{
Motor.Cook(food);
foodCooked = true;
}
catch(InUseException)
{
foodcooked = false;
}
return foodCooked;
}
}
}
重构后的代码如下所示，try catch做条件判断的语句改成了if
return的方式，这样在很多程度上统一了代码的书写，同时也提高了性能。
namespace LosTechies.DaysOfRefactoring.ReplaceException.After
{
public classMicrowave
{
private IMicrowaveMotorMotor {
get; set;}
publicbool Start(object
food)
{
if (Motor.IsInUse)
returnfalse;
Motor.Cook(food);
returntrue;
}
}
}
总结： 这个重构在项目代码中也经常用到，因为对于一部分程序员，是很难把握什么时候用try
catch ，什么地方该用try
catch。记得之前大家还专门讨论过这些，比如如何用好以及在大中型项目中应该把它放在哪一个组件中等。
19、提取工厂类
概念：本文中的“提取工厂类”是指如果要创建的对象很多，则代码会变的很复杂。一种很好的方法就是提取工厂类。正文：一般来说我们需要在代码中设置一些对象，以便获得它们的状态，从而使用对象，所谓的设置通常来说就是创建对象的实例并调用对象的方法。有时如果要创建的对象很多，则代码会变的很复杂。这便是工厂模式发挥作用的情形。工厂模式的复杂应用是使用抽象工厂创建对象集，但我们在这里只是使用基本的工厂类创建对象的一个简单应用。
如下代码所示，New方法包含创建类的整个逻辑，如果现在要创建的类比较多而且逻辑比较复杂的话（如根据不同条件创建对象，什么时候创建对象），我们的New方法逻辑会变得很大，同时代码也变得很难维护。所以我们就会采用提取工厂类的方式进行提炼。
namespace LosTechies.DaysOfRefactoring.ExtractServiceClass.Before
{
public class PoliceCarController
{
public PoliceCarNew(int
mileage, bool serviceRequired)
{
PoliceCarpoliceCar = new PoliceCar();
policeCar.ServiceRequired = serviceRequired;
policeCar.Mileage = mileage;
return policeCar;
}
}
}
那么重构后的代码如下，New方法变得很简单了，指需要调用实现接IPoliceCarFactory
接口的PoliceCarFactory 类就可以返回对象，这样就隔开了创建对象的逻辑，如果需求现在变为根据不同的条件创建不同的对象，什么时候创建对象等都变成了比较简单的事情，在后期可以把对象都配置在XML里面，使用反射的方式实现IOC注入创建。
namespace LosTechies.DaysOfRefactoring.ExtractServiceClass.After
{
publicinterface IPoliceCarFactory
{
PoliceCar Create(int mileage,
bool serviceRequired);
}
public classPoliceCarFactory
: IPoliceCarFactory
{
public PoliceCarCreate(int
mileage, boolserviceRequired)
{
PoliceCar policeCar = new PoliceCar();
policeCar.ReadForService =serviceRequired;
policeCar.Mileage = mileage;
returnpoliceCar;
}
}
public classPoliceCarController
{
public IPoliceCarFactory
PoliceCarFactory { get;
set; }
public PoliceCarController(IPoliceCarFactory
policeCarFactory)
{
PoliceCarFactory =policeCarFactory;
}
public PoliceCarNew(int
mileage, bool serviceRequired)
{
returnPoliceCarFactory.Create(mileage, serviceRequired);
}
}
}
总结：这个重构经常会在项目中使用，如果要创建的对象是一个，你可以采用简单工厂，但是这种方式还是会存在很多依赖，维护起来也比较不方便。所以推荐使用工厂方法模式，把实例化延迟到子类。如果你要创建一系列的对象，那么就推荐你使用抽象工厂模式，但是要注意不要过度设计，只要能满足不断变化的需求和给以后的维护和重构带来方便即可。
20、提取子类
概念：本文中的”提取子类”是指把基类中的一些不是所有子类都需要访问的方法调整到子类中。正文：当你的基类中存在一些方法不是所有的子类都需要访问，你想将它们调整到子类中时，这个重构会变得很有用了。如下代码所示，我们需要一个 Registration类用来处理学生选课的信息。但是当Registration类开始工作后，我们意识到我们会在两种不同的上下文中使用 Registration类，NonRegistrationAction和Notes只有在我们处理未注册情况下才用到。
所以我们将NonRegistration和Notes提到单独的NonRegistration类中。
using System;
namespace LosTechies.DaysOfRefactoring.SampleCode.ExtractSubclass.Before
{
public classRegistration
{
public NonRegistrationActionAction {
get; set;}
publicdecimal RegistrationTotal {
get; set; }
publicstring Notes {
get; set; }
publicstring Description {
get; set; }
public DateTime
RegistrationDate { get;
set; }
}
}
重构后的代码如下所示，这样也满足面向对象五大原则之一的单一职责。同时也让类的结构变得更加清晰，增强了可维护性。
using System;
namespace LosTechies.DaysOfRefactoring.SampleCode.ExtractSubclass.After
{
public classRegistration
{
publicdecimal RegistrationTotal {
get; set; }
publicstring Description {
get; set; }
public DateTime
RegistrationDate { get;
set; }
}
public classNonRegistration
: Registration
{
public NonRegistrationActionAction {
get; set;}
publicstring Notes {
get; set; }
}
}
总结：这个重构方法经常用来规范类的职责，和之前的一些重构方法也有些类似。
21、合并继承
概念：本文中的”合并继承”是指如果子类的属性和方法也适合于基类，那么就可以移除子类，从而减少依赖关系。正文：上一篇我们讲到“提取子类”重构是指当基类中的一个责任不被所有的子类所需要时，将这些责任提取到合适的子类中。而我们今天所要讲的的“合并继承”重构一般用在当我们觉得不需要子类的时候。
如下代码所示，StudentWebSite子类除了有一个属性用来说明网站是否是活动的外没有别的责任，在这种情形下我们意识到IsActive属性可以应用到所有的网站，所以我们可以将IsActive属性上移到基类中，并去掉StudentWebSite类。
using System.Collections.Generic;
namespace LosTechies.DaysOfRefactoring.SampleCode.CollapseHierarchy.Before
{
public class Website
{
public string Title {
get; set; }
public string Description {
get; set; }
public IEnumerable<Webpage>Pages {
get; set;}
}
public class StudentWebsite:
Website
{
public bool IsActive {
get; set; }
}
}
重构后的代码如下：
using System.Collections.Generic;
namespace LosTechies.DaysOfRefactoring.SampleCode.CollapseHierarchy.After
{
public class Website
{
public string Title {
get; set; }
public string Description {
get; set; }
public IEnumerable<Webpage>Pages {
get; set;}
public bool IsActive {
get; set; }
}
}
总结： 这篇和上篇其实最主要论述了子类和父类的继承关系以及如何判断什么时候需要使用继承，一般我们都能处理好这些关系，所以相对比较简单。
22、分解方法
概念：本文中的”分解方法”是指把我们所做的这个功能不停的分解方法，直到将一个大方法分解为名字有意义且可读性更好的若干个小方法。正文：如下代码所示，因为现实中AcceptPayment方法不会做这么多的事情。，所以我们通过几次分解将 AcceptPayment拆分成若干个名字有意义且可读性更好的小方法。
using System.Collections.Generic;
using System.Linq;
namespace LosTechies.DaysOfRefactoring.SampleCode.BreakMethod.Before
{
public classCashRegister
{
public CashRegister()
{
Tax = 0.06m;
}
privatedecimal Tax {
get; set; }
public void AcceptPayment(Customer
customer, IEnumerable<Product> products,
decimalpayment)
{
decimalsubTotal = 0m;
foreach(Product
product in products)
{
subTotal +=product.Price;
}
foreach(Product
product in products)
{
subTotal -=product.AvailableDiscounts;
}
decimalgrandTotal = subTotal * Tax;
customer.DeductFromAccountBalance(grandTotal);
}
}
public classCustomer
{
publicvoid DeductFromAccountBalance(decimal
amount)
{
//deduct from balance
}
}
public classProduct
{
publicdecimal Price {
get; set; }
publicdecimal AvailableDiscounts {
get; set; }
}
}
重构后的代码如下，我们把AcceptPayment的内部逻辑拆分成了CalculateSubtotal、SubtractDiscounts、AddTax、SubtractFromCustomerBalance四个功能明确且可读性更好的小方法。
using System.Collections.Generic;
namespace LosTechies.DaysOfRefactoring.SampleCode.BreakMethod.After
{
public classCashRegister
{
public CashRegister()
{
Tax = 0.06m;
}
privatedecimal Tax {
get; set; }
private IEnumerable<Product>Products {
get; set;}
publicvoid AcceptPayment(Customer
customer,IEnumerable<Product>products,
decimal payment)
{
decimalsubTotal = CalculateSubtotal();
subTotal =SubtractDiscounts(subTotal);
decimalgrandTotal = AddTax(subTotal);
SubtractFromCustomerBalance(customer,grandTotal);
}
privatevoid SubtractFromCustomerBalance(Customer
customer,decimal grandTotal)
{
customer.DeductFromAccountBalance(grandTotal);
}
privatedecimal AddTax(decimal
subTotal)
{
returnsubTotal * Tax;
}
privatedecimal SubtractDiscounts(decimal
subTotal)
{
foreach(Product
product in Products)
{
subTotal -= product.AvailableDiscounts;
}
returnsubTotal;
}
privatedecimal CalculateSubtotal()
{
decimalsubTotal = 0m;
foreach(Product
product in Products)
{
subTotal += product.Price;
}
returnsubTotal;
}
}
public classCustomer
{
publicvoid DeductFromAccountBalance(decimal
amount)
{
//deduct from balance
}
}
public classProduct
{
publicdecimal Price {
get; set; }
publicdecimal AvailableDiscounts {
get; set; }
}
}
总结：其实这个重构和我们前面讲的“提取方法”和“提取方法对象”如出一辙，尤其是“提取方法”，所以大家只要知道用这种思想重构就行。
23、引入参数对象
概念：本文中的“引入参数对象”是指当一个方法的参数过多或者过为复杂时，可以考虑把这些参数封装成一个单独的类。正文：如果一个方法所需要的参数大于5个，理解该方法的签名就变得比较困难，因为这样感觉参数很长、样式不好并且没有分类，所以我们有必要把参数进行封装。
namespace LosTechies.DaysOfRefactoring.SampleCode.ParameterObject.Before
{
public classRegistration
{
publicvoid Create(decimal
amount, Studentstudent, IEnumerable<Course> courses,
decimal credits)
{
//do work
}
}
}
通常这种情形下创建一个用户传递参数的类是很有帮助的，这会使得代码更容易明白也更灵活，因为当你需要增加参数时，只需要给参数类添加一个属性即可。请注意只有当你发现方法的参数比较多时才应该应用该重构，如果方法的参数比较少，就没有必要应用此重构，因为该重构会增加系统中类的数量，同时也会加大维护负担。所以要看参数情况而定。
重构后的代码如下：
using System.Collections.Generic;
namespace LosTechies.DaysOfRefactoring.SampleCode.ParameterObject.After
{
public classRegistrationContext
{
publicdecimal Amount {
get; set; }
public StudentStudent {
get; set;}
public IEnumerable<Course> Courses {
get; set; }
publicdecimal Credits {
get; set; }
}
public classRegistration
{
publicvoid Create(RegistrationContext
registrationContext)
{
//do work
}
}
}
总结：这种重构很重要，尤其是当一个方法的参数比较多的时候，不管是大中型项目还是小型项目，都会遇到这种场景，所以建议大家多使用这个重构。这种封装的思想在SOA 里面也经常运用到，封装输入Message，封装输出Message，消息来和消息去以及消息间的交互就构成了整个应用体系。
24、分解复杂判断
概念：本文中的”分解复杂判断”是指把原来复杂的条件判断等语句用尽快返回等方式简化代码。正文：简单的来说，当你的代码中有很深的嵌套条件时，花括号就会在代码中形成一个长长的箭头。我们经常在不同的代码中看到这种情况，并且这种情况也会扰乱代码的可读性。
如下代码所示，HasAccess方法里面包含一些嵌套条件，如果再加一些条件或者增加复杂度，那么代码就很可能出现几个问题：1，可读性差。 2，很容易出现异常。 3，性能较差。
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace LosTechies.DaysOfRefactoring.SampleCode.ArrowheadAntipattern.Before
{
public classSecurity
{
public ISecurityCheckerSecurityChecker {
get; set;}
public Security(ISecurityCheckersecurityChecker)
{
SecurityChecker =securityChecker;
}
publicbool HasAccess(User user, Permission permission,
IEnumerable<Permission> exemptions)
{
boolhasPermission =
false;
if (user!= null)
{
if(permission !=
null)
{
if (exemptions.Count() == 0)
{
if (SecurityChecker.CheckPermission(user, permission)|| exemptions.Contains(permission))
{
hasPermission= true;
}
}
}
}
returnhasPermission;
}
}
}
那么重构上面的代码也很简单，如果有可能的话，尽量将条件从方法中移除，我们让代码在做处理任务之前先检查条件，如果条件不满足就尽快返回，不继续执行。下面是重构后的代码：
using System.Collections.Generic;
using System.Linq;
namespace LosTechies.DaysOfRefactoring.SampleCode.ArrowheadAntipattern.After
{
public classSecurity
{
public ISecurityCheckerSecurityChecker {
get; set;}
public Security(ISecurityCheckersecurityChecker)
{
SecurityChecker = securityChecker;
}
publicbool HasAccess(User user, Permission permission,
IEnumerable<Permission> exemptions)
{
if (user== null
|| permission == null)
returnfalse;
if (exemptions.Contains(permission))
returntrue;
returnSecurityChecker.CheckPermission(user, permission);
}
}
}
总结：这个重构很重要，它和后面讲的”尽快返回“有些类似，我们在做复杂的处理过程时，要经常考虑这个重构，用好了它，会对我们的帮助很大。
25、引入契约式设计
概念：本文中的”引入契约式设计”是指我们应该对应该对输入和输出进行验证，以确保系统不会出现我们所想象不到的异常和得不到我们想要的结果。正文：契约式设计规定方法应该对输入和输出进行验证，这样你便可以保证你得到的数据是可以工作的，一切都是按预期进行的，如果不是按预期进行，异常或是错误就应该被返回，下面我们举的例子中，我们方法中的参数可能会值为null的情况，在这种情况下由于我们没有验证，NullReferenceException异常会报出。另外在方法的结尾处我们也没有保证会返回一个正确的decimal值给调用方法的对象。
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace LosTechies.DaysOfRefactoring.SampleCode.Day25_DesignByContract
{
public class CashRegister
{
public decimal TotalOrder(IEnumerable<Product> products, Customercustomer)
{
decimal orderTotal =products.Sum(product => product.Price);
customer.Balance += orderTotal;
return orderTotal;
}
}
}
对上面的代码重构是很简单的，首先我们处理不会有一个null值的customer对象，检查我们最少会有一个product对象。在返回订单总和 之前先确保我们会返回一个有意义的值。如果上面说的检查有任何一个失败，我们就抛出对应的异常，并在异常里说明错误的详细信息，而不是直接抛出 NullReferenceException。
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Microsoft.Contracts;
namespace LosTechies.DaysOfRefactoring.SampleCode.DesignByContract.After
{
public class CashRegister
{
public decimal TotalOrder(IEnumerable<Product> products, Customercustomer)
{
if (customer ==
null)
thrownew ArgumentNullException("customer",
"Customercannot be null");
if (products.Count()== 0)
thrownew ArgumentException("Must have at least one product to total","products");
decimal orderTotal =products.Sum(product => product.Price);
customer.Balance += orderTotal;
if (orderTotal== 0)
thrownew ArgumentOutOfRangeException("orderTotal",
"OrderTotal should not be zero");
return orderTotal;
}
}
}
上面的代码中添加了额外的代码来进行验证，虽然看起来代码复杂度增加了，但我认为这是非常值得做的，因为当NullReferenceException发生时去追查异常的详细信息真是很令人讨厌的事情。
总结：微软在处理代码乃至产品的时候，很喜欢应用此重构，你如果认真看它的代码库，认真看一下WCF的设计，就不难发现了。这个重构建议大家经常使用，这会增强整个系统的稳定性和健壮性。
26、避免双重否定
概念：本文中的”避免双重否定”是指把代码中的双重否定语句修改成简单的肯定语句，这样即让代码可读，同时也给维护带来了方便。正文：避免双重否定重构本身非常容易实现，但我们却在太多的代码中见过因为双重否定降低了代码的可读性以致于非常让人容易误解真正意图。存在双重否定的代码具有非常大的危害性，因为这种类型的代码容易引起错误的假设，错误的假设又会导致书写出错误的维护代码，最终会导致bug产生。具 体可以看下面的代码：
using System.Collections.Generic;
using LosTechies.DaysOfRefactoring.SampleCode.BreakMethod.After;
namespace LosTechies.DaysOfRefactoring.SampleCode.DoubleNegative.Before
{
publicclass Order
{
publicvoid Checkout(IEnumerable<Product> products,
Customer customer)
{
if (!customer.IsNotFlagged)
{
//the customer account is flagged
// log some errors andreturn
return;
}
//normal order processing
}
}
publicclass Customer
{
publicdecimal Balance {
get; private set; }
publicbool IsNotFlagged
{
get { return
Balance < 30m; }
}
}
}
如上代码中的双重否定可读性非常低，因为我们很难搞明白双重否定的正确值。要重构它也非常容易，如下是重构后的代码：
using System.Collections.Generic;
using LosTechies.DaysOfRefactoring.SampleCode.BreakMethod.After;
namespace LosTechies.DaysOfRefactoring.SampleCode.DoubleNegative.After
{
public classOrder
{
publicvoid Checkout(IEnumerable<Product>products,
Customer customer)
{
if (customer.IsFlagged)
{
//the customer account is flagged
// log some errors andreturn
return;
}
//normal order processing
}
}
public classCustomer
{
publicdecimal Balance {
get; private set; }
publicbool IsFlagged
{
get { return
Balance >= 30m; }
}
}
}
总结： ”双重否定“很容易让人产生错误的判断，也很难让人理解你的代码，所以这个重构在我们的代码中是很重要的，尤其是在判断条件很多且业务复杂的时候。
27、去除上帝类
概念：本文中的”去除上帝类”是指把一个看似功能很强且很难维护的类，按照职责把自己的属性或方法分派到各自的类中或分解成功能明确的类，从而去掉上帝类。正文：我们经常可以在一些原来的代码中见到一些类明确违反了SRP原则（单一原则），这些类通常以“Utils”或“Manager”后缀 结尾，但有时这些类也没有这些特征，它仅仅是多个类多个方法的组合。另一个关于上帝类的特征是通常这些类中的方法被用注释分隔为不同的分组。那么久而久之，这些类被转换为那些没有人愿意进行归并到合适类的方法的聚集地，对这些类进行重构是将类中的代码按照职责分派到各自的类中，这样就解除了上帝类，也减轻了维护的负担。
| using System.Collections.Generic; using LosTechies.DaysOfRefactoring.EncapsulateCollection.After; using LosTechies.DaysOfRefactoring.SampleCode.BreakMethod.After; using Customer = LosTechies.DaysOfRefactoring.BreakResponsibilities.After.Customer; namespace LosTechies.DaysOfRefactoring.SampleCode.RemoveGodClasses.Before { public class CustomerService { public decimal CalculateOrderDiscount(IEnumerable<Product> products, Customer customer) { // do work } public bool CustomerIsValid(Customer customer, Order order) { // do work } public IEnumerable<string> GatherOrderErrors(IEnumerable<Product> products, Customer customer) { // do work } public void Register(Customer customer) { // do work } public void ForgotPassword(Customer customer) { // do work } } } |
我们看到要重构上面的代码是很简单的，只要将相关的方法按职责分派到对应的类中即可，带来的好处就是这会降低代码的颗粒度并减少未来维护代码的成本。下面是重构后的代码，它将上面
的代码按照职责分为了两个不同的类。
| using System.Collections.Generic; using LosTechies.DaysOfRefactoring.EncapsulateCollection.After; using LosTechies.DaysOfRefactoring.SampleCode.BreakMethod.After; using Customer = LosTechies.DaysOfRefactoring.BreakResponsibilities.After.Customer; namespace LosTechies.DaysOfRefactoring.SampleCode.RemoveGodClasses.After { public class CustomerOrderService { public decimal CalculateOrderDiscount(IEnumerable<Product> products, Customer customer) { // do work } public bool CustomerIsValid(Customer customer, Order order) { // do work } public IEnumerable<string> GatherOrderErrors(IEnumerable<Product> products, Customer customer) { // do work } } public class CustomerRegistrationService { public void Register(Customer customer) { // do work } public void ForgotPassword(Customer customer) { // do work } } } |
28、为布尔方法命名
概念：本文中的”为布尔方法命名”是指如果一个方法带有大量的bool参数时，可以根据bool 参数的数量，提取出若干个独立的方法来简化参数。
正文：我们现在要说的重构并不是普通字面意义上的重构，它有很多值得讨论的地方。当一个方法带有大量的bool
参数时，会导致方法很容易被误解并产生非预期的行为，
根据布尔型参数的数量，我们可以决定提取出若干个独立的方法来。具体代码如下：
| using LosTechies.DaysOfRefactoring.BreakResponsibilities.After; namespace LosTechies.DaysOfRefactoring.SampleCode.RenameBooleanMethod.Before { public class BankAccount { public void CreateAccount(Customer customer, bool withChecking, bool withSavings, bool withStocks) { // do work } } } |
提取的独立方法会有一个很大的排列组合，这是一大缺点，所以我们可以考虑引入”参数对象“重构。
| using LosTechies.DaysOfRefactoring.BreakResponsibilities.After; namespace LosTechies.DaysOfRefactoring.SampleCode.RenameBooleanMethod.After { public class BankAccount { public void CreateAccountWithChecking(Customer customer) { CreateAccount(customer, true, false); } public void CreateAccountWithCheckingAndSavings(Customer customer) { CreateAccount(customer, true, true); } private void CreateAccount(Customer customer, bool withChecking, bool withSavings) { // do work } } } |
29、去除中间人对象
概念：本文中的”去除中间人对象”是指把在中间关联而不起任何其他作用的类移除，让有关系的两个类直接进行交互。正文：有些时候在我们的代码会存在一些”幽灵类“，设计模式大师Fowler称它们为“中间人”类，“中间人”类除了调用别的对象之外不做任何事情，所以“中间人”类没有存在的必要，我们可以将它们从代码中删除，从而让交互的两个类直接关联。
如下代码所示，Consumer 类要得到AccountDataProvider
的数据，但中间介入了没起任何作用的AccountManager 类来关联，所以我们应当移除。
| using LosTechies.DaysOfRefactoring.PullUpField.After; namespace LosTechies.DaysOfRefactoring.SampleCode.RemoveMiddleMan.Before { public class Consumer { public AccountManager AccountManager { get; set; } public Consumer(AccountManager accountManager) { AccountManager = accountManager; } public void Get(int id) { Account account = AccountManager.GetAccount(id); } } public class AccountManager { public AccountDataProvider DataProvider { get; set; } public AccountManager(AccountDataProvider dataProvider) { DataProvider = dataProvider; } public Account GetAccount(int id) { return DataProvider.GetAccount(id); } } public class AccountDataProvider { public Account GetAccount(int id) { // get account } } } |
重构后的代码如下所示，Consumer 和AccountDataProvider 直接进行关联，这样代码就简单了。
| using LosTechies.DaysOfRefactoring.PullUpField.After; namespace LosTechies.DaysOfRefactoring.SampleCode.RemoveMiddleMan.After { public class Consumer { public AccountDataProvider AccountDataProvider { get; set; } public Consumer(AccountDataProvider dataProvider) { AccountDataProvider = dataProvider; } public void Get(int id) { Account account = AccountDataProvider.GetAccount(id); } } public class AccountDataProvider { public Account GetAccount(int id) { // get account } } } |
30、尽快返回
概念： 本文中的”尽快返回”是指把原来复杂的条件判断等语句用尽快返回的方式简化代码。正文：如首先声明的是前面讲的”分解复杂判断“，简单的来说，当你的代码中有很深的嵌套条件时，花括号就会在代码中形成一个长长的箭头。我们经常在不同的代码中看到这种情况，并且这种情况也会扰乱代码的可读性。下代码所示，HasAccess方法里面包含一些嵌套条件，如果再加一些条件或者增加复杂度，那么代码就很可能出现几个问题：1，可读性差 2，很容易出现异常 3，性能较差
| using System.Collections.Generic; using System.Linq; using LosTechies.DaysOfRefactoring.SampleCode.BreakMethod.After; using Customer = LosTechies.DaysOfRefactoring.BreakResponsibilities.After.Customer; namespace LosTechies.DaysOfRefactoring.SampleCode.ReturnASAP.Before { public class Order { public Customer Customer { get; private set; } public decimal CalculateOrder(Customer customer, IEnumerable<Product> products, decimal discounts) { Customer = customer; decimal orderTotal = 0m; if (products.Count() > 0) { orderTotal = products.Sum(p => p.Price); if (discounts > 0) { orderTotal -= discounts; } } return orderTotal; } } } |
那么重构上面的代码也很简单，如果有可能的话，尽量将条件判断从方法中移除，我们让代码在做处理任务之前先检查条件，如果条件不满足就尽快返回，不继续执行。
下面是重构后的代码：
| using System.Collections.Generic; using System.Linq; using LosTechies.DaysOfRefactoring.SampleCode.BreakMethod.After; using Customer = LosTechies.DaysOfRefactoring.BreakResponsibilities.After.Customer; namespace LosTechies.DaysOfRefactoring.SampleCode.ReturnASAP.After { public class Order { public Customer Customer { get; private set; } public decimal CalculateOrder(Customer customer, IEnumerable<Product> products, decimal discounts) { if (products.Count() == 0) return 0; Customer = customer; decimal orderTotal = products.Sum(p => p.Price); if (discounts == 0) return orderTotal; orderTotal -= discounts; return orderTotal; } } } |
31、使用多态代替条件判断
概念：本文中的”使用多态代替条件判断”是指如果你需要检查对象的类型或者根据类型执行一些操作时，一种很好的办法就是将算法封装到类中，并利用多态性进行抽象调用。正文：本文展示了面向对象编程的基础之一“多态性”， 有时你需要检查对象的类型或者根据类型执行一些操作时，一种很好的办法就是将算法封装到类中，并利用多态性进行抽象调用。
如下代码所示，OrderProcessor 类的ProcessOrder方法根据Customer 的类型分别执行一些操作，正如上面所讲的那样，我们最好将OrderProcessor 类中这些算法（数据或操作）封装在特定的Customer 子类中。
| using System; using System.Collections.Generic; using System.Linq; using System.Text; using LosTechies.DaysOfRefactoring.SampleCode.BreakMethod.After; namespace LosTechies.DaysOfRefactoring.SampleCode.ReplaceWithPolymorphism.Before { public abstract class Customer { } public class Employee : Customer { } public class NonEmployee : Customer { } public class OrderProcessor { public decimal ProcessOrder(Customer customer, IEnumerable<Product> products) { // do some processing of order decimal orderTotal = products.Sum(p => p.Price); Type customerType = customer.GetType(); if (customerType == typeof(Employee)) { orderTotal -= orderTotal * 0.15m; } else if (customerType == typeof(NonEmployee)) { orderTotal -= orderTotal * 0.05m; } return orderTotal; } } } |
重构后的代码如下，每个Customer 子类都封装自己的算法，然后OrderProcessor 类的ProcessOrder方法的逻辑也变得简单并且清晰了。
| using System; using System.Collections.Generic; using System.Linq; using System.Text; using LosTechies.DaysOfRefactoring.SampleCode.BreakMethod.After; namespace LosTechies.DaysOfRefactoring.SampleCode.ReplaceWithPolymorphism.After { public abstract class Customer { public abstract decimal DiscountPercentage { get; } } public class Employee : Customer { public override decimal DiscountPercentage { get { return 0.15m; } } } public class NonEmployee : Customer { public override decimal DiscountPercentage { get { return 0.05m; } } } public class OrderProcessor { public decimal ProcessOrder(Customer customer, IEnumerable<Product> products) { // do some processing of order decimal orderTotal = products.Sum(p => p.Price); orderTotal -= orderTotal * customer.DiscountPercentage; return orderTotal; } } } |
内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 
相关文章推荐
- C#计算矩阵的秩实例分析
- C#使用加边法计算行列式的值
- C#绘制中国国旗的方法
- C#-遍历datatable的几种方法
- C#中一个保持事务原子性的方法，插入数据失败回滚
- C#网页爬虫抓取行政区划
- 进程与线程、应用程序域关系
- C#脚本引擎 CS-Script 之（三）——如何部署
- c#关键词operator
- C# verload,overwrite,override
- C#如何转换2位数字表示的年
- 编写高质量代码改善C#程序的157个建议——建议15： 使用dynamic来简化反射实现
- c#学习之双冒泡运算符
- 编写高质量代码改善C#程序的157个建议——建议14： 正确实现浅拷贝和深拷贝
- C#学习之Foreach
- C# ISupportInitialize的使用
- C#中out和ref之间的区别
- 编写高质量代码改善C#程序的157个建议——建议13： 为类型输出格式化字符串
- 编写高质量代码改善C#程序的157个建议——建议12： 重写Equals时也要重写GetHashCode
- C#笔记(一)