确定不要在构造函数中使用所有参数吗? - 重新审视

发布于 2024-12-01 08:05:11 字数 1314 浏览 5 评论 0原文

该类在构造函数中注入所有依赖项,但一次仅使用其中一个依赖项。这被认为是糟糕的设计吗?

public class OrderPayment
{
    ICreditCardPayment _ccPayment;
    ICashPayment _cashPayment;

    public OrderPayment(ICreditCardPayment ccPayment, ICashPayment cashPayment)
    {
        _ccPayment = ccPayment;
        _cashPayment = cashPayment;
    }

    private void PrepareOrder(Order order)
    {
        // Do stuff with the order
    }

    public PaymentResult PayByCreditCard(Order order)
    {
        PrepareOrder(order);
        return _ccPayment.Pay(order);
    }

    public PaymentResult PayByCreditCard(Order order)
    {
        PrepareOrder(order);
        return _cashPayment.Pay(order);
    }   
}

另一种方法是:

public class OrderPayment
{
    private void PrepareOrder(Order order)
    {
        // Do stuff with the order
    }

    public PaymentResult PayByCreditCard(Order order, ICreditCardPayment ccPayment)
    {
        PrepareOrder(order);
        return ccPayment.Pay(order);
    }

    public PaymentResult PayByCreditCard(Order order, ICashPayment cashPayment)
    {
        PrepareOrder(order);
        return cashPayment.Pay(order);
    }   
}

这会使函数调用稍微复杂化。即使不是每个构造函数参数都被使用,您会使用第一个看起来更干净的吗?考虑到 DI 框架必须实例化潜在的重类,即使它们可能不会全部被使用,我不确定这有多好。

那么您会使用哪一个呢?或者也许有不同的实现?

This class injects all dependencies in the constructor, but only one of the dependencies are used at a time. Is this considered bad design?

public class OrderPayment
{
    ICreditCardPayment _ccPayment;
    ICashPayment _cashPayment;

    public OrderPayment(ICreditCardPayment ccPayment, ICashPayment cashPayment)
    {
        _ccPayment = ccPayment;
        _cashPayment = cashPayment;
    }

    private void PrepareOrder(Order order)
    {
        // Do stuff with the order
    }

    public PaymentResult PayByCreditCard(Order order)
    {
        PrepareOrder(order);
        return _ccPayment.Pay(order);
    }

    public PaymentResult PayByCreditCard(Order order)
    {
        PrepareOrder(order);
        return _cashPayment.Pay(order);
    }   
}

An alternative is this:

public class OrderPayment
{
    private void PrepareOrder(Order order)
    {
        // Do stuff with the order
    }

    public PaymentResult PayByCreditCard(Order order, ICreditCardPayment ccPayment)
    {
        PrepareOrder(order);
        return ccPayment.Pay(order);
    }

    public PaymentResult PayByCreditCard(Order order, ICashPayment cashPayment)
    {
        PrepareOrder(order);
        return cashPayment.Pay(order);
    }   
}

This one complicates the function call somewhat. Would you use the first, cleaner looking one, even though not every constructor parameter is used? Considering a DI framework has to instantiate potentially heavy classes even though they may not all be used, I'm not sure how good this is.

So which one would you use? Or maybe a different implementation?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

黑凤梨 2024-12-08 08:05:11

我会从 ICashPaymentICreditCardPayment 重构或提取通用接口。您的代码示例表明您的方法都在调用 xPayment.Pay,这看起来是您的通用接口方法的良好候选者。

public interface IPayment 
{
    PaymentResult Pay(Order order);
}

您的更专业的接口可以继承并构建在它的基础上。

一般来说,我会避免让构造函数(或任何方法)接受未使用的参数,或者如果使用一个参数,则不使用另一个参数。这通常表明您没有在适当的抽象级别上操作,或者您的类/方法有太多职责。

I would refactor or extract a common interface from ICashPayment and ICreditCardPayment. Your code sample indicates your methods are both invoking xPayment.Pay, which looks like a good candidate for your common interface method.

public interface IPayment 
{
    PaymentResult Pay(Order order);
}

Your more specialized interfaces can inherit from and build upon it.

In general, I would avoid having constructors (or any method) accept arguments that go unused, or if one argument is used, the other is not. That's normally an indication that you are either not operating at the proper level of abstraction, or that your class/method has too many responsibilities.

眼眸里的那抹悲凉 2024-12-08 08:05:11

您需要一个需要满足以下所有条件的操作:

  • 付款方式
  • 支付的金额
  • 正在支付的订单
  • 付款前需要根据订单和支付的金额进行哪些处理

您正在尝试定义一些操作顺序与操作中正在执行的内容无关。依赖注入也可以在方法级别使用。

你需要一个像这样的方法:

public PaymentResult Pay(Amount amount, Order order, IOrderService orderService,
    IPaymentService paymentService) {
  var updatedOrder = orderService.Process(order); // don't alter the original in
                                                  // case you need to roll back
  var result = paymentService.Pay(amount, updatedOrder);
  return result; // this result should include the updated order, so that the system
                 // can determine what to do upon successful payment
}

You need an operation that requires all of the following:

  • the payment method
  • the amount being paid
  • the order that is being paid for
  • What processing needs to be done prior to payment, based on the order, and amount being paid

You are trying to define some order of operation independent of what is being performed in the operation. Dependency injection can be used at the method level too.

you need a method like this one:

public PaymentResult Pay(Amount amount, Order order, IOrderService orderService,
    IPaymentService paymentService) {
  var updatedOrder = orderService.Process(order); // don't alter the original in
                                                  // case you need to roll back
  var result = paymentService.Pay(amount, updatedOrder);
  return result; // this result should include the updated order, so that the system
                 // can determine what to do upon successful payment
}
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文