Bağımlılık Enjeksiyonu ve IoC Containers kullanmanın faydaları nelerdir?

62

Bağımlılık Enjeksiyonu ve IoC Containers hakkında bir konuşma yapmayı planlıyorum ve kullanımı için bazı iyi argümanlar arıyorum.

Bu tekniği ve bu araçları kullanmanın en önemli faydaları nelerdir?

design-patterns dependency-analysis

— Andy Lowry
kaynak

1

StackOverflow cevapları ve buradaki IoC ile ilgili tam bir makale için buraya ve buraya bakın . Karşılaştırma için ona karşı argümanlar istiyorsanız, buraya SO'ya gidin.

— Jesse C. Dilimleyici

14

popo olmamak ... ama neden DI / IOC'nin kullanılması gerektiğini bilmiyorsanız, neden bunun hakkında konuşuyorsunuz? bahis kaybetmek? ;-)

— Steven A. Lowe

2

@Steven, patronu ondan yapmasını istedi.

1

@Steven, zaten her zaman DI kullanıyorum (bazıları çok sık söylerdi :-D), sadece diğer insanların kullanmasını sağlamak için bazı iyi argümanlar arıyorum.

— Andy Lowry,

2

İnsanlar nadiren DI'nin aşırı kullanımı hakkında konuşurlar . Her bir kararı geciktirirseniz, spagetti kodunun OO eşdeğerini oluşturacaksınız. Tutarlı bir tasarıma sahip olmak, bir noktada, gerçek bir karar verilmesini gerektirir.

— Macneil

47

Benim için en önemlisi, Tek Sorumluluk İlkesini takip etmeyi kolaylaştırmak .

DI / IoC, nesneler arasındaki bağımlılıkları yönetmemi kolaylaştırıyor. Bu da, uyumlu işlevselliği kendi sözleşmemize (arayüzüne) bölmemi kolaylaştırıyor. Sonuç olarak, kodum DI / IoC'yi öğrendiğimden beri çok daha modüler hale getirildi.

Bunun bir başka sonucu da Açık-Kapalı Prensibi destekleyen bir tasarıma geçiş yolumu daha kolay görebilmemdir . Bu, en güvenilir ilham veren tekniklerden biridir (yalnızca otomatik testlerden ikincisidir). Açık-Kapalı İlkenin erdemlerini yeterince destekleyebileceğimden şüpheliyim.

DI / IoC, programlama kariyerimde "oyun değiştirici" olan birkaç şeyden biri. Bir yoktur kocaman Daha önce & DI / IoC öğrendikten sonra yazdığı kod arasındaki kalite farkı. Bunu biraz daha vurgulayayım. Kod kalitesinde BÜYÜK gelişme.

— Quentin-burkulma
kaynak

3

Açık-Kapalı İlke neden bu kadar önemli? Bir API / arayüzü değiştirmeniz gerektiğine inanıyorsanız neden olmasın?

— Arne Evertsson,

@ArneEvertsson Robert C. Martin'i Dinleyin Açık-Kapalı İlke hakkında konuşun. Aydınlanacaksın.

— Alternatex

Kodunuzu başkalarının kullanması için bir modül olarak (ticari ürün olarak örneğin) temin edildiğinde onları değiştirmek için size dönüştürme olmadan kullanımda kodunuzu daha kolay adapte yapar gibi @AmeEvertsson Açık-Kapalı, çok önemli

— James Ellis-Jones

2

DI, basitçe bir somut sınıfa bağımlılık yaratmaktan çok, bağımlılıkları yönetmeyi basitleştirmiyor. Bununla birlikte esneklik sağlar, ancak 'uygun' birim testi yapmazsanız, bu esnekliğe sıklıkla ihtiyaç duyulmaz. Açıklanan her iki temel avantaj, daha basit olan Servis Konumlandırıcı için de geçerlidir.

— James Ellis-Jones

1

Bu cevabı yıllar önce düşürdüm; İşte bazı açıklamalar: 1) Uygulamada, DI'nin yaygın kullanımı SRP'ye karşı çalışma eğilimindedir , çünkü programcılar, yeni sınıflar oluşturmak yerine, enjekte edilen "kontrolörlere", "hizmetlere", "DAO'lara" vb. yeni işlevsellik Normalde gördüğünüz Java ve C # .NET projelerinde DI çerçeve veya kapsayıcı kullanan şeylerdir. 2) Açık-kapalı ilke, sadece Bertrand Meyer'in sınıf (uygulama) mirasının yararına olan yanılgısı; 1400'den fazla sayfa kitabında arama yaparsanız ne demek istediğimi görürsünüz - gerçekten saçma.

— Rogério

9

Gerçekten gözlerimi açan örnekler, böylesi bir şekilde yaratılmış objeleri kolayca test etmenin nasıl mümkün olduğunu görüyordu. Ondan önce, bir ünite testi için nesneleri izole etmekte zorlandım. Genellikle daha büyük bir sistemle etkileşime geçmek için testler yazarım. Bu gerçekten zordu çünkü sistem bir bütün olarak daha az öngörülebilirdi ve tek tek bileşenlerden sonra değişime yatkındı.

— Winston Ewert
kaynak

3

Bağımlılık enjeksiyonlarının avantajları:

Kodunuz temiz ve daha okunur.
Kodlar gevşek bir şekilde birleştirilmiştir.
Uygulamalar XML dosyasında yapılandırıldıkça daha yeniden kullanılabilir, farklı bir bağlamda kullanılabilir.
Kod, farklı sahte uygulamalarla kolayca test edilebilir.

— Solaimani SA
kaynak

1

Bence asıl faydalar teknikten daha politik. DI sadece Servis Bulucu modeline bir alternatiftir , daha fazlası değil. Kendi başına, SRP veya OCP gibi ilkeleri takip etmeyi veya katmanları ayırmayı kolaylaştırmaz. Buradaki diğer katılımcılar farklı kavram ve teknikleri karıştırıyorlar, IMO.

Servis Belirleyicileri kullanarak veya uygun olduğunda doğrudan bağımlılıkları somutlaştırarak (çoğu zaman bu) doğrudan yüksek uyum ve düşük eşleşme ile ilgili aynı hedefleri gerçekleştirebilirsiniz.

Şimdi, çoğunun bu görüşe katılmayacağını biliyorum. Somut örnekleri tartışmaktan memnuniyet duyacağım.

— Rogério
kaynak

2

Ancak doğrudan bir hizmet bulucuyu çağırmak veya somut bir bağımlılığı başlatmak, genellikle bağımlılıklarınızı ya da en azından bağımlılıklarınızın nereden geldiğini gösterir. Bu DI amacını yenmek gibi görünüyor. Yine de servis bulucuyu enjekte etmeniz gerekiyor.

— Matt H

Bir Servis Bulucu kullanmak, normalde "enjekte edilmeyen" Servis Bulucu sınıfının kullanımı dışında hiçbir şeyi kablolamaz. Somut bir uygulama sınıfını başlatmak, dış yapılandırmaya ihtiyaç duymadığınız durumlarda mükemmeldir (örneğin, programcılar genellikle DI - kullanmak yerine DI kullanmak yerine doğrudan ArrayList sınıfını başlatırlar).

— Rogério

1

"Düşük kuplajdan" bahsediyorsunuz ve daha sonra bir servis bulucunun bir uygulamanın kuplaj seviyesi üzerinde bir etkisi olmadığını söylüyorsunuz. Aynı şekilde ortakları doğrudan kod üzerinde başlatmak için de, bir nesneyi bağımlılıklarıyla birleştirmenin daha mükemmel bir yolunu düşünemiyorum. Her iki senaryoyu da nasıl test edersiniz? Ben, saygılarımla, söylediğiniz her şeye tamamen katılmıyorum.

— Clint Eastwood

@Jonathan DI'yi tanıtan makaleyi okumalısınız ; Yazar, DI ve ServiceLocator’ın “kabaca eşdeğer” olduğunu söyler ve sonuncusu için “hafif bir kenarı” olur. Önemli olan bağlantı, bir bileşen ile birden fazla uygulamaya sahip olabilecek diğer bileşenler arasındadır; ServiceLocator, yalnızca bir uygulama ile bir altyapı hizmetidir, bu yüzden tamam. Not "Uygun olduğu zaman bağımlılık yaratma bağımlılıkları" yazdım ; Eğer varsa tabii ki, gerek kullanımından yapılandırmayı ayırmak için, bunu yapmaz.

— Rogério

1

@Jonathan Ünite testi ile ilgili olarak, ortak çalışanların bu tür testlerin oluşturulmasını önlediği bir efsanedir; enjekte edilip edilmese de bir sınıfı bağımlılık uygulamalarından izole etme işi yapan iyi bilinen alaycı araçlar vardır.

— Rogério

-1

DI, test amacıyla iç nesneleri ortaya çıkarmak için kullanıldığında, desen kötüye kullanılmıştır.

— Thomas-Peter
kaynak

1

"iç nesneler" ile neyi kastediyorsunuz? içinde gerçek (programcı muhtemelen sadece% 1 gerçekten ne anlama geldiğini biliyor nota) OOP, mesajları (yani yöntem invocations) göndererek vasıtasıyla birbirleriyle iletişim nesneler vardır. Bu anlamda, her nesnenin tek bir sorumluluğu olmalı, diğerlerinden daha "önemli" nesneler yoktur ... her birinin tek bir görevi vardır ve tüm sistemin sağladığı işlevselliği sağlamak için işbirliği yaparlar. Her nesneyi izole bir şekilde test etmek önemlidir, böylece hiçbir vakayı kaçırmadığımızı biliyoruz, DI'nin gerçekten iyi olduğu şey bu.

— Clint Eastwood

Unuttum.

— thomas-peter,