Ін'єкція залежності від статичних методів

Я провів сьогодні цікаву дискусію з іншим розробником про те, як наблизитись до класу методом, який приймає рядок та виводить рядок.

Уявіть щось на зразок наступного, яке повністю складено з метою прикладу

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жахлива назва.