Wstrzykiwanie zależności a metody statyczne

Przeprowadziłem dzisiaj interesującą dyskusję z innym programistą na temat tego, jak podejść do klasy za pomocą metody, która akceptuje ciąg i ciąg wyjściowy.

Wyobraź sobie coś takiego, co zostało w całości wykonane na potrzeby przykładu

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

Funkcja, która ma pewną logikę na podstawie danych wejściowych ciągu, jest dodawana do projektu za pomocą DI i ma kontener DI na swoim miejscu. Czy dodasz tę nową klasę z interfejsem i wstrzykniesz ją tam, gdzie to konieczne, czy uczynisz ją klasą statyczną? Jakie są zalety i wady każdego z nich? Dlaczego miałbyś (lub nie) chcieć zrobić to z zastrzykiem konstruktora, a nie tylko uzyskiwać do niego dostęp w razie potrzeby w dowolnym miejscu.

Nie ma powodu, aby to robić. To tylko funkcja, nie ma zależności, więc po prostu ją wywołaj. Może być nawet statyczny, jeśli chcesz, ponieważ wygląda na czysty. Bez trudu można napisać testy jednostkowe. Jeśli jest używany w innych klasach, testy jednostkowe mogą być nadal pisane.

Nie ma potrzeby abstrakcji funkcji bez zależności, to przesada.

Jeśli stanie się to bardziej złożone, być może uzasadnione jest przekazanie interfejsu do konstruktora lub metody. Ale nie poszedłbym tą drogą, chyba że miałbym złożoną GetStringPartlogikę opartą na lokalizacji itp.

Dlatego

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

Jeśli wybrałeś metodę statyczną, nie byłoby sposobu, aby zmienić zachowanie GetStringPartbez zniszczenia starego zachowania lub zanieczyszczenia go logiką warunkową. To prawda, że ​​statyka to złe globale w przebraniu, ale fakt, że wyłączają polimorfizm, jest moim głównym zarzutem. Metody statyczne nie są pierwszą klasą w językach OOP. Dając metodzie obiekt do życia, nawet taki bez stanu, sprawiamy, że metoda jest przenośna. Jego zachowanie można przekazywać jak wartość zmiennej.

Wyobraziłem sobie system, który musi zachowywać się nieco inaczej po wdrożeniu w Europie niż po wdrożeniu w USA. Zamiast tego wymuszaj, aby jeden system zawierał kod potrzebny tylko drugiemu, możemy zmienić zachowanie, kontrolując, jaki obiekt analizujący kolejność jest wprowadzany do klientów. To pozwala nam ograniczyć rozprzestrzenianie się szczegółów regionu. Ułatwia także dodawanie OrderParserCanada bez konieczności dotykania istniejących parserów.

Jeśli to nic dla ciebie nie znaczy, to naprawdę nie ma na to dobrego argumentu.

BTW, GetStringPartto okropne imię.