Dependency Injection

Debug ve Temiz Kod yazılarından sonra ismini sıkça duyduğumuz, adını bilmeden uyguladığımız ya da tam da uygulanması gereken noktalarda özen göstermediğimiz Dependency Injection konusunda yazmak istedim. Şu ana kadar yazmaya çalıştığım konular zemini sağlam yapmaya yarayacak konular oldu. Temiz kod yazımı, SOLID prensipleri, birim testlerin önemi ve Debug yapabilmek doğrudan kod yazmayı değil yazılmakta olan ya da var olan kodlar bütününü daha doğru şekilde yazmayı amaçlamanın neticesinde oluşmuş yazılardı. Bir önceki yazımızı SOLID Prensipleri ile bitirmiştik. Bu yazıya önceki yazıda bırakmış olduğumuz noktadan başlayalım.

SOLID diye kısaltılan prensiplerin en sonundaki harf tarafından temsil edilen Dependency Inversion Principle ile tümüyle aynı şeyleri ifade etmese de benzer amaçları olan Dependency Injection kavramına değinmek istiyorum.

dependencyinjectioncaps

Yazının başında ifade ettiğim gibi Dependency Injection kavramı bilerek ya da bilemeyerek de olsa bir çok yazılım geliştiricinin uyguladığı bir desendir. Kodun okunabilirliği ve mimarinin kurgulanması açısından yazılım geliştiricilere fazlasıyla yardımcı olan bir desendir. Dependency Injection, kodun aritmetiğini işin kitabına uygun ve verimli şekilde yapmayı amaçlayan bir konu. Dependency Injection’ı kısaca açıklayacak olursak projemizin dışarıya bağımlı olmasıdır. Fazlasıyla kısa bir ifade oldu sanırım 🙂 Bu bağımlılık bir fremawork, dll, obje, konfigürasyonlar, statik tanımlamalar, new keywordü ile yaratılan nesneler, email servisi, log servisi, sistem kaynakları (sunucudaki tarih,saat vs.) veya third party bir ürün olabilir.

Uygulamalar geliştirilirken ihtiyaçlar kapsamında yukarıda bahsettiğim dışa bağımlı kısımlar olabilir. Dependency Injection bu bağımlılıkları aza indirgeyip yönetilebilir hale getirilmesini amaçlar. Dependency Injection ile uygulamanın bağımlı olduğu alanları uygulamaya enjekte ederken enjekte edilen alanların dinamik olarak değiştirilmesine olanak sağlanması hedeflenir. Yapılan bir işin ihtiyaç duyulan başka çalışmalara mümkünse hiç değişiklik olmadan uyarlanabilecek şekilde tasarlanmış olmasıdır. Loosely coupled (gevşek bağlı) tasarım prensibi dikkate alınarak yazılım içerisinde kullanılan obje, sınıf ya da komponentler değişiklik taleplerine cevap verebilecek şekilde tasarlanmalıdır. Dependency Injection bakımı daha kolay yapılabilir, test edilebilir, loosely coupled (gevşek bağlılık) kod yazmayı amaçlayan bir desendir. Solid prensiplerine uygun kod yazılmasını sağlar. Dependency Injection deseni dikkate alınmadığında uygulama büyüdükçe yapılacak küçük değişiklikler bile uygulamanın bir çok yerini etkileyebilir ve etki analizi büyük olabilir. Dependency Injection desenine uyulmadığında her yeni veya değişiklik ihtiyacı için geniş geliştirme yapmak gerekecektir. Bu durumda bir süre sonra var olan yerlerde değişiklik yapmaktansa yeni classlar oluşturmak gibi yollara gidilebilir ki bu da uygulamada gereksiz kodlama veya karmaşıklığa sebep olur. Bir süre sonra Lemi Orhan’dan alıntıyla ifade edecek olursak “Kod’dan kötü kokular gelmeye başlar.”

Bir genelleme yapmak istemem ama galiba toplumumuzun genel bir özelliği kervan yolda düzelir düşüncesi bir çok yazılım projesinde de kendisini gösteriyor. Uzun süren toplantılar, hazırlanan analiz dökümanları, net olarak belirtilmeyen use case’ler ve oluşturulmayan mimari sebebiyle bir çok proje yapım aşamasında olgunlaşıyor.  Oysa ki başta use case’lerin belirlenmesi, mimarinin tasarlanması ve bağımlılıkların ortaya konulması projenin daha net iterasyonlarla devam etmesine katkı sunar. Aksi takdirde süreç içerisinde yeni isteklerle, öngörülmeyen ihtiyaçlarla proje sürekli yeniden düzenlenmek zorunda kalır. Dependency Injection deseni biraz da sonrada gelecek ihtiyaçlara hızlı entegrasyonun sağlanmasına katkıda bulunur.

DI tasarım deseni sayesinde aşağıdaki sorular cevaplanmış olur.

  • Bir uygulamanın nesnelerinin nasıl oluşturulduğundan bağımsız olarak nasıl olabilir?
  • Bir sınıf, ihtiyaç duyduğu nesnelerin nasıl oluşturulduğundan bağımsız nasıl çalışabilir?
  • Nesnelerin oluşturulma şekli, ayrı yapılandırma dosyalarında nasıl belirtilebilir?
  • Uygulama farklı konfigürasyonları nasıl destekleyebilir?

Avantajları :

  • Kod bağımlılığını azaltır
  • Kodun tekrar kullanılabilirliğini artırır.
  • Kodun sürdürülebilirliğini artıtrır
  • Uygulama testinin yapılabilmesini kolaylaştırır.
  • Sınıf birleştirmeyi azaltır
  • Merkezi yapılandırma

Dezavantajları

  • Karmaşıklık katabilir. Çünkü her şey metod ya da sınıfın içerisinde yazılmamıştır.
  • Öğrenmek, kodu anlamak biraz vakit alabilir.

Dependency Injection için yazmış olduğum kod projesine github adresimden inceleyebilirsiniz.

Leave a Reply