Внедрение зависимостей против статических методов

Сегодня у меня была интересная дискуссия с другим разработчиком о том, как подойти к классу с помощью метода, который принимает строку и выводит строку.

Представьте себе что-то вроде следующего, полностью составленное для примера.

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не разрушив старое поведение или не загрязнив его условной логикой. Это правда, что статики - это замаскированные злые глобалы, но тот факт, что они отключают полиморфизм, является моей главной жалобой на них. Статические методы не являются первоклассными в языках ООП. Предоставляя методу объект для жизни, даже если он не имеет состояния, мы делаем метод переносимым. Его поведение может передаваться как значение переменной.

Здесь я представил систему, которая должна вести себя немного иначе, когда она развернута в Европе, чем при развертывании в США. Вместо того, чтобы заставить любую систему содержать код, необходимый только другой, мы можем изменить поведение, контролируя, какой объект анализа заказов вводится в клиентах. Это позволяет нам сдерживать распространение деталей региона. Это также позволяет легко добавлять OrderParserCanada без необходимости трогать существующие парсеры.

Если это ничего не значит для вас, то для этого нет веских аргументов.

Кстати, GetStringPartэто ужасное имя.