Türkiye'nin en dandik Kargo şirketi hangisidir?
View Results
GoF’un Design Pattern kataloğundan sonra da bir sürü pattern adı ortaya atıldı ve atılmaya devam ediyor. Bu iş tam bir çılgınlığa döndü. Aynen Extreme Programming paradigmalarından sonra Agile Development, Alt.Net adıyla bir sürü türevinin ortaya çıkması gibi.
Efendim, nedir bu Dependency Injection?
Bir sınıfın ne olduğuna bakmaksızın ortak bir arayüz veya ortak bir sınıfı kullanması, yani o sınıfa ya da arayüze bağımlı hale getirilmesi. Örneğin bir veritabanı bağlantısı için IDbConnection diye bir arayüz tanımlanmış olsun. MSSQL, MySQL, vb veritabanlarına bağlanmak için bağlantı sınıfları oluştururken doğal olarak bu arayüzü kullanarak sınıflar tanımlarızki araya bir katman koyalım da veritabanı bağlantısıyla işi olan sınıflar veritabanının ne olduğuna bakmasızın işlerini yapabilsinler. Aşağıdaki kodda da dependency injection yapmış oluyoruz. Hatta bunların türleri var:
public class EmployeeLister { public EmployeeLister() {} public IList GetEmployees(IDbConnection connection) {} }
public class EmployeeLister { public EmployeeLister() {} public IList GetEmployees() {} public IDbConnection Connection {get;set;} }
public class EmployeeLister { public EmployeeLister(IDbConnection connection) {} public IList GetEmployees{} }
Dependency Injection kavramı ile interface kullanımı arasında bir fark var aslında. Konu hakkındaki yazılar ya çok soyut yada çok somut olduğundan fazla ilgimi çekmemişti ve ben de aynı görüşlere sahiptim. Bir gün kendime bir kütüphane hazırladım, sonra dönüp baktım, yaw acaba buna mı DI diyorlar diye. İşin özü aslında oldukça basit ama yukarıdakinden biraz farklı. Kısa bir örnekle anlatmaya çalışayım:
DI Framework: class DIR { void Register(Func factory); Func Resolve(); static DIR AppRegistry = new DIR(); }
Kütüphane kullanımı: … var con = DIR.AppRegistry.Resolve()(); …
Your App Loading: … DIR.AppRegistry.Register(()=>new CoolDBConnection()); yada DIR.AppRegistry.Register(()=>_dbConnectionInstance);
Yani interface direkt olarak kütüphaneye gitmiyor. Tabi bu benim kullanım şeklim.
Benim gördüklerim register fonksiyonunda Func vermek yerine type yazıyor. Tabi buna ek olarak bir sürü kod mevcut. Çok incelemedim ama temel mantık aynı. Uygulama interface i eline vermedi de, şırınga etti
Peki şart mıdır? Avukatı değilim, hatta konuyu atla deve gibi gösterdiklerinden dolayı Alt.NET de konu ile bir yazı görünce atlıyorum. Uzunca bir yorum oldu, biraz daha devam edersem önce dönüp her cümle için test yazmak zorunda kalacağım
Merhaba Orçun,
Evet illa da interface olmasına gerek yok, base classta olabilir fakat genellikle interface tercih edilir çünkü test ortamında interfaceler için rahatça mock nesneleri oluşturulabilir. Senin örneğin daha çok IoC (Inversion Of Control) Container’a benzemiş. Containerlara her servis (interface oluyor genellikle) için bir implementasyon kaydediliyor ve her servise ihtiyaç duyulduğunda Get ya da Resolve gibi bir metot ile bir implemantasyon alınıyor, tabi Containerlar sadece basit mappingden daha fazlasını yapıyorlar. Nesnelerin yaşam sürelerini kontrol ediyorlar (Lifetime management), bağımlılıkları otomatik olarak çözümlüyorlar (auto-wiring) vs vs…
Senin stiline benzer şekilde kullanılan bir Container olarak AutoFac örnek verilebilir.
Ben de Wordpress’in azizliğine uğradım çünkü bu yazı bir seneden eski olmasına rağmen permalinkte bir değişiklik yapınca RSS okuyucularda yeni gibi beliriverdi
Özür, dediğimde haklı çıktım. Koddaki açıklamaları ingilizce yazdığımı farkettim, hepsini türkçeleştirmemişim. TDD nin laneti
Hatırlamaz mıyım, yazıyı eskiden okumuştum. Yeri geldi, yazayım dedim. IoC mevzusuna gelirsek. Bana kalırsa bu yöntem, belirttiğin 3 yönteme bir alternatif ve en azından GoF un dışına çıkartarak yeni isim hakkını elde edebilir. IoC’un daha çok kodun kullanıma yönelik bir kavram olduğunu düşünüyorum. Bu kodun “Control” ile ilgili olmasına gerek yok. Bir kavram daha ekleyerek konuyu özetleyelim yada ortalığı dağıtalım “Repository Pattern” kullanılarak yazılan bu “Dependency Injection Framework” u kullanarak “Inversion of Control” yapmak kolaylaşmakta. Acaba bütün bu kavramları ortadan kaldırabilicek, çok kısa “pseudo kod” yazımını sağlayan bir dile mi ihtiyacımız var ?
Sanırım yazdığın kod örneği < > karakterleri yüzünden html filtereye takılmış ama genel fikir anlaşılıyor.
Evet, IoC kodun sadeleşmesini sağlıyor, fakat ileri seviye kullanımlarda “Control”‘e de etkisi olmuyor değil. Örneğin containerdan bir CoolDbConnection istendiği zaman, CoolDbConnection nesnesi LoggingDbConnection nesnesi içine gömülüp geri döndürülebilir ve nesneyi isteyen kodun bundan haberi bile olmaz. Dolayısıyla loglama işleminin kontrolü artık çağrıyı yapan kodda değil.
Bütün bu kavramların ortaya çıkma sebebi ve ortak amaç her zaman hatasız yazılımlar üretebilmek. Dolayısıyla geçtim yazımı kolaylaştırmasını ama yazılan kodun her koşulda doğru çalışabileceğini matematiksek olarak kanıtlayabilen bir derleyici ve dile kimsenin hayır diyeceğini sanmıyorum
Ben teşekkür ederim. Aslında türkçem çokta güçlü değildir, bazen sıkıntı çekiyorum fakat elimden geldiğince iyi ifade etmeye çalışıyorum.
İyi çalışmalar.
Türkçesi güçlü olan bir yazılımcı daha bulduğum için mutluyum. Elinize sağlık, güzel bir “DI” eleştirisi olmuş.
Name (required)
Mail (will not be published) (required)
Website