dependency injection

• inversion of control ile aynı şey değildir. inversion of control programın akışını bir framework'ün kontrol ettiği bir programlama yaklaşımıdır. event driven programming buna örnektir: kullanıcı arayüzü eventler aracılığıyla kontrolü sizin kodunuza verir. başka bir örnek olarak asp.net page lifecycle'ını düşünebiliriz. kullanıcı isteği sayfanın server side code'una ulaşana kadar kontrol asp.net'dedir, program akışını yöneten asp.net'tir, gerektiğinde kontrolü size verir. bu yapı artık çok yaygındır, bunun gibi birçok framework vardır ve katmanlı bir mimari kurmamıza imkan veren yaklaşımlardan biridir ioc.
  
  ioc kullanılmayan bir durum için konsol uygulamalarını gösterebiliriz: uygulamanın başlangıç noktası main methodudur. programın başından sonuna kadar kontrol bizdedir. tüm akışı bizim yönetmemiz gerekmektedir.
  
  martin fowler dependency injection (di) terimini ortaya atmadan önce dependency'leri yöneten framework'lere ioc container deniyordu. ancak bu framework'ler program akışından çok dependency'lerin yönetimiyle ilgilendikleri için dependecy injection terimi bu işi daha iyi karşılamaktadır. bu terim genel olarak kabul edilmiş olsada ioc container terimi de hala oldukça yaygın. bunun sebebi ioc'nin daha kapsamlı bir kavram olduğunun ve container'lardan önce de var olduğunun gözden kaçırılması.
  
  di, yıllardır etrafta olmasına rağmen tam olarak anlaşılamamış bir teknik. service locator gibi bir anti-pattern'in yaygın olarak kullanılması buna bir örnek. go to implementation'ı bozuyor diyen arkadaşlara da kayda değer herhangi bir refactoring tool kullanmalarını tavsiye ediyorum. di ile ilgili birkaç yanlış inanç daha:
  
  - di sadece late binding için gereklidir : di bu imkanı sağlasa da bu resmin küçük bir kısmını görmek demektir, di çok daha fazla şey yapabilir.
  
  - di sadece unit testing'i desteklemek içindir : di unit testing için zorunlu olsa da diğer özelliklerini göz ardı etmek yanlış olur. yine de unit testing'i doğru bir şekilde yapmayı amaçlayan herkesin karşısına di eninde sonunda çıkacaktır.
  
  - di gelişmiş bir abstract factory'dir : di bütün object graph'ını oluşturmak için kullanılsa da service locator'dakinin aksine bu iş sistemin kalanı için transparent olmalıdır. di container bir seam ile uygulamaya tek bir yerden bağlanmalıdır (composition root) ve sistemin kalanı di container hakkında hiçbirşey bilmemelidir.
  
  - di için di container gereklidir : di container işleri her zaman kolaylaştırsa da kesinlikle zorunlu değildir. yine de di container kullanmamak yönünde bir kısıt varsa (örneğin internette paylaşacağımız küçük bir library var, herhangi bir di container'a bağımlı olmamız mümkün değil) poor man's injection geçerli bir yöntemdir.
  
  peki bunlar değilse nedir di? di; loosely coupled, maintainable, testable, extensible kod yazmayı hedefleyen bir araçtır. diğer solid prensiplerine destek olur. aynı zamanda bu prensipler ve unit testing, di'ın ortaya çıkmasında rol oynamıştır. bana göre bu yüzden tdd'ye girmeden ve en azından single responsibility principle'ını sindirmeden ne gibi sorunları çözdüğünü somut olarak görmek mümkün değildir. üzerine okuyup, kafa yorulması gerekir.
  
  zaman içinde referans verdiğim boş başlıkları doldurmayı umuyorum. herhangi bir soru veya öneri için mesaj atabilirsiniz. entry'nin büyük bir kısmı dependecy injection in .net kitabından referans alınmıştır.