Bağımlılık Enjeksiyonu ve Statik Yöntemler

Bugün bir dize ve çıkış dizesi kabul bir yöntemle bir sınıfa yaklaşmak hakkında başka bir geliştirici ile ilginç bir tartışma vardı.

Tamamen örnek amaçlı yapılmış aşağıdaki gibi bir şey düşünün

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

Dize girişine dayalı bir mantığı olan bir işlev, DI kullanılarak bir projeye eklenir ve bir DI Kabı vardır. Bu yeni sınıfı bir arabirim ile ekler ve gerektiğinde enjekte eder misiniz, yoksa statik bir sınıf yapar mısınız? Her birinin artıları ve eksileri nelerdir? Neden herhangi bir yere ihtiyaç duyulduğunda erişmektense bunu yapıcı enjeksiyonuyla kullanılan bir şey yapmak istersiniz (ya da istemezsiniz).

Bunun enjekte edilmesi için bir neden yoktur. Bu sadece bir işlevdir, bağımlılıkları yoktur, bu yüzden sadece çağırın. Saf gibi görünmesini istiyorsanız statik bile olabilir. Buna karşı birim testler zorlanmadan yazılabilir. Diğer sınıflarda kullanılırsa, birim testleri yine de yazılabilir.

Bağımlılık olmadan işlevleri soyutlamaya gerek yoktur, aşırıya kaçar.

Bu daha karmaşık hale gelirse bir arayüzün bir kurucuya veya yönteme geçirilmesi gerekebilir. Ancak, GetStringPartkonuma dayalı karmaşık bir mantığa sahip olmadıkça, o yoldan aşağıya gitmezdim.

İşte nedeni

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

Statik bir yöntemle gitmiş olsaydınız GetStringPart, eski davranışı yok etmeden veya koşullu mantıkla kirletmeden davranışını değiştirmenin bir yolu olmazdı . Statiklerin kılık değiştirmiş kötü küreseller olduğu doğrudur, ancak polimorfizmi devre dışı bıraktıkları gerçeği, bunlar hakkında benim ana şikayetim. Statik yöntemler OOP dillerinde birinci sınıf değildir. Yönteme yaşamak için bir nesne, hatta durumu olmayan bir nesne vererek, yöntemi taşınabilir hale getiririz. Davranışı bir değişkenin değeri gibi geçirilebilir.

Burada Avrupa'da konuşlandırıldıktan sonra ABD'de konuşlandırıldığında biraz farklı davranması gereken bir sistem hayal ettim. Daha sonra her iki sistemi de sadece diğerinin ihtiyaç duyduğu kodu içermeye zorlamak istemcilere hangi sıra ayrıştırma nesnesinin enjekte edildiğini kontrol ederek davranışı değiştirebiliriz. Bu, bölge detaylarının yayılmasını kontrol etmemizi sağlar. Ayrıca, mevcut ayrıştırıcılara dokunmadan OrderParserCanada eklemeyi de kolaylaştırır.

Bu sizin için bir şey ifade etmiyorsa, bunun için gerçekten iyi bir argüman yoktur.

BTW, GetStringPartkorkunç bir isim.