使用流畅的接口重构长方法

Question

我想知道您对使用流畅接口模式重构长方法的看法。

http://en.wikipedia.org/wiki/Fluent_interface

流畅模式不包含在重构书籍。

例如，假设您有一个很长的方法（名称很长） 做了很多事情）

class TravelClub {

   Receipt buyAndAddPointsAndGetReceipt(long amount, long cardNumber) {
    buy(amount);
    accumulatePoints(cardNumber);
    return generateReceipt();

   }

   void buy(int amount) {...}

   void accumlatePoints(int cardNumber) {...}

   void generateRecepit() {...}

}

称为：

Receipt myReceipt = myTravelClub.buyAndAddPointsAndGetReceipt(543L,12345678L);

可以重构为：

class TravelClub {

   TravelClub buy(long amount) {
    //buy stuff
    return this;
   }

   TravelClub accumulatePoints(long cardNumber) {
    //accumulate stuff
    return this;
   }

   Receipt generateReceipt() {
    return new Receipt(...);
   }


}

并称为：

Receipt myReceipt = myTravelClub.buy(543L).accumulatePoints(12345678L).generateReceipt();

从我的角度来看，这是分解长方法的一种很好的方式，并且 亦分解其名。

你怎么认为？

Answer 1

它有一个问题，因为您必须记住积累积分并执行购买（并生成收据，这不是什么问题，因为我认为该操作没有副作用）。在我看来，积分应该在购买时自动累积。您在购买时收到收据也是很自然的，因此在某种程度上，您最初的方法很好，只是读起来不太好。

如果您想要一个流畅的界面，我会引入一个额外的类，它会温和地引导客户端代码做正确的事情（假设所有购买都是通过卡进行的，并以相同的方式累积积分）：

class TravelClub {

   OngoingPurchase buyAmount(long amount) {
      return new OngoingPurchase(amount);
   }

   private Receipt buyAndAddPointsAndGetReceipt(long amount, long cardNumber){
      // make stuff happen
   }

   public class OngoingPurchase {
      private final long amount;
      private OngoingPurchase(long amount){
         this.amount = amount;
      }
      public Receipt withCard(long cardNumber){
         return buyAndAddPointsAndGetReceipt(long amount, cardNumber);
      }
   }

}

// Usage:
Receipt receipt = travelClub.buyAmount(543).withCard(1234567890L);

这样，如果您忘记调用 < code>withCard，什么也没有发生。发现丢失的交易比发现错误的交易更容易，而且如果不执行完整的交易，您就无法获得收据。

编辑：顺便说一句，有趣的是，我们所做的所有这些工作都是为了使具有许多参数的方法可读，而例如命名参数将使问题完全消失：

Receipt r = travelClub.makePurchase(forAmount: 123, withCardNumber: 1234567890L);

Answer 2

，预期的行为是什么

myTravelClub.accumulatePoints(10000000L);

那么我的反问题是，如果有人打电话而不打电话买 ？或者在购买前生成收据？我认为流畅的界面仍然需要遵守其他面向对象的约定。如果您确实想要一个流畅的界面，那么 buy() 方法必须返回另一个对象，不是 TravelClub 本身，而是一个具有 accumulatePoints() 的“购买对象” code> 和 generateReceipt() 方法。

也许我对你的示例的语义读得太多了，但是维基百科示例具有逻辑上可以按任何顺序调用的方法是有原因的。我认为 Hibernate criteria API 是另一个很好的例子。

Answer 3

长方法与具有长名称的方法不同。就您而言，我唯一要更改的是方法名称：（

public Receipt buy(long amount, long cardNumber) {
    buy(amount);
    accumulatePoints(cardNumber);
    return generateReceipt();
}

并为私有 buy 方法考虑一个更具描述性的名称），因为所有三件事（“buying”、accumulatePoints 和获取收据）总是一起发生，因此从调用代码的角度来看，它们可以是单个操作。从实施的角度来看，单一操作也更容易。吻:-)

Answer 4

使用单一方法的优点是始终调用相同的序列。例如，您不能像在您提供的流畅界面示例中那样跳过accumulatePoints。

如果调用这些方法的唯一方法与第一个代码块中的顺序相同，请将其保留为单个函数。但是，如果在生成收据之前可以在 TravelClub 上完成任何操作子集，那么请务必使用流畅的界面。这是克服“组合爆炸”代码味道的最佳方法之一（如果不是最好的话）。

Answer 5

只要您使用了正确的验证，Fluent 接口就更容易理解，例如它可以如下所示：

class TravelClub {

   TravelClub buy(long amount) {
    buy(amount);
    return this;
   }

   TravelClub accumulatePoints(long cardNumber) {
    if (!bought)
    {
        throw new BusinessException("cannot accumulate points if not bought");
    }
    accumulatePoints(cardNumber);
    return this;
   }

   Receipt generateReceipt() {
    if (!bought)
    {
       throw new BusinessException("cannot generate receipts not bought");
    }
    return new Receipt(...);
   }
}

Answer 6

在我看来，这里的部分困难在于选择一个包含方法所做的一切的良好描述性名称。问题自然是，有时您有很多复杂的逻辑，无法用简单的名称轻松描述。

在您的代码示例中提出的情况下，我很想将方法本身的名称简化为更通用的名称：

Receipt Transaction(long amount, long cardNumber) 
{
    buy(amount);
    accumulatePoints(cardNumber);
    return generateReceipt();
}

那么我提到的这个逻辑问题又如何呢？这本身可以归结为你的方法在其功能上是否非常固定。如果只能使用购买->积分->收据序列来完成交易，则可以使用更简单的名称，但更具描述性的名称也可以，并且流畅的界面可能是一个合理的选择。

如果客户没有奖励卡或不希望有收据怎么办？如果在一次交易中可能会购买多个商品，那么情况又如何呢？当然，假设 buy 方法可能代表一个购买商品，而不仅仅是在其他地方计算出的总数？一旦你开始在序列中引入问题/选择，设计就会变得不太明显，命名也会变得更加困难。您当然不想使用疯狂的长名称，例如：

BuyAndAddPointsIfTheCustomerHasACardAndReturnAReceiptIfTheCustomerAsksForIt(...)

当然，它确切地告诉您它的作用，但它也突出了一个潜在的问题，即该方法可能负责太多的事情，或者它可能隐藏了一个它调用的方法之一背后有更复杂的代码味道。同样，像“Transaction”这样的简单方法名称可能会过度简化需要更好理解的复杂问题。

流畅的界面在这里可以带来很大的好处，只要它能够指导开发人员就如何应用所调用的流畅方法做出明智的决定。如果调用序列很重要，则需要将返回类型限制为序列中的下一个选择。如果调用顺序不太重要，那么您可以使用具有更通用接口的返回类型，该接口允许选择以任何顺序调用的方法。

至于是否使用流畅的接口，我认为它不应该仅仅作为分解难以命名的方法的一种手段来决定。您正在做出一个设计选择，您需要在产品的整个生命周期中接受它，并且从维护的角度来看，我发现流畅的界面会使设计更难以在您的应用程序中可视化、组织和维护。代码。最终，您需要决定这是否是您可以忍受的东西，以权衡它给您带来的好处。对我来说，我通常首先询问用例组合是否固定且简单，或者它们是否相对无穷无尽。如果是后者，流畅的界面可能有助于保持代码更简洁，并且更易于在多种场景中使用。我还会考虑代码是否属于更通用的层（例如 API），或者更专业的层（例如，流畅的界面可能会很好地工作）。