19.08.2017

Bagliligi Tersine Çevirme Prensibi - Dependency Inversion Principle – DIP

SOLID tasarim prensiplerini anlattigim makale serisinin sonuna gelmis bulunuyoruz. Dependency Inversion (Bagliligi tersine çevirme – bu arada itiraf ediyorum; bu prensiplerin Türkçesini yazinca çok tuhaf oluyorum) prensibi… Dilerseniz yine bu prensibin temel cümlesini ele alarak baslayalim.

 

  1. Yüksek seviye modüller, düsük seviye modüllere bagli olmamali. Her ikisi de soyut (abstract) kavramlara bagli olmali.
  2. Soyut kavramlar detaylara bagli olmamali. Detaylar soyut kavramlara bagli olmali.

Elbette bu kurallari öncelikle günlük hayata uygulayacagiz. Hep söyledim yine söylüyorum, yazilim mimarisinde uygulanan tasarim prensipleri, hayatin ta kendisinden ilham almistir. O halde söyle hayatimiza bakalim ve kavramasi zormus gibi gözüken su iki maddenin aslinda ne kadar kolay oldugunu görelim.

Simdi size, mobilyalari zemine sabitlenmis bir ev oldugunu söylesem; bu evin efektif oldugunu düsünür müydünüz? Hiçbir esyasini yerinden dahi oynatamadiginiz bir ev ne kadar mantikli olabilir ki? Burada tasarimsal bir problemin oldugu asikâr öyle degil mi?

Hadi benzer bir örnekle devam edelim. Evinizdeki ampul patladiginda koskoca elektrik tesisatini degistirdiginizi bir düsünsenize! Yani büyük modül (elektrik tesisati) küçük modüle (ampul) bagli olmamali! Her ikisi de soyut kavrama (lamba –duy ve ampul-) bagli olmali. Üstelik burada, ampulün kaç Watt oldugu (detay), lambanin duy kismini (soyut) ilgilendirir mi? Hiç sanmiyorum.

Buna benzer yüzlerce örnek verilebilir. Ancak biraz daha teknik bir örnek vermem gerektigini düsünüyorum. Günümüzde; ayni altyapiyi kullanan fakat birden fazla arayüze (web, mobile gibi) sahip olan birçok uygulama var. Burada da altyapi üzerinde çalisan ve is süreçlerini yöneten katman bizim “yüksek seviye” modülümüzdür. Bu açidan bakildiginda kullanici arayüzünün düsük seviye oldugunu söylememiz mümkün.

Tamam. Bu kadar sözel örnek yeterli sanirim. Artik bu prensibi kodlarimizda nasil uygulayacagimiza odaklanabiliriz.

Bu örnekte kullanacagimiz senaryoya göre; hali hazirda bir web servisiniz var ve bu servis, veri paylasimi için XML formatini kullaniyor. Öncelikle kötü tasarlanmis bir yapiyi görelim sonrada bunun neden kötü oldugunu tartisalim.

Kodumuz gayet sikintisiz. Buraya kadar sorun yok. Ancak, yillar sonra bir gün JSON (JavaScript Object Notation) diye yeni bir veri paylasim formati çikar ve sizde tüm altyapiyi degistirmek zorunda kalirsiniz. Peki bunu yapmak, bu mimaride kolay olur muydu sizce?

Bu mimarideki yüksek modül, ProductService sinifidir. Düsük seviyede bulunan modül ise dogal olarak XMLConverter sinifidir. Bu noktada, ProductService sinifinin XMLConverter sinifina bagimli oldugu çok net ortada. Çünkü artik veri paylasimini JSON formatiyla yapmaya karar verdiginizde, degistirmeniz gereken sinif kesinlikle ProductService olacaktir. Evet, ampulü degistirmek için koskoca tesisati degistirmek zorunda kalacaksiniz.

Öyleyse en basta mimariyi nasil düzenlemeliydik? Burada, büyük modülünüzün Publishmetodunun ana unsur oldugunun farkinda oldugunuzu düsünüyorum. O halde yapmaniz gereken sey Loosely Coupling yaklasimi, SRP ilkesini ve ISP ilkesini bir araya getirerek Convert metodunu ayri bir Interface içine almak olacaktir.

Bu degisimi sagladiktan sonra büyük modülünüzü de buna göre degistirmelisiniz.

Bu degisiklik sayesinde, ampul patladiginda sadece yeni bir ampul alabileceksiniz. Hatta dilerseniz floresan bile takabilirsiniz!

 

Peki, bu mimaride “istedigimiz zaman istedigimiz sinifla (JSONConverter veya XMLConverter) çalismak istersek” ne yapacagiz? Iste bu Dependency Injection yani baska bir makale konusu…

Evet, sevgili dostlarim. Bu yazimiz ile SOLID tasarim prensiplerinin sonuna gelmis bulunuyoruz. Umarim faydali olmus ve nesne yönelimli mimari konusunda sizleri bir adim daha öteye tasimistir.