Question

在一个主要负责其依赖服务协调工作的类中，是否有减少依赖数量的策略？

例如，考虑捐款。我的协调课可能如下：

public class DonationService
{
    public DonationService(
            IDonationValidator validator,
            ICreditCardGateway creditCardGateway,
            IServiceBus serviceBus,
            IDatabaseSession dbSession,
            ILogger logger
            )
            { … }

    public DonationResult HandleDonation(DonationRequest request)
    {
        // 1. Validate
        // 2. Charge Credit Card
        // 3. Record in database
        // 4. Publish message to service bus
    }
}

如果在这个过程中还有一个步骤，我很容易看到出现了第六个依赖关系。也许伐木可能是一个跨领域的问题，但这是值得商榷的。

在承担捐赠的单一责任中，需要采取许多步骤。我没有包括“发送电子邮件”等步骤，因为我在通过服务总线接收捐赠消息时依靠单独的流程来做到这一点。

我不确定是否可以在该组中的任何依赖项子集上创建外观服务，并且不确定我还应该做什么。任何关于删除此代码气味的建议都将非常感激。

Answer 1

我遇到了与这个场景非常相似的场景，但事实证明（由于设计不佳）......实际上，一些高级建筑师过去曾向我指出这一点。通常，因为对单个对象赋予过多的责任。现在，众所周知，有时候全腿重新设计并不是解决这个问题的最明智或最经济的方式，但是当你遇到设计问题时，你应该首先考虑它。你能做些什么来避免臃肿的构造函数？以下是一些选项：

1-提供默认实现，添加一个默认构造函数，初始化这些依赖项的默认实现...也许使用工厂对象，这样您就不会最终初始化具体对象实现。通过让这些重载调用默认构造函数

来重载构造函数

2-将某些责任委托给某种“中间”对象，例如，您可能希望将servicebus和数据库职责移至单独的对象，然后将日志记录移至这些依赖项

Answer 2

尽管它的名字，代码气味并不一定是一件需要删除的坏事 - 它只是表明需要进行更深入的评估。

代码气味调查导致不采取任何行动是完全合法的，只要设计合理就可以。当然，代码气味通常表明存在问题（因此他们的耻辱）。

对于您提供的方案，我们可以将一些依赖项组合在一起;但我们能以一种有助于提高可读性/可维护性的方式这样做吗？

例如：它可能是＆＃34;验证＆＃34;和＃34;收取信用卡＆＃34;可以合并步骤，从而产生＆＃34;流程信用卡捐赠＆＃34;步。但它也可能是＆＃34;验证＆＃34;将苹果作为一个整体（如协作者的名字所暗示的那样）进行捐赠过程，而不仅仅是信用卡部分。在这种情况下，合并者只会导致混淆。

您可以考虑的一个选项是将单个协作者从课堂中拉出来，并使用它来创建decorator课程。例如，从IDonationValidator中移除DonationService，并使用它来创建类似DonationServiceThatValidatesBeforeProcessing的类（首选名称更简洁）。

您应该采用任何方法来评估使代码库更具可读性的思维方式。如果有很多构造函数参数会损害可读性，但是替代方案会损害可读性，然后坚持现状。

减少协调类中的依赖项数量

2 个答案: