重构长方法之以方法对象取代方法

以方法对象取代方法 是重构长方法的一种技术，适用于那些过长、逻辑复杂且难以拆解的单一方法。此方法通过引入一个新的类，将原本庞杂的方法转化为一个对象方法，这样可以更容易将方法中的不同步骤拆解为多个私有方法，使代码结构清晰，易于维护。

一、问题背景

长方法常常包含多步逻辑或复杂的计算，导致代码难以理解和修改。如果只是简单地将方法分割成多个小方法，可能还不够，因为这些小方法通常需要共享一些局部变量。直接将方法拆解为多个小方法，可能会导致参数传递繁琐，难以维持一致性。

二、重构思路

通过引入一个新的类（方法对象），你可以将长方法内的逻辑逐步拆解到该类中。这样一来，局部变量可以成为方法对象的字段，从而避免在多个方法间传递大量参数，同时方法中的各个步骤也能被分离成单独的小方法，进一步提高代码的可读性。

三、重构过程

假设我们有一个非常复杂的计算方法：

public double CalculateTotalPrice(double price, double taxRate, double discount)
{double tax = price * taxRate;double discountedPrice = price - discount;double totalPrice = discountedPrice + tax；if (discountedPrice < 0){throw new ArgumentException("Discount cannot be greater than price");}//-------------------------//Long Code//-------------------------return totalPrice;
}

这是一个典型的长方法，包含了计算税费、折扣以及一些错误检查逻辑等。虽然在现在它还不算太复杂，但随着需求增加这个方法很容易变得臃肿和难以维护。

四、重构：引入方法对象

创建新类：将这个计算逻辑提取到一个新的类中，称为 PriceCalculator。
将局部变量转化为字段：在新的类中，所有的局部变量和传入参数变成类的字段。
将不同的逻辑拆分为独立方法：将各个步骤逻辑分离为私有方法，从而保持代码清晰。

重构后的代码：

public class PriceCalculator
{private double price;private double taxRate;private double discount;public PriceCalculator(double price, double taxRate, double discount){this.price = price;this.taxRate = taxRate;this.discount = discount;}public double CalculateTotalPrice(){double discountedPrice = ApplyDiscount();ValidatePrice(discountedPrice);double tax = CalculateTax();return discountedPrice + tax;}private double ApplyDiscount(){return price - discount;}private double CalculateTax(){return price * taxRate;}private void ValidatePrice(double discountedPrice){if (discountedPrice < 0){throw new ArgumentException("Discount cannot be greater than price");}}
}

调用方式：

var calculator = new PriceCalculator(price, taxRate, discount);
double totalPrice = calculator.CalculateTotalPrice();

五、优点和缺点

5.1 优点

更好地组织代码：通过方法对象将复杂的计算逻辑拆解为多个方法，代码结构变得更清晰。
减少参数传递：局部变量变成了对象的字段，不需要频繁地在方法之间传递参数。
便于后续扩展：如果未来需要对某些步骤进行修改或增加新步骤，直接在这个类中修改或添加即可，符合单一职责原则。
提高可测试性：每个方法都可以单独进行测试，方法的分离使得代码更容易被单元测试覆盖。

5.2 缺点

增加类的数量：引入新的类虽然可以组织代码，但也会增加项目中的类数量。如果每次遇到长方法都使用方法对象进行重构，可能会导致项目中有过多的小类，增加代码库的复杂性，影响类的管理和维护。
增加理解成本：对于开发人员来说，引入新类可能会使代码结构变得更加分散。尤其是在代码库中类数量较多时，理解这些类之间的关系可能需要额外的认知负担。特别是对于新成员，可能需要更多时间去理清哪些类是核心业务逻辑，哪些类是为了拆解方法而创建的。
可能带来过度设计：有时长方法中的逻辑并不复杂，直接拆分为几个私有方法即可。如果引入方法对象，可能会显得过于复杂化，属于“过度设计”。如果一个方法并不复杂，引入额外的类反而增加了不必要的复杂度。
方法对象可能缺乏复用性：方法对象通常是为了某个具体方法服务的，因此这些类通常只在一个地方使用，导致它们缺乏复用价值。除非有多个类似的长方法使用相同的逻辑，否则引入的类很可能只能局限于某一场景，增加了代码的碎片化。
调试复杂性：将一个长方法拆解成多个方法后，调试过程中可能需要频繁地跳转到不同的类和方法进行检查。如果方法的逻辑全部集中在一个地方，调试时可以一目了然；但拆解到多个方法或类后，跟踪代码执行路径可能变得更加复杂。
性能影响（极少见）：在极少数情况下，如果每次重构都会创建新的对象，并且这些对象的创建和销毁发生得非常频繁（比如在高性能的实时系统中），可能会引入额外的性能开销。不过在大多数业务系统中，这种开销微不足道。
类的职责边界模糊：方法对象是一个临时的类，专门为了处理一个方法的复杂逻辑。这些类的职责与实际业务无关，因此在架构上，这些类的职责边界可能不如业务类那么清晰。这可能会给架构的整体设计带来一些混乱。