依赖注入与静态方法

今天，我与另一位开发人员进行了有趣的讨论，内容涉及如何使用接受字符串并输出字符串的方法处理类。

想象一下以下内容，它完全是出于示例目的而组成的

public string GetStringPart(string input)
{ 
   //Some input validation which is removed for clarity

   if(input.Length > 5)
        return input.Substring(0,1);

   if(input.Substring(0,1) == "B")
        return input.Substring(0,3);

   return string.empty;
}

一个基于字符串输入而具有某种逻辑的函数将使用DI添加到项目中，并且具有一个DI容器。您是否会使用接口添加此新类并在需要时将其注入，还是将其设为静态类？各自的优缺点是什么？您为什么要（或不希望）使它与构造函数注入一起使用，而不是在需要时随处访问。

没有理由为什么需要注入。这只是一个函数，没有依赖性，因此只需调用它即可。如果您愿意，它甚至可以是静态的，因为它看起来是纯净的。可以毫不费力地针对此编写单元测试。如果在其他类中使用它，则仍可以编写单元测试。

不需要抽象出没有依赖关系的函数，这太过分了。

如果这变得更加复杂，则可能需要将接口传递给构造函数或方法。但是，除非有GetStringPart基于位置等的复杂逻辑，否则我不会走这条路。

这就是为什么

class DOSClient {
    OrderParser orderParser;
    string orderCode;

    DOSClient(OrderParser orderParser, string ordercode) { 
        this.orderParser = orderParser; 
        this.ordercode = ordercode;
    }
    void DisplayOrderCode() {
        Console.Write( "Prefix: " + orderParser.GetStringPart(ordercode) ); 
        ...
    }
}

class GUIClient {
    OrderParser orderParser;
    string orderCode;
    GUI gui;

    GUIClient(OrderParser orderParser, string ordercode, GUI gui) { 
        this.orderParser = orderParser; 
        this.ordercode = ordercode;
        this.gui = gui;
    }

    void DisplayOrderCode() {
        gui.Prefix( orderParser.GetStringPart(ordercode) ); 
        ...
    }
}

class OrderParserUS : IOrderParser {

    public string GetStringPart(string input)
    { 
        //Some input validation which is removed for clarity

        if(input.Length > 5)
            return input.Substring(0,1);

        if(input.Substring(0,1) == "B")
            return input.Substring(0,3);

        return string.empty;
    }
}

class OrderParserEU : IOrderParser {

    public string GetStringPart(string input)
    { 
        //Some input validation which is removed for clarity

        if(input.Length > 6)
            return input.Substring(0,1);

        if(input.Substring(0,1) == "#")
            return input.Substring(0,3);

        return string.empty;
    }
}

如果您使用静态方法，则无法在不GetStringPart破坏旧行为或不使用条件逻辑对其进行污染的情况下更改的行为。确实，静电是变相的邪恶全局变量，但是它们使多态性失效的事实是我对它们的主要抱怨。静态方法不是OOP语言中的一流。通过为该方法提供一个对象，甚至没有状态的对象，我们可以使该方法可移植。它的行为可以像变量的值一样传递。

在这里，我已经想象过一个系统，在欧洲部署时与在美国部署时，其性能需要略有不同。而是强迫一个系统只包含另一个系统所需的代码，我们可以通过控制将顺序解析对象注入客户端的方式来更改行为。这使我们能够包含区域细节的分布。这也使添加OrderParserCanada变得容易，而无需接触现有的解析器。

如果那对您没有任何意义，那么这确实没有一个很好的论据。

顺便说一句，这GetStringPart是一个可怕的名字。