Phương pháp tiêm phụ thuộc so với phương pháp tĩnh

Hôm nay tôi đã có một cuộc thảo luận thú vị với một nhà phát triển khác về cách tiếp cận một lớp với phương thức chấp nhận chuỗi và xuất chuỗi.

Hãy tưởng tượng một cái gì đó giống như sau đây hoàn toàn được tạo ra cho mục đích ví dụ

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

Một hàm có một số logic dựa trên đầu vào chuỗi của nó được thêm vào dự án bằng DI và có DI Container. Bạn sẽ thêm lớp mới này với một giao diện và đưa nó vào nơi cần thiết, hoặc bạn sẽ biến nó thành một lớp tĩnh? Những ưu và nhược điểm của mỗi là gì? Tại sao bạn (hoặc không) muốn tạo ra thứ gì đó được sử dụng với hàm xây dựng thay vì chỉ truy cập khi được yêu cầu ở bất cứ đâu.

Không có lý do tại sao điều này cần phải được tiêm. Đây chỉ là một chức năng, nó không có phụ thuộc, vì vậy chỉ cần gọi nó. Nó thậm chí có thể tĩnh nếu bạn muốn nó trông thuần khiết. Người ta có thể viết bài kiểm tra đơn vị chống lại điều này mà không gặp khó khăn. Nếu nó được sử dụng trong các lớp khác, bài kiểm tra đơn vị vẫn có thể được viết.

Không cần phải trừu tượng hóa các chức năng mà không phụ thuộc, đó là quá mức cần thiết.

Nếu điều này trở nên phức tạp hơn thì có thể chuyển giao diện vào hàm tạo hoặc phương thức được bảo hành. Nhưng, tôi sẽ không đi vào con đường đó trừ khi tôi có GetStringPartlogic phức tạp dựa trên vị trí, v.v.

Đây là lý do tại sao

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

Nếu bạn đã sử dụng một phương thức tĩnh, sẽ không có cách nào thay đổi hành vi GetStringPartmà không phá hủy hành vi cũ hoặc làm ô nhiễm nó bằng logic có điều kiện. Đúng là thống kê là những quả cầu xấu xa được ngụy trang nhưng thực tế là chúng vô hiệu hóa đa hình là lời phàn nàn chính của tôi về chúng. Các phương thức tĩnh không phải là lớp đầu tiên trong các ngôn ngữ OOP. Bằng cách cung cấp cho phương thức một đối tượng để sống, ngay cả một đối tượng không có trạng thái, chúng ta tạo ra phương thức di động. Hành vi của nó có thể được truyền xung quanh giống như giá trị của một biến.

Ở đây tôi đã tưởng tượng một hệ thống cần hành xử hơi khác khi được triển khai ở châu Âu sau đó khi được triển khai ở Mỹ. Thay vào đó, buộc một trong hai hệ thống chỉ chứa mã mà chúng ta cần, chúng ta có thể thay đổi hành vi bằng cách kiểm soát đối tượng phân tích cú pháp thứ tự nào được đưa vào máy khách. Điều này cho phép chúng tôi chứa sự lây lan của chi tiết khu vực. Nó cũng giúp bạn dễ dàng thêm OrderParserCanada mà không cần phải chạm vào các trình phân tích cú pháp hiện có.

Nếu điều đó không có nghĩa gì với bạn thì thực sự không có lý lẽ nào cho việc này.

BTW, GetStringPartlà một cái tên khủng khiếp.