Yaz\u0131l\u0131m geli\u015ftirme d\u00fcnyas\u0131nda kar\u015f\u0131la\u015f\u0131lan en b\u00fcy\u00fck zorluklardan biri, zamanla bak\u0131m\u0131 zorla\u015fan, yeni \u00f6zellik eklemenin maliyetli hale geldi\u011fi ve bir de\u011fi\u015fikli\u011fin domino etkisiyle bir\u00e7ok yeri bozabilece\u011fi sistemler in\u015fa etmektir. Peki, daha esnek, test edilebilir ve s\u00fcrd\u00fcr\u00fclebilir bir kod taban\u0131 olu\u015fturmak m\u00fcmk\u00fcn m\u00fc? Elbette, bu sorunun cevab\u0131 SOLID prensiplerinden biri olan Ba\u011f\u0131ml\u0131l\u0131k Tersine \u00c7evirme Prensibi (Dependency Inversion Principle – DIP) ile yak\u0131ndan ili\u015fkili. Bu makalede, DIP’in ne oldu\u011funu, neden \u00f6nemli oldu\u011funu ve projelerinizde nas\u0131l uygulayarak kod kalitenizi art\u0131rabilece\u011finizi ad\u0131m ad\u0131m inceleyece\u011fiz.<\/p>\n
Her yaz\u0131l\u0131m projesi, farkl\u0131 bile\u015fenlerin bir araya gelmesiyle olu\u015fur. Bir kullan\u0131c\u0131 aray\u00fcz\u00fc, bir veritaban\u0131 katman\u0131, i\u015f mant\u0131\u011f\u0131 katman\u0131 ve harici servis entegrasyonlar\u0131 gibi pek \u00e7ok mod\u00fcl birbiriyle etkile\u015fim halindedir. Bu mod\u00fcller aras\u0131ndaki ili\u015fkiler, yani “ba\u011f\u0131ml\u0131l\u0131klar”, kod taban\u0131n\u0131n sa\u011fl\u0131\u011f\u0131 \u00fczerinde do\u011frudan bir etkiye sahiptir. Geleneksel yakla\u015f\u0131mlarda, y\u00fcksek seviyeli mod\u00fcller (i\u015f mant\u0131\u011f\u0131 i\u00e7eren mod\u00fcller) genellikle d\u00fc\u015f\u00fck seviyeli mod\u00fcllere (veritaban\u0131 eri\u015fimi, dosya i\u015flemleri gibi detaylar\u0131 y\u00f6neten mod\u00fcller) do\u011frudan ba\u011f\u0131ml\u0131 hale gelir. Bu durum, ilk bak\u0131\u015fta do\u011fal gibi g\u00f6r\u00fcnse de, zamanla ciddi sorunlara yol a\u00e7abilir. \u00d6rne\u011fin, i\u015f mant\u0131\u011f\u0131n\u0131 i\u00e7eren bir raporlama mod\u00fcl\u00fcn\u00fcz\u00fcn do\u011frudan belirli bir SQL veritaban\u0131 s\u00fcr\u00fcc\u00fcs\u00fcne ba\u011f\u0131ml\u0131 oldu\u011funu d\u00fc\u015f\u00fcn\u00fcn. E\u011fer gelecekte veritaban\u0131n\u0131z\u0131 NoSQL bir \u00e7\u00f6z\u00fcme veya farkl\u0131 bir SQL sa\u011flay\u0131c\u0131s\u0131na ge\u00e7irmek isterseniz ne olur? Muhtemelen raporlama mod\u00fcl\u00fcn\u00fczdeki bir\u00e7ok kodu ba\u015ftan yazmak veya kapsaml\u0131 de\u011fi\u015fiklikler yapmak zorunda kal\u0131rs\u0131n\u0131z. Bu senaryo, yaz\u0131l\u0131m\u0131n esnekli\u011fini ve de\u011fi\u015fime adaptasyon yetene\u011fini \u00f6nemli \u00f6l\u00e7\u00fcde k\u0131s\u0131tlar.<\/p>\n
Bu t\u00fcr somut ba\u011f\u0131ml\u0131l\u0131klar, kodun “kat\u0131” (rigid) ve “k\u0131r\u0131lgan” (fragile) olmas\u0131na neden olur. Kat\u0131l\u0131k, bir sistemde yap\u0131lan k\u00fc\u00e7\u00fck bir de\u011fi\u015fikli\u011fin, sistemin bir\u00e7ok yerinde b\u00fcy\u00fck de\u011fi\u015fiklikleri tetiklemesi anlam\u0131na gelir. K\u0131r\u0131lganl\u0131k ise, bir sistemin bir yerinde yap\u0131lan de\u011fi\u015fikli\u011fin, sistemin ba\u015fka bir yerinde beklenmedik hatalara yol a\u00e7mas\u0131 durumudur. Ayr\u0131ca, somut ba\u011f\u0131ml\u0131l\u0131klar, birim testlerini (unit tests) yazmay\u0131 da zorla\u015ft\u0131r\u0131r. \u00c7\u00fcnk\u00fc bir mod\u00fcl\u00fc test etmek istedi\u011finizde, onun ba\u011f\u0131ml\u0131 oldu\u011fu t\u00fcm di\u011fer mod\u00fclleri de \u00e7al\u0131\u015ft\u0131rmak veya sahte (mock) nesnelerle taklit etmek zorunda kal\u0131rs\u0131n\u0131z. Bu da test s\u00fcre\u00e7lerini karma\u015f\u0131kla\u015ft\u0131r\u0131r ve yava\u015flat\u0131r. Bu sorunlar\u0131n temelinde, yaz\u0131l\u0131m mimarisindeki “ba\u011f\u0131ml\u0131l\u0131k y\u00f6n\u00fc” yatar. Y\u00fcksek seviyeli politikalar, d\u00fc\u015f\u00fck seviyeli detaylara ba\u011f\u0131ml\u0131 hale geldi\u011finde, sistemin genel yap\u0131s\u0131 zay\u0131flar. \u0130\u015fte bu noktada Ba\u011f\u0131ml\u0131l\u0131k Tersine \u00c7evirme Prensibi devreye girer ve bu ba\u011f\u0131ml\u0131l\u0131k y\u00f6n\u00fcn\u00fc tersine \u00e7evirerek daha sa\u011flam bir yap\u0131 sunar.<\/p>\n
Yaz\u0131l\u0131m geli\u015ftirme s\u00fcre\u00e7lerinde kar\u015f\u0131la\u015f\u0131lan bu tip ba\u011f\u0131ml\u0131l\u0131k sorunlar\u0131, genellikle projenin \u00f6l\u00e7e\u011fi b\u00fcy\u00fcd\u00fck\u00e7e veya ekip \u00fcyeleri de\u011fi\u015ftik\u00e7e daha belirgin hale gelir. Ba\u015flang\u0131\u00e7ta basit g\u00f6r\u00fcnen bir sistem, zamanla karma\u015f\u0131k bir \u00f6r\u00fcmcek a\u011f\u0131na d\u00f6n\u00fc\u015febilir ve bu a\u011fdaki herhangi bir d\u00fc\u011f\u00fcme dokunmak, t\u00fcm yap\u0131y\u0131 sarsma riskini ta\u015f\u0131r. Bu durum, geli\u015ftiriciler i\u00e7in s\u00fcrekli bir endi\u015fe kayna\u011f\u0131d\u0131r ve yeni \u00f6zelliklerin geli\u015ftirilmesini yava\u015flat\u0131r, hata oranlar\u0131n\u0131 art\u0131r\u0131r. Bu nedenle, yaz\u0131l\u0131m mimarisini tasarlarken ba\u011f\u0131ml\u0131l\u0131klar\u0131n do\u011fru bir \u015fekilde y\u00f6netilmesi, uzun vadede projenin ba\u015far\u0131s\u0131 i\u00e7in kritik \u00f6neme sahiptir. DIP, bu karma\u015f\u0131kl\u0131\u011f\u0131 y\u00f6netmek ve sistemin daha mod\u00fcler, anla\u015f\u0131l\u0131r ve s\u00fcrd\u00fcr\u00fclebilir olmas\u0131n\u0131 sa\u011flamak i\u00e7in g\u00fc\u00e7l\u00fc bir ara\u00e7 sunar. Gelecek b\u00f6l\u00fcmlerde bu prensibin detaylar\u0131na inerek, bu sorunlara nas\u0131l zarif \u00e7\u00f6z\u00fcmler getirdi\u011fini ke\u015ffedece\u011fiz.<\/p>\n
Ba\u011f\u0131ml\u0131l\u0131k Tersine \u00c7evirme Prensibi (DIP), Robert C. Martin (Uncle Bob) taraf\u0131ndan ortaya konan SOLID prensiplerinin “D” harfini temsil eder. Bu prensip, iki temel kural \u00fczerine kuruludur:<\/p>\n
Bu iki kural\u0131 a\u00e7acak olursak, y\u00fcksek seviyeli mod\u00fcller, uygulaman\u0131z\u0131n ana i\u015f mant\u0131\u011f\u0131n\u0131 veya politikalar\u0131n\u0131 bar\u0131nd\u0131ran mod\u00fcllerdir. \u00d6rne\u011fin, bir sipari\u015f i\u015fleme mod\u00fcl\u00fc veya bir rapor olu\u015fturma mod\u00fcl\u00fc y\u00fcksek seviyeli mod\u00fcllerdir. D\u00fc\u015f\u00fck seviyeli mod\u00fcller ise, bu i\u015f mant\u0131\u011f\u0131n\u0131n uygulanmas\u0131 i\u00e7in gerekli olan somut detaylar\u0131 sa\u011flayan mod\u00fcllerdir. \u00d6rne\u011fin, bir veritaban\u0131 s\u00fcr\u00fcc\u00fcs\u00fc, bir dosya sistemi eri\u015fim s\u0131n\u0131f\u0131 veya bir harici API istemcisi d\u00fc\u015f\u00fck seviyeli mod\u00fcllerdir. Geleneksel yakla\u015f\u0131mlarda, y\u00fcksek seviyeli mod\u00fcller do\u011frudan d\u00fc\u015f\u00fck seviyeli mod\u00fcllerin somut implementasyonlar\u0131na ba\u011f\u0131ml\u0131 hale gelir. DIP ise bu ba\u011f\u0131ml\u0131l\u0131k y\u00f6n\u00fcn\u00fc tersine \u00e7evirir. Yani, hem y\u00fcksek seviyeli mod\u00fcller hem de d\u00fc\u015f\u00fck seviyeli mod\u00fcller, aray\u00fczler (interfaces) veya soyut s\u0131n\u0131flar (abstract classes) gibi soyutlamalara ba\u011f\u0131ml\u0131 hale gelir.<\/p>\n
Peki, bu ne anlama geliyor? Diyelim ki bir e-ticaret uygulaman\u0131z var ve bir sipari\u015f i\u015fleme (y\u00fcksek seviyeli mod\u00fcl) yetene\u011finiz mevcut. Bu sipari\u015f i\u015fleme mod\u00fcl\u00fc, sipari\u015fleri bir veritaban\u0131na kaydetmek (d\u00fc\u015f\u00fck seviyeli mod\u00fcl) istiyor. DIP’e g\u00f6re, sipari\u015f i\u015fleme mod\u00fcl\u00fc do\u011frudan \u0130kinci kural olan “soyutlamalar detaylara ba\u011f\u0131ml\u0131 olmamal\u0131d\u0131r, detaylar soyutlamalara ba\u011f\u0131ml\u0131 olmal\u0131d\u0131r” ifadesi de bu durumu peki\u015ftirir. Yani, Yaz\u0131l\u0131m geli\u015ftirme prati\u011finde, \u00e7o\u011fu zaman fark\u0131nda olmadan Ba\u011f\u0131ml\u0131l\u0131k Tersine \u00c7evirme Prensibi’nin tam tersi y\u00f6nde hareket ederiz. \u00d6zellikle k\u00fc\u00e7\u00fck projelerde veya h\u0131zl\u0131 prototipleme a\u015famalar\u0131nda, i\u015flevselli\u011fi bir an \u00f6nce hayata ge\u00e7irmek ad\u0131na, y\u00fcksek seviyeli mod\u00fcllerin d\u00fc\u015f\u00fck seviyeli mod\u00fcllere do\u011frudan ba\u011f\u0131ml\u0131 hale geldi\u011fi somut ba\u011f\u0131ml\u0131l\u0131klar olu\u015ftururuz. Bu, ilk ba\u015fta pratik ve h\u0131zl\u0131 g\u00f6r\u00fcnse de, uzun vadede sistemin s\u00fcrd\u00fcr\u00fclebilirli\u011fini ve esnekli\u011fini ciddi \u015fekilde tehlikeye atar. Geleneksel ba\u011f\u0131ml\u0131l\u0131klar\u0131n sistemlerimizi neden k\u0131r\u0131lgan hale getirdi\u011fini anlamak, DIP’in de\u011ferini kavramak i\u00e7in hayati \u00f6neme sahiptir.<\/p>\n Bir \u00f6rnek \u00fczerinden gidelim: Bir e-posta bildirim sistemi geli\u015ftirdi\u011finizi varsayal\u0131m. Ana i\u015f mant\u0131\u011f\u0131n\u0131z, bir kullan\u0131c\u0131ya belirli bir olay ger\u00e7ekle\u015fti\u011finde (\u00f6rne\u011fin, sipari\u015f onay\u0131) e-posta g\u00f6ndermektir. Geleneksel bir yakla\u015f\u0131mla, Bu \u00f6rnekte, Bu t\u00fcr somut ba\u011f\u0131ml\u0131l\u0131klar, yaz\u0131l\u0131m projesinin \u00f6mr\u00fc boyunca biriken teknik borcun (technical debt) \u00f6nemli bir par\u00e7as\u0131d\u0131r. Ba\u015flang\u0131\u00e7ta g\u00f6z ard\u0131 edilen bu k\u00fc\u00e7\u00fck ba\u011f\u0131ml\u0131l\u0131klar, zamanla birikerek sistemin “k\u0131r\u0131lgan” bir yap\u0131ya b\u00fcr\u00fcnmesine neden olur. Bir mod\u00fclde yap\u0131lan ufak bir de\u011fi\u015fiklik, beklenmedik yerlerde hatalara yol a\u00e7abilir, bu da geli\u015ftirme s\u00fcrecini yava\u015flat\u0131r ve maliyetleri art\u0131r\u0131r. DIP, i\u015fte tam da bu noktada devreye girerek, bu k\u0131r\u0131lganl\u0131\u011f\u0131 ortadan kald\u0131rmak ve daha sa\u011flam, esnek ve s\u00fcrd\u00fcr\u00fclebilir sistemler in\u015fa etmek i\u00e7in bir yol haritas\u0131 sunar. Ba\u011f\u0131ml\u0131l\u0131klar\u0131n y\u00f6n\u00fcn\u00fc tersine \u00e7evirerek, y\u00fcksek seviyeli mod\u00fcllerin i\u015f mant\u0131\u011f\u0131n\u0131 altyap\u0131 detaylar\u0131ndan ay\u0131rmay\u0131 hedefler.<\/p>\n Ba\u011f\u0131ml\u0131l\u0131k Tersine \u00c7evirme Prensibi’ni uygulamak, temelde aray\u00fczlerin (interfaces) ve soyut s\u0131n\u0131flar\u0131n (abstract classes) g\u00fcc\u00fcnden yararlanmak anlam\u0131na gelir. Bu soyutlamalar, y\u00fcksek seviyeli mod\u00fcller ile d\u00fc\u015f\u00fck seviyeli mod\u00fcller aras\u0131nda bir k\u00f6pr\u00fc g\u00f6revi g\u00f6rerek, do\u011frudan somut ba\u011f\u0131ml\u0131l\u0131klar\u0131 ortadan kald\u0131r\u0131r. Hadi, \u00f6nceki e-posta bildirim \u00f6rne\u011fimizi DIP prensiplerine uygun hale getirelim.<\/p>\n \u00d6nceki \u00f6rnekte, Yukar\u0131daki kodda neler de\u011fi\u015fti\u011fini ad\u0131m ad\u0131m inceleyelim:<\/p>\n Bu yeni yap\u0131land\u0131rma ile, DIP, yaz\u0131l\u0131m mimarisinde “kontrol\u00fcn tersine \u00e7evrilmesi” (Inversion of Control – IoC) prensibinin bir uygulamas\u0131d\u0131r. Y\u00fcksek seviyeli mod\u00fcl, d\u00fc\u015f\u00fck seviyeli mod\u00fcl\u00fc do\u011frudan kontrol etmek yerine, kontrol\u00fc d\u0131\u015far\u0131dan enjekte edilen bir soyutlamaya b\u0131rak\u0131r. Bu sayede, yaz\u0131l\u0131m bile\u015fenleri aras\u0131ndaki ba\u011flar gev\u015fer (loose coupling) ve sistem daha mod\u00fcler, anla\u015f\u0131l\u0131r ve s\u00fcrd\u00fcr\u00fclebilir hale gelir. Aray\u00fczler ve soyut s\u0131n\u0131flar, bu d\u00f6n\u00fc\u015f\u00fcm\u00fcn anahtar\u0131d\u0131r ve yaz\u0131l\u0131m tasar\u0131m\u0131nda sa\u011flam bir temel olu\u015ftururlar.<\/p>\n DIP’in ger\u00e7ek d\u00fcnya senaryolar\u0131nda nas\u0131l b\u00fcy\u00fck faydalar sa\u011flad\u0131\u011f\u0131n\u0131 daha iyi anlamak i\u00e7in bir \u00f6deme sistemi entegrasyonu \u00f6rne\u011fini inceleyelim. Modern e-ticaret uygulamalar\u0131nda, farkl\u0131 \u00f6deme sa\u011flay\u0131c\u0131lar\u0131yla (kredi kart\u0131, PayPal, sanal pos, mobil \u00f6deme vb.) entegrasyon yapmak olduk\u00e7a yayg\u0131nd\u0131r. Geleneksel yakla\u015f\u0131mlar, bu t\u00fcr entegrasyonlarda ciddi ba\u011f\u0131ml\u0131l\u0131k sorunlar\u0131na yol a\u00e7abilirken, DIP bu sorunlara zarif bir \u00e7\u00f6z\u00fcm sunar.<\/p>\n Ba\u015flang\u0131\u00e7ta, sadece tek bir \u00f6deme sa\u011flay\u0131c\u0131s\u0131 (\u00f6rne\u011fin, X Bankas\u0131 Sanal Posu) ile \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131z\u0131 varsayal\u0131m. \u00d6deme i\u015fleme mant\u0131\u011f\u0131n\u0131z\u0131 i\u00e7eren Bu yap\u0131, ilk ba\u015fta \u00e7al\u0131\u015f\u0131r ve basit g\u00f6r\u00fcn\u00fcr. Ancak, i\u015fler karma\u015f\u0131kla\u015ft\u0131\u011f\u0131nda veya yeni gereksinimler ortaya \u00e7\u0131kt\u0131\u011f\u0131nda sorunlar ba\u015flar:<\/p>\n Bu senaryolarda, \u015eimdi bu yap\u0131y\u0131 DIP prensiplerine g\u00f6re yeniden d\u00fczenleyelim:<\/p>\n Bu DIP uyumlu tasar\u0131m\u0131n sa\u011flad\u0131\u011f\u0131 faydalar olduk\u00e7a fazlad\u0131r:<\/p>\n Bu vaka analizi, DIP’in sadece teorik bir kavram olmad\u0131\u011f\u0131n\u0131, ayn\u0131 zamanda ger\u00e7ek d\u00fcnya yaz\u0131l\u0131m projelerinde kar\u015f\u0131la\u015f\u0131lan karma\u015f\u0131k ba\u011f\u0131ml\u0131l\u0131k sorunlar\u0131na pratik ve etkili \u00e7\u00f6z\u00fcmler sundu\u011funu a\u00e7\u0131k\u00e7a g\u00f6stermektedir. Aray\u00fczler ve ba\u011f\u0131ml\u0131l\u0131k enjeksiyonu (Dependency Injection) gibi teknikler, DIP’i uygulaman\u0131n temel ta\u015flar\u0131d\u0131r ve modern yaz\u0131l\u0131m mimarilerinin olmazsa olmazlar\u0131ndand\u0131r.<\/p>\n Ba\u011f\u0131ml\u0131l\u0131k Tersine \u00c7evirme Prensibi (DIP), yaz\u0131l\u0131m projelerine uyguland\u0131\u011f\u0131nda bir dizi \u00f6nemli avantaj sunar. Bu avantajlar, kod kalitesini art\u0131rmaktan, geli\u015ftirme s\u00fcre\u00e7lerini h\u0131zland\u0131rmaya kadar geni\u015f bir yelpazeyi kapsar ve uzun vadede yaz\u0131l\u0131m\u0131n s\u00fcrd\u00fcr\u00fclebilirli\u011fini garanti alt\u0131na al\u0131r.<\/p>\n DIP, y\u00fcksek seviyeli mod\u00fcllerin somut implementasyonlara do\u011frudan ba\u011f\u0131ml\u0131 olmas\u0131n\u0131 engelleyerek, sistemin daha esnek olmas\u0131n\u0131 sa\u011flar. Bir mod\u00fcl\u00fcn i\u00e7 i\u015fleyi\u015fini de\u011fi\u015ftirmek veya tamamen yeni bir implementasyonla de\u011fi\u015ftirmek istedi\u011finizde, bu de\u011fi\u015fiklikler di\u011fer ba\u011f\u0131ml\u0131 mod\u00fclleri etkilemez. \u00d6rne\u011fin, bir veritaban\u0131 katman\u0131n\u0131 de\u011fi\u015ftirmek veya yeni bir \u00f6deme sa\u011flay\u0131c\u0131s\u0131 entegre etmek, ana i\u015f mant\u0131\u011f\u0131 kodunda minimum de\u011fi\u015fiklikle veya hi\u00e7 de\u011fi\u015fiklik yapmadan ger\u00e7ekle\u015ftirilebilir. Bu, uygulaman\u0131n gelecekteki gereksinimlere kolayca adapte olabilmesini ve yeni \u00f6zelliklerin daha h\u0131zl\u0131 bir \u015fekilde eklenebilmesini sa\u011flar.<\/p>\n<\/li>\n DIP’in belki de en belirgin avantajlar\u0131ndan biri, birim testlerini (unit tests) yazmay\u0131 ve \u00e7al\u0131\u015ft\u0131rmay\u0131 inan\u0131lmaz derecede kolayla\u015ft\u0131rmas\u0131d\u0131r. Y\u00fcksek seviyeli mod\u00fcller soyutlamalara ba\u011f\u0131ml\u0131 oldu\u011fundan, test s\u0131ras\u0131nda ger\u00e7ek ba\u011f\u0131ml\u0131l\u0131klar yerine “mock” (sahte) veya “stub” (taslak) nesneler enjekte edilebilir. Bu sayede:<\/p>\n DIP, mod\u00fcller aras\u0131ndaki ba\u011f\u0131ml\u0131l\u0131klar\u0131 soyutlamalar arac\u0131l\u0131\u011f\u0131yla y\u00f6netti\u011fi i\u00e7in, mod\u00fcller aras\u0131 ba\u011flar\u0131 gev\u015fetir. Mod\u00fcller birbirlerinin somut detaylar\u0131n\u0131 bilmek zorunda kalmazlar, sadece bir aray\u00fcz veya soyut s\u0131n\u0131f \u00fczerinden tan\u0131mlanan kontrata uyarlar. Gev\u015fek ba\u011fl\u0131l\u0131k, bir mod\u00fcldeki de\u011fi\u015fikli\u011fin di\u011fer mod\u00fcllere domino etkisiyle yay\u0131lmas\u0131n\u0131 engeller, bu da sistemin daha az “k\u0131r\u0131lgan” olmas\u0131n\u0131 sa\u011flar. Ayr\u0131ca, farkl\u0131 geli\u015ftirme ekiplerinin ayn\u0131 sistem \u00fczerinde birbirlerinden ba\u011f\u0131ms\u0131z olarak \u00e7al\u0131\u015fabilmelerine olanak tan\u0131r.<\/p>\n<\/li>\n Soyutlamalara dayal\u0131 tasar\u0131m, mod\u00fcllerin daha genel ve yeniden kullan\u0131labilir olmas\u0131n\u0131 te\u015fvik eder. \u00d6rne\u011fin, DIP, yaz\u0131l\u0131m mimarisini daha net ve organize hale getirir. Y\u00fcksek seviyeli i\u015f mant\u0131\u011f\u0131, d\u00fc\u015f\u00fck seviyeli altyap\u0131 detaylar\u0131ndan ayr\u0131ld\u0131\u011f\u0131 i\u00e7in, kodun okunabilirli\u011fi ve anla\u015f\u0131labilirli\u011fi artar. Bu da yeni geli\u015ftiricilerin projeye adaptasyonunu kolayla\u015ft\u0131r\u0131r ve uzun vadede kodun bak\u0131m maliyetlerini d\u00fc\u015f\u00fcr\u00fcr.<\/p>\n<\/li>\n<\/ul>\n Bu avantajlar, DIP’in modern yaz\u0131l\u0131m geli\u015ftirme pratiklerinde neden bu kadar merkezi bir rol oynad\u0131\u011f\u0131n\u0131 a\u00e7\u0131k\u00e7a ortaya koymaktad\u0131r. Sadece mevcut sorunlar\u0131 \u00e7\u00f6zmekle kalmaz, ayn\u0131 zamanda gelecekteki de\u011fi\u015fikliklere ve geni\u015flemelere kar\u015f\u0131 da yaz\u0131l\u0131m\u0131 daha dayan\u0131kl\u0131 hale getirir.<\/p>\n Ba\u011f\u0131ml\u0131l\u0131k Tersine \u00c7evirme Prensibi (DIP), yaz\u0131l\u0131m kalitesini \u00f6nemli \u00f6l\u00e7\u00fcde art\u0131ran g\u00fc\u00e7l\u00fc bir prensip olsa da, yanl\u0131\u015f uyguland\u0131\u011f\u0131nda veya a\u015f\u0131r\u0131 kullan\u0131ld\u0131\u011f\u0131nda baz\u0131 zorluklara yol a\u00e7abilir. Bu b\u00f6l\u00fcmde, DIP’i uygularken dikkat etmeniz gereken \u00f6nemli noktalar\u0131 ve deneyimli geli\u015ftiriciler i\u00e7in ileri seviye ipu\u00e7lar\u0131n\u0131 ele alaca\u011f\u0131z.<\/p>\n 1. A\u015f\u0131r\u0131 Soyutlamadan Ka\u00e7\u0131n\u0131n:<\/strong> E\u011fer bu sorular\u0131n cevab\u0131 “hay\u0131r” ise, basit bir somut s\u0131n\u0131f yeterli olabilir. “YAGNI (You Ain’t Gonna Need It)” prensibini akl\u0131n\u0131zda bulundurun; yani, ihtiya\u00e7 duymayaca\u011f\u0131n\u0131z soyutlamalar\u0131 \u00f6nceden olu\u015fturmay\u0131n.<\/p>\n 2. Ba\u011f\u0131ml\u0131l\u0131k Enjeksiyonu (Dependency Injection – DI) Kullan\u0131m\u0131:<\/strong> 3. Fabrika Metotlar\u0131 ve Abstract Factory Desenleri:<\/strong> 4. Nereden Soyutlama Yap\u0131laca\u011f\u0131n\u0131 Bilmek (Boundary Concerns):<\/strong> 5. Ba\u011f\u0131ml\u0131l\u0131klar\u0131n Y\u00f6n\u00fcn\u00fc Kontrol Etmek:<\/strong> 6. Kod \u0130ncelemelerinde DIP Odakl\u0131l\u0131k:<\/strong> DIP, yaz\u0131l\u0131m mimarinizi daha g\u00fc\u00e7l\u00fc, daha esnek ve daha s\u00fcrd\u00fcr\u00fclebilir hale getiren bir felsefedir. Ancak her ara\u00e7 gibi, do\u011fru zamanda ve do\u011fru \u015fekilde kullan\u0131lmas\u0131 gerekir. Bu ipu\u00e7lar\u0131n\u0131 g\u00f6z \u00f6n\u00fcnde bulundurarak, projelerinizde DIP’i daha bilin\u00e7li ve etkili bir \u015fekilde uygulayabilirsiniz.<\/p>\n Ba\u011f\u0131ml\u0131l\u0131k Tersine \u00c7evirme Prensibi (DIP), modern yaz\u0131l\u0131m geli\u015ftirmenin temel ta\u015flar\u0131ndan biridir. Bu prensip, y\u00fcksek seviyeli mod\u00fcllerin d\u00fc\u015f\u00fck seviyeli mod\u00fcllere do\u011frudan ba\u011f\u0131ml\u0131 olmas\u0131n\u0131 engelleyerek, kod taban\u0131m\u0131z\u0131n esnekli\u011fini, test edilebilirli\u011fini ve s\u00fcrd\u00fcr\u00fclebilirli\u011fini art\u0131rmay\u0131 hedefler. Aray\u00fczler ve soyut s\u0131n\u0131flar arac\u0131l\u0131\u011f\u0131yla ba\u011f\u0131ml\u0131l\u0131klar\u0131 soyutlayarak, yaz\u0131l\u0131m bile\u015fenleri aras\u0131ndaki s\u0131k\u0131 ba\u011flar\u0131 (tight coupling) gev\u015fetir ve kontrol\u00fcn tersine \u00e7evrilmesini (Inversion of Control) sa\u011flar. Ger\u00e7ek d\u00fcnya senaryolar\u0131nda, \u00f6zellikle \u00f6deme sistemleri, bildirim servisleri veya veritaban\u0131 entegrasyonlar\u0131 gibi s\u0131k de\u011fi\u015fen veya farkl\u0131 implementasyonlara sahip olabilecek alanlarda, DIP’in sa\u011flad\u0131\u011f\u0131 avantajlar paha bi\u00e7ilmezdir. Daha az k\u0131r\u0131lgan, daha kolay bak\u0131m\u0131 yap\u0131labilen ve gelecekteki de\u011fi\u015fikliklere daha a\u00e7\u0131k bir yaz\u0131l\u0131m mimarisi in\u015fa etmek isteyen her geli\u015ftiricinin bu prensibi anlamas\u0131 ve projelerinde uygulamas\u0131 kritik \u00f6neme sahiptir.<\/p>\n Hay\u0131r, DIP prensipleri her boyuttaki projede uygulanabilir ve fayda sa\u011flayabilir. K\u00fc\u00e7\u00fck projelerde bile, do\u011fru soyutlamalarla ba\u015flamak, projenin b\u00fcy\u00fcmesi durumunda gelecekteki karma\u015f\u0131kl\u0131\u011f\u0131 \u00f6nleyebilir. Ba\u015flang\u0131\u00e7ta basit gibi g\u00f6r\u00fcnen bir \u00f6zellik, zamanla birden fazla implementasyon gerektirebilir ve bu noktada DIP’in de\u011feri ortaya \u00e7\u0131kar.<\/p>\n<\/li>\n Hay\u0131r, ayn\u0131 \u015feyler de\u011fildirler ancak yak\u0131ndan ili\u015fkilidirler. DIP bir prensiptir (bir tasar\u0131m felsefesi), DI ise bu prensibi uygulaman\u0131n yayg\u0131n bir tekni\u011fi veya desenidir. DI, bir s\u0131n\u0131f\u0131n ba\u011f\u0131ml\u0131l\u0131klar\u0131n\u0131 kendisinin olu\u015fturmas\u0131 yerine, d\u0131\u015far\u0131dan almas\u0131n\u0131 sa\u011flayarak DIP’in “soyutlamalara ba\u011f\u0131ml\u0131l\u0131k” kural\u0131n\u0131 hayata ge\u00e7irir.<\/p>\n<\/li>\n Genellikle aray\u00fczler tercih edilir \u00e7\u00fcnk\u00fc bir s\u0131n\u0131f\u0131n birden fazla aray\u00fcz\u00fc implemente etmesine izin verirler, bu da daha fazla esneklik sa\u011flar. Soyut s\u0131n\u0131flar ise, ortak bir temel implementasyon veya durum (state) sa\u011flamak istedi\u011finizde daha uygun olabilir. E\u011fer birden fazla somut s\u0131n\u0131f aras\u0131nda ortak bir davran\u0131\u015f ve\/veya veri payla\u015f\u0131m\u0131 varsa, soyut s\u0131n\u0131f mant\u0131kl\u0131 olabilir.<\/p>\n<\/li>\n Ba\u015flang\u0131\u00e7ta, \u00f6zellikle k\u00fc\u00e7\u00fck projelerde, aray\u00fczler ve ba\u011f\u0131ml\u0131l\u0131k enjeksiyonu gibi kavramlar kod karma\u015f\u0131kl\u0131\u011f\u0131n\u0131 art\u0131r\u0131yormu\u015f gibi g\u00f6r\u00fcnebilir. Ancak uzun vadede, DIP uyumlu kod daha mod\u00fcler, daha anla\u015f\u0131l\u0131r ve bak\u0131m\u0131 daha kolayd\u0131r. Bu ilk yat\u0131r\u0131m, projenin \u00f6mr\u00fc boyunca ortaya \u00e7\u0131kabilecek teknik borcu azaltarak fazlas\u0131yla geri d\u00f6ner.<\/p>\n<\/li>\n<\/ol>\n #Yaz\u0131l\u0131mMimarisi #SOLID #DIP #DependencyInversionPrinciple #KodKalitesi #Yaz\u0131l\u0131mGeli\u015ftirme #NesneY\u00f6nelimliProgramlama<\/p>\nMySQLVeritaban\u0131<\/code> veya PostgreSQLVeritaban\u0131<\/code> gibi somut bir s\u0131n\u0131fa ba\u011f\u0131ml\u0131 olmamal\u0131d\u0131r. Bunun yerine, IVeritaban\u0131Deposu<\/code> gibi bir aray\u00fcze ba\u011f\u0131ml\u0131 olmal\u0131d\u0131r. Bu aray\u00fcz, kaydet(sipari\u015f)<\/code> gibi metotlar\u0131 tan\u0131mlar. Daha sonra, MySQLVeritaban\u0131<\/code> veya PostgreSQLVeritaban\u0131<\/code> s\u0131n\u0131flar\u0131 bu IVeritaban\u0131Deposu<\/code> aray\u00fcz\u00fcn\u00fc implemente eder. Bu sayede, sipari\u015f i\u015fleme mod\u00fcl\u00fc, hangi veritaban\u0131 teknolojisinin kullan\u0131ld\u0131\u011f\u0131n\u0131 bilmek zorunda kalmaz; sadece bir veritaban\u0131 deposu aray\u00fcz\u00fc ile etkile\u015fim kurdu\u011funu bilir. Bu, y\u00fcksek seviyeli mod\u00fcl\u00fcn d\u00fc\u015f\u00fck seviyeli detaylardan soyutlanmas\u0131n\u0131 sa\u011flar.<\/p>\nIVeritaban\u0131Deposu<\/code> aray\u00fcz\u00fc, MySQLVeritaban\u0131<\/code> s\u0131n\u0131f\u0131n\u0131n i\u00e7 detaylar\u0131na (\u00f6rne\u011fin, SQL sorgular\u0131na) ba\u011f\u0131ml\u0131 olmamal\u0131d\u0131r. Tam tersine, MySQLVeritaban\u0131<\/code> s\u0131n\u0131f\u0131, IVeritaban\u0131Deposu<\/code> aray\u00fcz\u00fcn\u00fcn tan\u0131mlad\u0131\u011f\u0131 kontrata uymak zorundad\u0131r. Bu, ba\u011f\u0131ml\u0131l\u0131k y\u00f6n\u00fcn\u00fcn tersine \u00e7evrilmesidir: Somut implementasyonlar, soyut tan\u0131mlara ba\u011f\u0131ml\u0131 hale gelir. Bu prensibin temel amac\u0131, kodunuzu daha mod\u00fcler, test edilebilir ve de\u011fi\u015fime daha dayan\u0131kl\u0131 hale getirmektir. Uygulaman\u0131z\u0131n temel i\u015f mant\u0131\u011f\u0131, altyap\u0131 detaylar\u0131ndan izole edildi\u011fi i\u00e7in, bu detaylarda yap\u0131lan de\u011fi\u015fiklikler i\u015f mant\u0131\u011f\u0131n\u0131 etkilemez. \u00d6rne\u011fin, veritaban\u0131n\u0131 de\u011fi\u015ftirmek, sadece yeni bir veritaban\u0131 implementasyonu yazmay\u0131 ve bunu sisteme enjekte etmeyi gerektirir, ana i\u015f mant\u0131\u011f\u0131 kodunu de\u011fi\u015ftirmeyi de\u011fil. Bu da yaz\u0131l\u0131m\u0131n bak\u0131m maliyetlerini d\u00fc\u015f\u00fcr\u00fcr ve gelecekteki de\u011fi\u015fikliklere kar\u015f\u0131 daha esnek bir yap\u0131 sa\u011flar.<\/p>\nGeleneksel Ba\u011f\u0131ml\u0131l\u0131klar: Neden Sistemlerimizi K\u0131r\u0131lgan Hale Getirir?<\/h3>\n
Sipari\u015fY\u00f6neticisi<\/code> ad\u0131nda bir s\u0131n\u0131f\u0131n\u0131z olabilir ve bu s\u0131n\u0131f\u0131n i\u00e7inde do\u011frudan SmtpEpostaServisi<\/code> ad\u0131nda somut bir e-posta g\u00f6nderme s\u0131n\u0131f\u0131n\u0131 \u00e7a\u011f\u0131r\u0131rs\u0131n\u0131z. Kodunuz \u015f\u00f6yle g\u00f6r\u00fcnebilir:<\/p>\n\nclass SmtpEpostaServisi {\n public void EpostaGonder(string alici, string konu, string icerik) {\n \/\/ SMTP sunucusu \u00fczerinden e-posta g\u00f6nderme mant\u0131\u011f\u0131\n Console.WriteLine($\"SMTP ile e-posta g\u00f6nderildi: {alici}, Konu: {konu}\");\n }\n}\n\nclass SiparisYoneticisi {\n private SmtpEpostaServisi _epostaServisi;\n\n public SiparisYoneticisi() {\n _epostaServisi = new SmtpEpostaServisi(); \/\/ Do\u011frudan ba\u011f\u0131ml\u0131l\u0131k!\n }\n\n public void SiparisOnayla(int siparisId, string aliciEposta) {\n \/\/ Sipari\u015f onaylama mant\u0131\u011f\u0131...\n _epostaServisi.EpostaGonder(aliciEposta, \"Sipari\u015finiz Onayland\u0131\", $\"Sipari\u015f #{siparisId} ba\u015far\u0131yla onayland\u0131.\");\n }\n}\n <\/code><\/pre>\n<\/div>\nSiparisYoneticisi<\/code> (y\u00fcksek seviyeli mod\u00fcl) do\u011frudan SmtpEpostaServisi<\/code> (d\u00fc\u015f\u00fck seviyeli mod\u00fcl) s\u0131n\u0131f\u0131na ba\u011f\u0131ml\u0131d\u0131r. Bu ba\u011f\u0131ml\u0131l\u0131k, a\u015fa\u011f\u0131daki sorunlara yol a\u00e7ar:<\/p>\n\n
SiparisYoneticisi<\/code> s\u0131n\u0131f\u0131n\u0131 a\u00e7\u0131p de\u011fi\u015ftirmek zorunda kal\u0131rs\u0131n\u0131z. Bu, “A\u00e7\u0131k\/Kapal\u0131 Prensibi”ne (Open\/Closed Principle) ayk\u0131r\u0131d\u0131r; yani, bir s\u0131n\u0131f de\u011fi\u015fikli\u011fe kapal\u0131, geni\u015flemeye a\u00e7\u0131k olmal\u0131d\u0131r.<\/li>\nSiparisYoneticisi<\/code> s\u0131n\u0131f\u0131n\u0131 birim testlerine tabi tutmak istedi\u011finizde, ger\u00e7ek bir SMTP sunucusuna ba\u011f\u0131ml\u0131 kal\u0131rs\u0131n\u0131z. Bu, testlerin yava\u015f \u00e7al\u0131\u015fmas\u0131na, d\u0131\u015f ba\u011f\u0131ml\u0131l\u0131klara ihtiya\u00e7 duymas\u0131na ve hatta test ortam\u0131nda istenmeyen e-postalar g\u00f6nderilmesine neden olabilir. SmtpEpostaServisi<\/code>‘nin davran\u0131\u015f\u0131n\u0131 taklit eden bir “sahte” (mock) nesne kullanamazs\u0131n\u0131z \u00e7\u00fcnk\u00fc do\u011frudan somut s\u0131n\u0131fa ba\u011f\u0131ml\u0131s\u0131n\u0131z.<\/li>\nSmtpEpostaServisi<\/code>, sadece e-posta g\u00f6nderme i\u015fini yaparken, SiparisYoneticisi<\/code> s\u0131n\u0131f\u0131, bu spesifik e-posta g\u00f6nderme mekanizmas\u0131yla s\u0131k\u0131ca ba\u011fl\u0131d\u0131r. Bu, SiparisYoneticisi<\/code>‘nin ba\u015fka bir bildirim mekanizmas\u0131yla (\u00f6rne\u011fin, SMS veya anl\u0131k bildirim) kolayca kullan\u0131lamayaca\u011f\u0131 anlam\u0131na gelir.<\/li>\nSmtpEpostaServisi<\/code>‘nde yap\u0131lan herhangi bir de\u011fi\u015fiklik, SiparisYoneticisi<\/code>‘nin de yeniden derlenmesini ve test edilmesini gerektirebilir. Bu “s\u0131k\u0131 ba\u011f” (tight coupling), bir mod\u00fcldeki hatan\u0131n di\u011fer mod\u00fcllere kolayca yay\u0131lmas\u0131na neden olabilir.<\/li>\n<\/ul>\nDIP Nas\u0131l Uygulan\u0131r? Aray\u00fczler ve Abstraksiyon G\u00fcc\u00fc<\/h3>\n
SiparisYoneticisi<\/code> do\u011frudan SmtpEpostaServisi<\/code>‘ne ba\u011f\u0131ml\u0131yd\u0131. DIP’i uygulamak i\u00e7in ilk ad\u0131m, e-posta g\u00f6nderme i\u015flevini tan\u0131mlayan bir aray\u00fcz olu\u015fturmakt\u0131r. Bu aray\u00fcz, hem y\u00fcksek seviyeli mod\u00fcl\u00fcn (SiparisYoneticisi<\/code>) bekledi\u011fi kontrat\u0131 hem de d\u00fc\u015f\u00fck seviyeli mod\u00fcllerin (farkl\u0131 e-posta servisleri) uymas\u0131 gereken yap\u0131y\u0131 tan\u0131mlar.<\/p>\n\n\/\/ 1. Ad\u0131m: Soyutlama (Aray\u00fcz) Tan\u0131mla\ninterface IEpostaServisi {\n void EpostaGonder(string alici, string konu, string icerik);\n}\n\n\/\/ 2. Ad\u0131m: D\u00fc\u015f\u00fck Seviyeli Mod\u00fcller Soyutlamay\u0131 Uygular\nclass SmtpEpostaServisi : IEpostaServisi {\n public void EpostaGonder(string alici, string konu, string icerik) {\n \/\/ Ger\u00e7ek SMTP sunucusu \u00fczerinden e-posta g\u00f6nderme mant\u0131\u011f\u0131\n Console.WriteLine($\"SMTP ile e-posta g\u00f6nderildi: {alici}, Konu: {konu}\");\n }\n}\n\nclass SendGridEpostaServisi : IEpostaServisi {\n public void EpostaGonder(string alici, string konu, string icerik) {\n \/\/ SendGrid API'si \u00fczerinden e-posta g\u00f6nderme mant\u0131\u011f\u0131\n Console.WriteLine($\"SendGrid ile e-posta g\u00f6nderildi: {alici}, Konu: {konu}\");\n }\n}\n\n\/\/ 3. Ad\u0131m: Y\u00fcksek Seviyeli Mod\u00fcl Soyutlamaya Ba\u011f\u0131ml\u0131 Olur\nclass SiparisYoneticisi {\n private IEpostaServisi _epostaServisi;\n\n \/\/ Ba\u011f\u0131ml\u0131l\u0131\u011f\u0131 enjeksiyon (Dependency Injection) ile al\u0131yoruz\n public SiparisYoneticisi(IEpostaServisi epostaServisi) {\n _epostaServisi = epostaServisi;\n }\n\n public void SiparisOnayla(int siparisId, string aliciEposta) {\n \/\/ Sipari\u015f onaylama mant\u0131\u011f\u0131...\n _epostaServisi.EpostaGonder(aliciEposta, \"Sipari\u015finiz Onayland\u0131\", $\"Sipari\u015f #{siparisId} ba\u015far\u0131yla onayland\u0131.\");\n }\n}\n <\/code><\/pre>\n<\/div>\n\n
IEpostaServisi<\/code> Aray\u00fcz\u00fc:<\/strong> E-posta g\u00f6nderme i\u015flevini soyutlayan bir aray\u00fcz tan\u0131mlad\u0131k. Bu aray\u00fcz, e-posta g\u00f6nderme eyleminin “ne” oldu\u011funu tan\u0131mlar, “nas\u0131l” yap\u0131ld\u0131\u011f\u0131n\u0131 de\u011fil.<\/li>\nSmtpEpostaServisi<\/code> ve SendGridEpostaServisi<\/code> gibi d\u00fc\u015f\u00fck seviyeli mod\u00fcller, art\u0131k bu IEpostaServisi<\/code> aray\u00fcz\u00fcn\u00fc implemente ediyorlar. Bu, her iki s\u0131n\u0131f\u0131n da EpostaGonder<\/code> metodunu kendi i\u00e7 mant\u0131klar\u0131na g\u00f6re sa\u011flamak zorunda oldu\u011fu anlam\u0131na gelir.<\/li>\nSiparisYoneticisi<\/code>‘nin De\u011fi\u015fimi:<\/strong> En kritik de\u011fi\u015fiklik burada. SiparisYoneticisi<\/code> art\u0131k somut bir SmtpEpostaServisi<\/code> nesnesi olu\u015fturmak yerine, yap\u0131c\u0131 metodu (constructor) arac\u0131l\u0131\u011f\u0131yla bir IEpostaServisi<\/code> nesnesi al\u0131yor. Bu tekni\u011fe “Ba\u011f\u0131ml\u0131l\u0131k Enjeksiyonu” (Dependency Injection) denir ve DIP’i uygulaman\u0131n en yayg\u0131n yollar\u0131ndan biridir.<\/li>\n<\/ol>\nSiparisYoneticisi<\/code> art\u0131k belirli bir e-posta g\u00f6nderme mekanizmas\u0131n\u0131n detaylar\u0131ndan tamamen habersizdir. Sadece bir IEpostaServisi<\/code> nesnesi ile \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131 bilir. Bu durum, bize inan\u0131lmaz bir esneklik sa\u011flar. \u00d6rne\u011fin:<\/p>\n\n
IEpostaServisi<\/code> aray\u00fcz\u00fcn\u00fc implemente eden bir s\u0131n\u0131f yazmak ve bunu SiparisYoneticisi<\/code>‘ne enjekte etmektir. SiparisYoneticisi<\/code> s\u0131n\u0131f\u0131n\u0131n kodunu de\u011fi\u015ftirmeye gerek kalmaz.<\/li>\nSiparisYoneticisi<\/code>‘ni test ederken, ger\u00e7ek bir SmtpEpostaServisi<\/code> veya SendGridEpostaServisi<\/code> kullanmak yerine, IEpostaServisi<\/code> aray\u00fcz\u00fcn\u00fc implemente eden sahte (mock) bir nesne olu\u015fturabiliriz. Bu sahte nesne, e-posta g\u00f6nderme metodunun \u00e7a\u011fr\u0131l\u0131p \u00e7a\u011fr\u0131lmad\u0131\u011f\u0131n\u0131 veya do\u011fru parametrelerle \u00e7a\u011fr\u0131l\u0131p \u00e7a\u011fr\u0131lmad\u0131\u011f\u0131n\u0131 kontrol etmemizi sa\u011flar, ger\u00e7ek bir e-posta g\u00f6ndermeden.<\/li>\nSiparisYoneticisi<\/code>, art\u0131k herhangi bir IEpostaServisi<\/code> implementasyonu ile \u00e7al\u0131\u015fabilir. Bu, ayn\u0131 SiparisYoneticisi<\/code> s\u0131n\u0131f\u0131n\u0131n farkl\u0131 projelerde veya farkl\u0131 bildirim mekanizmalar\u0131yla kolayca yeniden kullan\u0131labilece\u011fi anlam\u0131na gelir.<\/li>\n<\/ul>\nBir Vaka Analizi: \u00d6deme Sistemi Entegrasyonu<\/h3>\n
OdemeServisi<\/code> ad\u0131nda bir s\u0131n\u0131f\u0131n\u0131z var ve bu s\u0131n\u0131f, do\u011frudan XBankasiSanalPosu<\/code> s\u0131n\u0131f\u0131n\u0131 kullanarak i\u015flemleri ger\u00e7ekle\u015ftiriyor:<\/p>\n\n\/\/ Geleneksel Yakla\u015f\u0131m: S\u0131k\u0131 Ba\u011fl\u0131l\u0131k\nclass XBankasiSanalPosu {\n public bool OdemeYap(decimal tutar, string kartBilgileri) {\n Console.WriteLine($\"X Bankas\u0131 Sanal Posu ile {tutar} TL \u00f6deme yap\u0131ld\u0131.\");\n \/\/ Ger\u00e7ek \u00f6deme API \u00e7a\u011fr\u0131s\u0131 ve mant\u0131\u011f\u0131\n return true;\n }\n}\n\nclass OdemeServisi {\n private XBankasiSanalPosu _sanalPosu;\n\n public OdemeServisi() {\n _sanalPosu = new XBankasiSanalPosu(); \/\/ Do\u011frudan ba\u011f\u0131ml\u0131l\u0131k\n }\n\n public bool MusteriOdemesiAl(decimal tutar, string kartBilgileri) {\n \/\/ \u0130\u015f mant\u0131\u011f\u0131: sipari\u015f kontrol\u00fc, stok g\u00fcncelleme vb.\n if (_sanalPosu.OdemeYap(tutar, kartBilgileri)) {\n Console.WriteLine(\"\u00d6deme ba\u015far\u0131yla tamamland\u0131.\");\n return true;\n }\n Console.WriteLine(\"\u00d6deme ba\u015far\u0131s\u0131z oldu.\");\n return false;\n }\n}\n <\/code><\/pre>\n<\/div>\n\n
OdemeServisi<\/code> s\u0131n\u0131f\u0131n\u0131 s\u00fcrekli de\u011fi\u015ftirmek zorunda kal\u0131rs\u0131n\u0131z. Her yeni \u00f6deme sa\u011flay\u0131c\u0131s\u0131 i\u00e7in yeni bir if-else<\/code> blo\u011fu eklemek veya mevcut kodu karma\u015f\u0131kla\u015ft\u0131rmak zorunda kal\u0131rs\u0131n\u0131z. Bu, kodun hem bak\u0131m\u0131 zorla\u015f\u0131r hem de yeni hatalara a\u00e7\u0131k hale gelir.<\/p>\n\n\/\/ 1. Ad\u0131m: \u00d6deme Sa\u011flay\u0131c\u0131lar\u0131 i\u00e7in Soyutlama (Aray\u00fcz) Tan\u0131mla\ninterface IOdemeSaglayici {\n bool OdemeYap(decimal tutar, string odemeDetaylari);\n string SaglayiciAdi { get; }\n}\n\n\/\/ 2. Ad\u0131m: D\u00fc\u015f\u00fck Seviyeli Mod\u00fcller Soyutlamay\u0131 Uygular\nclass XBankasiSanalPosu : IOdemeSaglayici {\n public bool OdemeYap(decimal tutar, string odemeDetaylari) {\n Console.WriteLine($\"X Bankas\u0131 Sanal Posu ile {tutar} TL \u00f6deme yap\u0131ld\u0131. Detaylar: {odemeDetaylari}\");\n \/\/ X Bankas\u0131 API \u00e7a\u011fr\u0131s\u0131\n return true;\n }\n public string SaglayiciAdi => \"X Bankas\u0131\";\n}\n\nclass PayPalOdemeSaglayici : IOdemeSaglayici {\n public bool OdemeYap(decimal tutar, string odemeDetaylari) {\n Console.WriteLine($\"PayPal ile {tutar} TL \u00f6deme yap\u0131ld\u0131. Detaylar: {odemeDetaylari}\");\n \/\/ PayPal API \u00e7a\u011fr\u0131s\u0131\n return true;\n }\n public string SaglayiciAdi => \"PayPal\";\n}\n\nclass YBankasiSanalPosu : IOdemeSaglayici {\n public bool OdemeYap(decimal tutar, string odemeDetaylari) {\n Console.WriteLine($\"Y Bankas\u0131 Sanal Posu ile {tutar} TL \u00f6deme yap\u0131ld\u0131. Detaylar: {odemeDetaylari}\");\n \/\/ Y Bankas\u0131 API \u00e7a\u011fr\u0131s\u0131\n return true;\n }\n public string SaglayiciAdi => \"Y Bankas\u0131\";\n}\n\n\/\/ 3. Ad\u0131m: Y\u00fcksek Seviyeli Mod\u00fcl Soyutlamaya Ba\u011f\u0131ml\u0131 Olur\nclass OdemeServisi {\n private readonly IOdemeSaglayici _secilenSaglayici;\n\n public OdemeServisi(IOdemeSaglayici saglayici) {\n _secilenSaglayici = saglayici;\n }\n\n public bool MusteriOdemesiAl(decimal tutar, string odemeDetaylari) {\n Console.WriteLine($\"\u00d6deme i\u015flemi ba\u015flat\u0131l\u0131yor, sa\u011flay\u0131c\u0131: {_secilenSaglayici.SaglayiciAdi}\");\n if (_secilenSaglayici.OdemeYap(tutar, odemeDetaylari)) {\n Console.WriteLine(\"\u00d6deme ba\u015far\u0131yla tamamland\u0131.\");\n return true;\n }\n Console.WriteLine(\"\u00d6deme ba\u015far\u0131s\u0131z oldu.\");\n return false;\n }\n}\n\n\/\/ Uygulama Ba\u015flang\u0131c\u0131 (Composition Root)\nclass Program {\n static void Main(string[] args) {\n \/\/ X Bankas\u0131 ile \u00f6deme\n IOdemeSaglayici xBankasi = new XBankasiSanalPosu();\n OdemeServisi odemeServisiX = new OdemeServisi(xBankasi);\n odemeServisiX.MusteriOdemesiAl(150.75m, \"Kredi Kart\u0131 Detaylar\u0131\");\n\n Console.WriteLine(\"\\n--- Farkl\u0131 bir sa\u011flay\u0131c\u0131 ile \u00f6deme ---\\n\");\n\n \/\/ PayPal ile \u00f6deme\n IOdemeSaglayici payPal = new PayPalOdemeSaglayici();\n OdemeServisi odemeServisiPayPal = new OdemeServisi(payPal);\n odemeServisiPayPal.MusteriOdemesiAl(250.00m, \"PayPal Kullan\u0131c\u0131 Ad\u0131\");\n\n Console.WriteLine(\"\\n--- Test ortam\u0131nda mock sa\u011flay\u0131c\u0131 ile \u00f6deme ---\\n\");\n\n \/\/ Test i\u00e7in sahte (mock) sa\u011flay\u0131c\u0131\n class MockOdemeSaglayici : IOdemeSaglayici {\n public bool OdemeYap(decimal tutar, string odemeDetaylari) {\n Console.WriteLine($\"Mock sa\u011flay\u0131c\u0131 ile {tutar} TL \u00f6deme sim\u00fcle edildi.\");\n return true; \/\/ Her zaman ba\u015far\u0131l\u0131\n }\n public string SaglayiciAdi => \"Mock Test Sa\u011flay\u0131c\u0131\";\n }\n\n IOdemeSaglayici mockSaglayici = new MockOdemeSaglayici();\n OdemeServisi testOdemeServisi = new OdemeServisi(mockSaglayici);\n testOdemeServisi.MusteriOdemesiAl(99.99m, \"Test Kart\");\n }\n}\n <\/code><\/pre>\n<\/div>\n\n
IOdemeSaglayici<\/code> aray\u00fcz\u00fcn\u00fc implemente eden yeni bir s\u0131n\u0131f olu\u015fturmak ve bunu OdemeServisi<\/code>‘ne enjekte etmektir. OdemeServisi<\/code>‘nin i\u00e7 kodunu de\u011fi\u015ftirmeye gerek kalmaz.<\/li>\nOdemeServisi<\/code>‘ni birim testlerine tabi tutarken, ger\u00e7ek \u00f6deme sa\u011flay\u0131c\u0131lar\u0131na ba\u011f\u0131ml\u0131 kalmadan, IOdemeSaglayici<\/code> aray\u00fcz\u00fcn\u00fc taklit eden bir “mock” (sahte) veya “stub” (taslak) nesne kullanabiliriz. Bu, testlerin daha h\u0131zl\u0131, daha g\u00fcvenilir ve d\u0131\u015f ba\u011f\u0131ml\u0131l\u0131klardan ar\u0131nm\u0131\u015f olmas\u0131n\u0131 sa\u011flar. Yukar\u0131daki MockOdemeSaglayici<\/code> \u00f6rne\u011fi, bu durumu net bir \u015fekilde g\u00f6stermektedir.<\/li>\nOdemeServisi<\/code>), \u00f6deme sa\u011flay\u0131c\u0131s\u0131n\u0131n somut detaylar\u0131ndan ayr\u0131lm\u0131\u015ft\u0131r. Bu, \u00f6deme sa\u011flay\u0131c\u0131s\u0131 API’lerinde yap\u0131lan de\u011fi\u015fikliklerin veya yeni entegrasyonlar\u0131n, OdemeServisi<\/code>‘ni etkilememesini sa\u011flar. Sadece ilgili \u00f6deme sa\u011flay\u0131c\u0131s\u0131 s\u0131n\u0131f\u0131 g\u00fcncellenir.<\/li>\nOdemeServisi<\/code> s\u0131n\u0131f\u0131, farkl\u0131 \u00f6deme y\u00f6ntemlerini desteklemek i\u00e7in kolayca yap\u0131land\u0131r\u0131labilir ve farkl\u0131 projelerde kullan\u0131labilir.<\/li>\n<\/ul>\nDIP’in Avantajlar\u0131 Nelerdir?<\/h3>\n
\n
\n
IEpostaServisi<\/code> aray\u00fcz\u00fcn\u00fc kullanan bir BildirimYoneticisi<\/code> s\u0131n\u0131f\u0131, farkl\u0131 projelerde veya ayn\u0131 projenin farkl\u0131 yerlerinde, farkl\u0131 e-posta implementasyonlar\u0131yla kolayca kullan\u0131labilir. Bu, kod tekrar\u0131n\u0131 azalt\u0131r ve geli\u015ftirme verimlili\u011fini art\u0131r\u0131r.<\/p>\n<\/li>\nDIP Uygulamas\u0131nda Dikkat Edilmesi Gerekenler ve \u0130leri Seviye \u0130pu\u00e7lar\u0131<\/h3>\n
\nHer \u015fey i\u00e7in bir aray\u00fcz olu\u015fturmak cazip gelebilir, ancak her zaman gerekli de\u011fildir. A\u015f\u0131r\u0131 soyutlama, kod taban\u0131n\u0131 gereksiz yere karma\u015f\u0131kla\u015ft\u0131rabilir, okunabilirli\u011fi azaltabilir ve geli\u015ftirme h\u0131z\u0131n\u0131 d\u00fc\u015f\u00fcrebilir. Bir aray\u00fcz tan\u0131mlamadan \u00f6nce kendinize \u015fu sorular\u0131 sorun:<\/p>\n\n
\nDIP’i uygulaman\u0131n en yayg\u0131n ve etkili yolu Ba\u011f\u0131ml\u0131l\u0131k Enjeksiyonu kullanmakt\u0131r. DI, bir s\u0131n\u0131f\u0131n ba\u011f\u0131ml\u0131l\u0131klar\u0131n\u0131 kendisinin olu\u015fturmas\u0131 yerine, d\u0131\u015far\u0131dan (genellikle yap\u0131c\u0131 metot arac\u0131l\u0131\u011f\u0131yla) almas\u0131n\u0131 sa\u011flar. Bu, mod\u00fcllerin daha gev\u015fek ba\u011fl\u0131 olmas\u0131n\u0131 ve kolayca taklit edilebilir (mockable) olmas\u0131n\u0131 sa\u011flar. Modern \u00e7er\u00e7eveler (framework) ve k\u00fct\u00fcphaneler (library), genellikle yerle\u015fik DI konteynerleri (container) ile gelir (\u00f6rne\u011fin, .NET Core’daki yerle\u015fik DI, Spring Framework’teki IoC konteyneri). Bu ara\u00e7lar\u0131 kullanarak DI’\u0131 daha kolay y\u00f6netebilirsiniz.<\/p>\n\n\/\/ Ba\u011f\u0131ml\u0131l\u0131k Enjeksiyonu \u00d6rne\u011fi (C#)\npublic class RaporServisi {\n private readonly IVeriDeposu _veriDeposu;\n\n \/\/ Yap\u0131c\u0131 metot (constructor) enjeksiyonu\n public RaporServisi(IVeriDeposu veriDeposu) {\n _veriDeposu = veriDeposu;\n }\n\n public void RaporOlustur() {\n var veriler = _veriDeposu.VeriGetir();\n \/\/ Rapor olu\u015fturma mant\u0131\u011f\u0131\n Console.WriteLine(\"Rapor olu\u015fturuldu.\");\n }\n}\n <\/code><\/pre>\n<\/div>\n
\nE\u011fer uygulaman\u0131zda, hangi somut implementasyonun olu\u015fturulaca\u011f\u0131na karar verilmesi gereken bir nokta varsa, Fabrika Metodu (Factory Method) veya Soyut Fabrika (Abstract Factory) tasar\u0131m desenlerini kullanabilirsiniz. Bu desenler, nesne olu\u015fturma mant\u0131\u011f\u0131n\u0131 soyutlayarak, y\u00fcksek seviyeli mod\u00fcllerin somut s\u0131n\u0131flar\u0131n olu\u015fturulma detaylar\u0131ndan uzak durmas\u0131n\u0131 sa\u011flar. \u00d6rne\u011fin, farkl\u0131 veritaban\u0131 t\u00fcrlerine g\u00f6re farkl\u0131 veri depolar\u0131 olu\u015fturan bir fabrika aray\u00fcz\u00fc tan\u0131mlayabilirsiniz.<\/p>\n
\nDIP’i en etkili \u015fekilde uygulamak i\u00e7in, uygulaman\u0131zdaki “s\u0131n\u0131r endi\u015felerini” (boundary concerns) iyi belirlemeniz gerekir. Yani, hangi katmanlar\u0131n veya mod\u00fcllerin di\u011ferlerinden ba\u011f\u0131ms\u0131z olmas\u0131 gerekti\u011fini anlamak \u00f6nemlidir. Genellikle, i\u015f mant\u0131\u011f\u0131 katman\u0131 (domain layer) ve uygulama katman\u0131 (application layer), altyap\u0131 detaylar\u0131ndan (veritaban\u0131, dosya sistemi, harici servisler) soyutlanmal\u0131d\u0131r. Bu, i\u015f kurallar\u0131n\u0131z\u0131n de\u011fi\u015fime daha diren\u00e7li olmas\u0131n\u0131 sa\u011flar.<\/p>\n
\nDIP’in temel amac\u0131, ba\u011f\u0131ml\u0131l\u0131klar\u0131n y\u00f6n\u00fcn\u00fc tersine \u00e7evirmektir. Yani, y\u00fcksek seviyeli mod\u00fcllerin (politikalar) d\u00fc\u015f\u00fck seviyeli mod\u00fcllere (detaylar) ba\u011f\u0131ml\u0131 olmas\u0131n\u0131 engellemektir. Bunun yerine, her ikisi de bir soyutlamaya ba\u011f\u0131ml\u0131 olmal\u0131d\u0131r. Bu, kod taban\u0131n\u0131zda “oklar\u0131n” her zaman daha soyut olan y\u00f6ne do\u011fru i\u015faret etmesi gerekti\u011fi anlam\u0131na gelir. Bir mod\u00fcl\u00fcn somut bir s\u0131n\u0131fa ba\u011f\u0131ml\u0131 oldu\u011funu g\u00f6rd\u00fc\u011f\u00fcn\u00fczde, bu genellikle bir DIP ihlalidir ve bir aray\u00fcz veya soyut s\u0131n\u0131f arac\u0131l\u0131\u011f\u0131yla bu ba\u011f\u0131ml\u0131l\u0131\u011f\u0131 tersine \u00e7evirmeniz gerekti\u011fini g\u00f6sterir.<\/p>\n
\nEkip i\u00e7inde yap\u0131lan kod incelemelerinde, DIP prensibine uyulup uyulmad\u0131\u011f\u0131n\u0131 kontrol etmek, kod kalitesini art\u0131rman\u0131n \u00f6nemli bir yoludur. Yeni eklenen veya de\u011fi\u015ftirilen kod par\u00e7ac\u0131klar\u0131nda somut ba\u011f\u0131ml\u0131l\u0131klar\u0131n olup olmad\u0131\u011f\u0131n\u0131, aray\u00fczlerin do\u011fru kullan\u0131l\u0131p kullan\u0131lmad\u0131\u011f\u0131n\u0131 sorgulamak, prensibin tutarl\u0131 bir \u015fekilde uygulanmas\u0131n\u0131 sa\u011flar.<\/p>\nSonu\u00e7 ve S\u0131k\u00e7a Sorulan Sorular<\/h3>\n
S\u0131k\u00e7a Sorulan Sorular (SSS)<\/h4>\n
\n