Abhängigkeitsinjektion im Vergleich zu statischen Methoden

Ich hatte heute eine interessante Diskussion mit einem anderen Entwickler darüber, wie man sich einer Klasse mit einer Methode nähert, die einen String akzeptiert und einen String ausgibt.

Stellen Sie sich etwas wie das Folgende vor, das zum Zweck des Beispiels vollständig erfunden ist

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;
}

Eine Funktion, deren Logik auf der Eingabe eines Strings basiert, wird mit DI zu einem Projekt hinzugefügt und verfügt über einen DI-Container. Würden Sie diese neue Klasse mit einer Schnittstelle hinzufügen und bei Bedarf einfügen, oder würden Sie sie zu einer statischen Klasse machen? Was sind die Vor- und Nachteile von jedem? Warum sollten Sie (oder nicht) möchten, dass dieses Element mit der Konstruktorinjektion verwendet wird, anstatt nur bei Bedarf an einer beliebigen Stelle darauf zuzugreifen?

Es gibt keinen Grund, warum dies injiziert werden muss. Dies ist nur eine Funktion, sie hat keine Abhängigkeiten. Rufen Sie sie einfach auf. Es kann sogar statisch sein, wenn Sie möchten, da es rein aussieht. Dagegen kann man problemlos Unit-Tests schreiben. Wenn es in anderen Klassen verwendet wird, können noch Komponententests geschrieben werden.

Es ist nicht nötig, Funktionen ohne Abhängigkeiten zu abstrahieren, es ist übertrieben.

Wenn dies komplexer wird, ist möglicherweise die Übergabe einer Schnittstelle an einen Konstruktor oder eine Methode gerechtfertigt. Aber ich würde diesen Weg nicht gehen, wenn ich nicht eine komplexe GetStringPartLogik basierend auf dem Ort usw. hätte.

Hier ist der Grund

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;
    }
}

Wenn Sie sich für eine statische Methode entschieden hätten, gäbe es keine Möglichkeit, das Verhalten von zu ändern, GetStringPartohne entweder das alte Verhalten zu zerstören oder es mit bedingter Logik zu verschmutzen. Es ist wahr, dass Statik böse Globals in Verkleidung sind, aber die Tatsache, dass sie den Polymorphismus deaktivieren, ist meine Hauptbeschwerde über sie. Statische Methoden sind in OOP-Sprachen nicht erstklassig. Indem wir der Methode ein Objekt zum Leben geben, auch wenn es keinen Zustand gibt, machen wir die Methode portierbar. Sein Verhalten kann wie der Wert einer Variablen weitergegeben werden.

Hier habe ich mir ein System vorgestellt, das sich beim Einsatz in Europa etwas anders verhalten muss als beim Einsatz in den USA. Statt zu erzwingen, dass eines der beiden Systeme Code enthält, der nur von dem anderen benötigt wird, können wir das Verhalten ändern, indem wir steuern, welches Ordnungsanalyseobjekt in die Clients injiziert wird. Dies ermöglicht es uns, die Streuung der Regionsdetails einzudämmen. Es macht es auch einfach, OrderParserCanada hinzuzufügen, ohne vorhandene Parser anfassen zu müssen.

Wenn Ihnen das nichts bedeutet, gibt es dafür wirklich kein gutes Argument.

Übrigens GetStringPartist ein schrecklicher Name.