Iniezione di dipendenza vs metodi statici

Oggi ho avuto un'interessante discussione con un altro sviluppatore su come affrontare una classe con un metodo che accetta una stringa e genera una stringa.

Immagina qualcosa di simile al seguente, completamente inventato a scopo di esempio

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

Una funzione che ha una logica basata sul suo input di stringa viene aggiunta a un progetto usando DI e ha un contenitore DI in atto. Aggiungeresti questa nuova classe con un'interfaccia e la inietteresti dove necessario, o la trasformeresti in una classe statica? Quali sono i pro ed i contro di ognuno? Perché vorresti (o no) rendere questo qualcosa usato con l'iniezione del costruttore piuttosto che accedervi quando richiesto ovunque.

Non vi è alcun motivo per cui questo debba essere iniettato. Questa è solo una funzione, non ha dipendenze, quindi chiamala. Può anche essere statico se lo si desidera in quanto sembra essere puro. Si può scrivere test unitari contro questo senza difficoltà. Se viene utilizzato in altre classi, è ancora possibile scrivere unit test.

Non è necessario sottrarre funzioni senza dipendenze, è eccessivo.

Se questo diventa più complesso, allora è garantito il passaggio di un'interfaccia in un costruttore o in un metodo. Ma non seguirei quella strada se non avessi una GetStringPartlogica complessa basata sulla posizione, ecc.

Ecco perché

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

Se avessi adottato un metodo statico, non ci sarebbe modo di cambiare il comportamento GetStringPartsenza distruggere il vecchio comportamento o inquinarlo con la logica condizionale. È vero che la statica è una malvagità globale sotto mentite spoglie, ma il fatto che disabilitino il polimorfismo è la mia principale lamentela. I metodi statici non sono di prima classe nei linguaggi OOP. Dando al metodo un oggetto in cui vivere, anche uno senza stato, rendiamo il metodo portatile. Il suo comportamento può essere passato come il valore di una variabile.

Qui ho immaginato un sistema che deve comportarsi in modo leggermente diverso quando distribuito in Europa rispetto a quando implementato negli Stati Uniti. Invece di forzare un sistema a contenere codice necessario solo all'altro, possiamo modificare il comportamento controllando l'ordine di analisi dell'oggetto iniettato nei client. Questo ci consente di contenere la diffusione dei dettagli della regione. Inoltre, semplifica l'aggiunta di OrderParserCanada senza dover toccare i parser esistenti.

Se questo non significa nulla per te, allora non c'è davvero un buon argomento per questo.

A proposito, GetStringPartè un nome terribile.