Bağımlılık Enjeksiyonu (DI) ve Kontrolün Ters Çevirilmesi (IOC) Arasındaki Fark

Bağımlılık Enjeksiyonu (DI) ve Kontrolün Tersine Çevirilmesi (IOC) ile ilgili çok sayıda referans görüyorum, ancak aralarında bir fark olup olmadığını gerçekten bilmiyorum.

Bunlardan birini veya ikisini kullanmaya başlamak istiyorum, ancak nasıl farklı olduklarına dair biraz kafam karıştı.

Tanımlar

Kontrolün tersine çevrilmesi, somut uygulamaların uygulama çerçevesi kodundan farkındalığının azaltılması ve uygulamanızın alana özgü bileşenlerine daha fazla kontrol verilmesi amacıyla bir tasarım paradigmasıdır. Geleneksel yukarıdan aşağıya tasarlanmış bir sistemde, uygulamanın mantıksal akışı ve bağımlılık bilinci, ilk önce tasarlananlardan en son tasarlananlara akar. Bu nedenle, kontrolün tersine çevrilmesi, bir uygulamadaki kontrol ve bağımlılık bilincinin neredeyse tersine çevrilmesidir.

Bağımlılık enjeksiyonu, derleme zamanında, bu işlevselliği sağlamak için hangi uygulamanın kullanılacağını bilmeden, diğer sınıfların dayandığı sınıfların örneklerini oluşturmak için kullanılan bir kalıptır.

Birlikte çalışma

Kontrolün tersine çevrilmesi bağımlılık enjeksiyonunu kullanabilir, çünkü spesifik işlevselliği sağlayan bileşenleri oluşturmak için bir mekanizmaya ihtiyaç vardır. Diğer seçenekler mevcuttur ve bunlar, örneğin aktivatörler, fabrika yöntemleri vb. Kullanılır, ancak çerçeve sınıfları, ihtiyaç duydukları bağımlılığı (ları) kabul edebiliyorsa, çerçevelerin bu fayda sınıflarına başvurması gerekmez.

Örnekler

İşyerinde bu kavramların bir örneği Reflektör'deki eklenti çerçevesidir . Uygulama derleme zamanında eklentilerle ilgili bir şey bilmese de eklentiler sistemin kontrolünü büyük ölçüde kontrol eder. Bu eklentilerin her biri için tek bir yöntem çağrılır, Eklentiyi kontrol altına alan bellek işe yararsa başlat. Çerçeve ne yapacaklarını bilmiyor, sadece yapmalarına izin veriyor. Ana uygulamadan kontrol alınmış ve belirli işleri yapan bileşene verilmiştir; kontrolün ters çevrilmesi.

Uygulama çerçevesi, çeşitli servis sağlayıcılar aracılığıyla işlevselliğine erişim sağlar. Bir eklenti oluşturulduğunda servis sağlayıcılara referanslar verilir. Bu bağımlılıklar eklentinin kendi menü öğelerini eklemesini, dosyaların görüntülenme şeklini değiştirmesini, kendi panellerini uygun panellerde görüntülemesini vb. Sağlar. Bağımlılıklar arayüzden geçtiğinden, uygulamalar değişebilir ve değişiklikler bozulmaz sözleşme bozulmadan kaldığı müddetçe

O zaman, yapılandırma bilgilerini, yansımayı ve Activator nesnesini (en azından .NET'te) kullanarak eklentileri oluşturmak için bir fabrika yöntemi kullanıldı. Günümüzde araçlar vardır MEF bir bağımlılık olarak eklentilerin listesini kabul etmek bir uygulama çerçevesi yapabilme gibi bağımlılıklar enjekte ederken daha geniş bir seçenek yelpazesi için izin biri için.

özet

Bu kavramlar bağımsız olarak kullanılabilir ve yarar sağlarken, birlikte çok daha esnek, yeniden kullanılabilir ve test edilebilir bir kodun yazılmasına izin verir. Bu nedenle, nesneye yönelik çözümler tasarlamada önemli kavramlardır.

IOC ve DI'yi anlamak için iyi bir yazı http://martinfowler.com/articles/injection.html

IOC (Kontrolün Ters Çevirilmesi)

IOC anlamına gelir

1. arabirime kodlama (bir bileşen, diğer bileşenin arabirimine bağlı olmalı ve impl'ye bağlı olmamalıdır) ve örneğin

   interface iComp_2 {...}
   
   class Comp_1 {
       iComp_2 c2 = ….;
   }
   

2. bileşen uygulamasına özel kodun kaldırılması, örneğin

   Comp_1 {
       iComp_2 c2 = getComp_2_Impl(); // not new Comp_2_Impl();
   }
   

IOC, aşağıdakilerden herhangi biri ile elde edilebilir:

1. DI (Bağımlılık Enjeksiyonu)

3 types of DI

1.1 Constructor Injection

1.2 Setter Injection

1.3 Interface Injection

2. Servis Bulucu

DI (Bağımlılık Enjeksiyonu) konteyneri

Çalışma zamanı uygulama belirleme ve derleme zamanı belirleme: çalışma zamanında, bazı yapılandırma dosyalarına dayanarak kullanılacak bir arabirimin hangi somut uygulamasının belirlendiğini belirler (derleme zamanında, hangi uygulamanın kullanılacağını bilmiyoruz ve böylece uygulamanın yapılandırılabilirliğini artırırız) . Farklı modüller arasındaki somut ilişkinin "çalışma zamanında" belirlendiği bir uygulamadır.

Bağımlılık enjeksiyonundan sonra impl'nin başlatılması: impl'yi belirledikten sonra, ilk önce tüm bağımlılıklarını yaratarak (config dosyasında belirtilen) ve sonra bu bağımlılıkları bu impl 'e enjekte ederek bunu başlatır.

Örnek Yaşam döngüsü yönetimi: DI kapları genellikle, yalnızca yaşam döngülerini yönetmek için ihtiyaç duydukları veya gelecek tekil enjeksiyonlar için (örneğin singleton veya flyweights) yeniden kullanılan nesnelere atıfta bulunur. Kapsayıcıya yapılan her çağrı için bazı bileşenlerin yeni örneklerini oluşturmak üzere yapılandırıldığında kapsayıcı genellikle yalnızca oluşturulan nesneyi unutur. Aksi halde çöp toplayıcı, artık kullanılmadığında tüm bu nesneleri toplamakta zorlanacaktır.

"Kontrolün Tersine Çevirilmesi" nin, tüm modüllerin soyut varlıklar olduğu düşünülen bir sistem tasarlamanın bir yolu olduğunu söyleyebilirim.

Ve, "Bağımlılık Enjeksiyonu", farklı modüller arasındaki somut ilişkinin "çalışma zamanında" kararlaştırıldığı bir uygulamadır.

Kontrolün ters çevrilmesi genel bir kavramdır, işlevsel dillerde genellikle süreklilik kullanılarak yapılır. Bu, her iki tarafın da 'arayan' olduğu ve hiçbirinin 'callee' olmadığı bir API yazmanızı sağlar. Diğer, daha statik ortamlarda bu kolaylığa sahip değilsinizdir, bu nedenle kontrol akışına ipuçları eklemek için bu kesmeye ihtiyacınız var.