Bağımlılık Ters Çevirme İlkesi vs “Bir uygulama değil, bir arayüze program”

Bağımlılık Ters Çevirme İlkesi'nin "programdan uygulamaya değil, uygulamadan" ilkesinden nasıl farklı olduğunu anlamaya çalışıyorum.

"Bir uygulamaya değil, bir arabirime programla" nın ne anlama geldiğini anlıyorum. Daha esnek ve bakımı kolay tasarımlara nasıl izin verdiğini de anlıyorum.

Fakat Bağımlılık Tersine Çevirme İlkesinin "Program değil, bir arabirime program" ilkesinden ne kadar farklı olduğunu anlamıyorum.

İnternette çeşitli yerlerde DIP hakkında bir şeyler okudum ve karışıklığımı gidermedi. Hala iki ilkenin birbirinden nasıl farklı olduğunu göremiyorum. Yardımın için teşekkürler.

"Bir arayüze program" , işinizi yapmak için somut bir türe bağlı olmadığı anlamına gelir , ancak bağımlılığınızı nasıl elde etmeniz gerektiğini belirtmez .

"Bağımlılık Ters Çevirme İlkesi", bir nesnenin bağımlılıklarının yaratılmasını kontrol etmemesi gerektiğini, sadece ihtiyaç duyduğu bağımlılığın reklamını yapması ve arayanın bunu sağlamasına izin vermesi gerektiğini söyler . Ancak, bağımlılığın somut bir tip mi yoksa bir arayüz mi olacağını belirtmez.

Bazı C # kodlarıyla farklılıkları göstereceğim.

Aşağıdaki örnek somut bir türe bağlıdır ve kendi bağımlılığının yaratılmasını kontrol eder. Ne "bir arabirime program" ne de "bağımlılık tersini" izler :

public class ThingProcessor
{
    MyThing _myThing;

    public ThingProcessor()
    {
        _myThing = new MyThing();
    }

    public void DoSomething()
    {
        _myThing.DoIt();
    }
}

Aşağıdaki örnek bir arabirime bağlıdır, ancak kendi bağımlılığının oluşturulmasını kontrol eder. "Bir arabirime program" ı izler, ancak "bağımlılık tersini" izlemez:

public class ThingProcessor
{
    IMyThing _myThing;

    public ThingProcessor()
    {
        _myThing = ThingFactory.GiveMeANewMyThing();
    }

    public void DoSomething()
    {
        _myThing.DoIt();
    }
}

Aşağıdaki örnek somut bir türe bağlıdır, ancak bağımlılığının yaratılmasını ve kendisine aktarılmasını ister. "Bağımlılığı tersine çevirme" izler, ancak "arabirime program" izlemez:

public class ThingProcessor
{
    MyThing _myThing;

    public ThingProcessor(MyThing myThing)
    {
        _myThing = myThing;
    }

    public void DoSomething()
    {
        _myThing.DoIt();
    }
}

Aşağıdaki örnek bir arabirime bağlıdır ve bağımlılığının oluşturulmasını ve ona aktarılmasını ister. Hem "bağımlılık inversiyon" izler ve "bir arayüz programı":

public class ThingProcessor
{
    IMyThing _myThing;

    public ThingProcessor(IMyThing myThing) // using an interface
    {
        _myThing = myThing;
    }

    public void DoSomething()
    {
        _myThing.DoIt();
    }
}

Genellikle aynı şeydir. Eğer okursanız Bağımlılık Inversion İlke nedir ve neden önemlidir? ve Bağımlılık Tersine Çevirme İlkesi , temelde aynı şey hakkında konuşan iki "ilke" nin farkına varacaksınız .

• Yüksek seviyeli modüller, düşük seviyeli modüllere bağlı olmamalıdır. Her ikisi de soyutlamalara bağlı olmalıdır.
• Soyutlamalar asla detaylara bağlı olmamalıdır. Ayrıntılar soyutlamalara bağlı olmalıdır.

Arayüz bir soyutlamadır ve uygulama bir detaydır. Bunları önceki iki ifadede değiştirirseniz, temel olarak "kod, uygulamalara değil, arabirimlere bağlı olmalıdır" elde edersiniz. Ve bu bana aynı şey gibi geliyor.

Arabirimler DI'yi uygulamanın bir yoludur. Bir sınıfın yapıcı yönteminde bir parametre olarak bir arabirim belirtirseniz, bu nesne yapıcı parametresinin arabirimini uyguladığı sürece, istediğiniz yapıcı yöntemine o yapıcı yöntemine verebilirsiniz.

Başka bir deyişle, bir arabirimi programlamak , o arabirimin uygulamasını değiştirmenize olanak tanır . Birim testi sırasında sahte nesneleri gerçek nesnelerle nasıl değiştirebiliriz, farklı veri sağlayıcıları belirleyebiliriz.