Yeni Kayıt
Konudaki Resimler
< Bu mesaj bu kişi tarafından değiştirildi StGuard -- 8 Aralık 2017; 20:16:48 > |
Hızlı 
Bildirim
Dependency Injection Üzerine Tartışma
Sıcak Fırsatlarda Tıklananlar
Editörün Seçtiği Fırsatlar
Daha Fazla 
Bu Konudaki Kullanıcılar:
Daha Az 
2 Misafir - 2 Masaüstü
Giriş
Mesaj
-
-
Konu kilit. Cevap alamayacağıma kanaat getirdim. 
-
Bana kalırsa bahsedilen avantaj, dependency injection ile alakalı değil de Dependency Inversion Principle ile alakalı.
Dependency Injection, aslında tam olarak dependency inversion'ı da satisfy eden bir yöntem değil başlı başına, örneğin bir concrete class'ı dependency olarak listeyen bir sistem, DIP'ını takip etmiş olmaz:
class Logger
{
void Log(/*log params*/);
}
class System
{
System(Logger logger)
}
Dependency Injection, dependency'lerin instance'larına ulaşmak için bir yol sadece benim gözümde. Çoğunlukla bahsettiğiniz gibi, Dependency Inversion Principle'ı ile birlikte anılıyor, bazen karıştırılıyor. Quora'da bir cevabımda bahsetmiştim, tekrarlamak isterim; Dependency Injection'ı kullanmak için iki tane net motivasyon var (en azından benim için).
Birincisi, özellikle constructor injection, çok daha anlaşılır bir "anlaşma" sağlıyor sistemin kullanıcıları için. Eğer parametresiz constructor kullanmıyorsanız, sisteminiz instante etmek isteyen herkes, anlaşmanızı takip etmek zorun kalıyor (Reflection hariç diyelim), diğer yandan örneğin metodlar ile veya "property"ler ile enjekt edilen dependency'ler için ortada bir anlaşma yok ve compile time'da hiçbirşeyden haberiniz olmuyor.
İkincisi ise, dependency injection; dependency inversion prensibi ile birlikte kullanıldığında unit testing'i çok kolay hale getiriyor.
Dependency Injection'ın abartıldığında ağır bir yüke dönüştüğüne katılıyorum. Bunun için ilginç çözümler üretilebiliyor, örneği Uncle Bob'ın tavsiyesi, 2-3'ten fazla dependency'ye sahip olmamak ve, gerekli yerlerde Factory patternlarını işin içine katarak yükü hafifletmek. Kaynak bulabilirsem bunu söylediği konuşmaya yönelik eklemeye çalışacağım.
Dezavantaj'lar noktasında, stack trace'i takip ederekten bir interface'e varmak bence en doğal şey zaten; DIP bundan bahsediyor zaten. Implementation'lara değil, interface'lere depend olmak. Behaviour'ı varsaymadan programlamak, en sağlıklısı diye düşünmekteyim. Güzel tasarlanmış bir sistem, behaviour'ı dışarıdan kullanan kullanıcılara açık yapmak ister ise, bunu Strategy pattern'ları veya farklı parametrik yapılarla yapabilir, yalnızca Concrete bir nesne vermek değil bence bunun doğru yolu.
Yanlış anlaşılmasın, DI ile benim de mutlaka sorunlarım var, burada sadece tartışma devam etsin diye anti-tezler sunmaya çalışıyorum :)
-
DI kullanılırken UML diagramlarını da oluşturmak gerekir. Aksi takdir de kodları incelerken işin içinden çıkılmaz hal alıyor. Hele Visual Studio da Goto defination olayı da olmuyor. Bizi Interface götürüyor.Çözmek anlamak güç oluyor.
DI kullanmanın avantajı bana göre;
Kodların daha sade olması,
Hızlı düzenleme yapılabilmesi,
Test işlemlerini kolayca gerçekleştirilebilir olması.
Ben .Net tarafında IOC framework olarak Autofac tercih ediyorum.
Sizlerin tercihi nedir ? -
Ben Java dili (JavaEE) ve IOC Framework olarak Spring kullanıyorum. 
-
Aslında DI edilecek o kadar da çok kod yok ki. Benim hatırladığım 3 tane kod var projede heryerde kullanılan ve dolayısı ile injecte edilmesi gereken
1- Db Bağlanan generic kodumuz, IReposity<T> miz.
2- Log Manager
3- User/Login Manager
henüz daha fazla enjekte etmemi gerektiren birşey hatırlamıyorum. Projesine bağlı bazen dış servisleri de soyutlamak ve DI gerektiriyor elbette ama henüz abartıldığı proje görmedim. Bu günlerde ben type safety gereksizmiş gibi hissediyorum. artık bi proje yazalım 20 yıl çalışssın olmuyor ki. 2-3 yıla yeniden yazılıyor sanki.
Ruby on rails ile takılınca harbiden sanki boşa kasıyoruz gibi. duck type candır gibi.
ki bu soyutlamayı ben sadece test yazma kolaylığı sebebi ile seviyorum. Yoksa sanmıyorum ki bu gün hadi orm i değiştiyoruz artık X yerine Y kullancağız diyelim.
< Bu mesaj bu kişi tarafından değiştirildi mahoni_38 -- 17 Aralık 2017; 23:37:50 >
Sayfa:
1
Ip işlemleri
Bu mesaj IP'si ile atılan mesajları ara Bu kullanıcının son IP'si ile atılan mesajları ara Bu mesaj IP'si ile kullanıcı ara Bu kullanıcının son IP'si ile kullanıcı ara
KAPAT X
Bu mesaj IP'si ile atılan mesajları ara Bu kullanıcının son IP'si ile atılan mesajları ara Bu mesaj IP'si ile kullanıcı ara Bu kullanıcının son IP'si ile kullanıcı ara
KAPAT X
