poor man's injection

• poor man's injection ya da bastard injection, di container kullanma imkanımız olmadığı durumlarda dependency injection yapmamızı sağlayan bir tekniktir.
  
  örneğin sistem zamanı bilgisiyle çalışan bir class yazdığımızı varsayalım. .net ortamında bu bilgi datetime struct'ının static bir property'si ile sunulur. class'ımız eğer bilgiye direkt olarak bu property üzerinden ulaşırsa, davranışı test etmemiz için zaman bilgisine dayanan testler yazmamız veya sistem saatini değiştirmek için türlü taklalar atmamız gerekecektir. düzgün bir unit test bu çeşit konfigürasyonlara ihtiyaç duymamalı ve kararlı sonuçlar üretmelidir. saat 2:00'den sonra fail olan, diğer zamanlarda çalışan bir test doğru değildir.
  
  class'ın bu bilgiye direkt olarak datetime.now yerine bir dependency üzerinden ulaşmasını sağlarsak zaman bilgisini test senaryosuna göre istediğimiz değere set edebiliriz. bunun için basit bir interface işimizi görecektir.
  
  artık class'ımıza constructor injection ile bu dependency'yi sağlayabiliriz. örnekteki görüntü di kullanılan projelerde görebileceğiniz klasik bir görüntüdür. class'ın çalışması için gereken dependency'ler interface'leri ile constructor'da belirtilmiş, bu parametreler field'lara atanmış, böylece diğer metotlar tarafından kullanılabilmektedirler. unit test'lerde constructor'dan implementation'lar yerine mock'lar verilerek class'ın davranışı test edilir. bu testleri ve class'ı yazarken idatetimeprovider interface'ini implemente eden hiçbir class yazmamıza gerek yok. ihtiyaç duyduğumuz dependency'lerin implementation'ları ayrı class'lardır, kendilerine ait unit test'leri olacaktır. bu class'ların da ihtiyaç duyduğu dependency'ler olabilir.
  
  class'ın doğru çalıştığını testlerimizle onayladıktan sonra kütüphanemizi publish etmeye karar verdik. bu basit kütüphane için bir di container şart koşmak ayıp olur ama şu anki haliyle scheduler class'ının instance'ını oluşturmak için bir adet idatetimeprovider instance'ına ihtiyacımız var. aslında bu interface ve implementation'ı library'ninin public interface'inde yer almamalıdır. kullanıcıya aslında sadece scheduler class'ını sunmak istiyoruz. kullanıcının kütüphanenin içinde kalması gereken detayları bilmesine gerek yok.
  
  bunun için scheduler class'ına bir constructor overload'u ekliyoruz ve bu detayı kullanıcıdan gizliyoruz. artık kullanıcının idatetimeprovider ve datetimeprovider'dan haberi olmasına bile gerek yok. bu öğeleri ve ilk constructor'ı internal yaparak assembly'de de gizleyebiliriz. (test assembly'leri için internalsvisibleto attribute'u gerekecektir.) böylece hem dependency injection kullanarak fonksiyonaliteyi küçük parçalara ayırıp test edebildik, hem de encapsulation'ı sağladık. aynı zamanda bunun için herhangi bir di container kullanmadık.
• dependency injection öğrenmeden önce herkes bilmeden etmeden bunu kullanır.
  
  var paymenthandler = new paymenthandler();
  yaptığınız yani new'ladığnız anda poor man's injection kullanmış oluyorsunuz.
  
  antipattern'in dibidir. çağıran fonksiyon kendi elleriyle bir dependency yaratır ve ikisi tightly coupled hale gelir. unit testing olanakları da azalır. iğrençtir. yerine kullanılması şiddetle önerilen ioc teknikleri üzerinden dependency injection'ı tercih ediniz. bastard injection ve service locator gibi anti-pattern'lerden uzak durunuz. kusmuk'unuz iyi günler diler.