Kotlin Multiplatform (KMP) ile tek bir kod taban\u0131ndan birden fazla platforma uygulama geli\u015ftirmek heyecan verici bir vaat sunar. Bu mimarinin temel ta\u015flar\u0131ndan biri olan Kotlin Multiplatform (KMP), JetBrains taraf\u0131ndan geli\u015ftirilen ve geli\u015ftiricilerin Android, iOS, Web (JavaScript), masa\u00fcst\u00fc (JVM) ve hatta g\u00f6m\u00fcl\u00fc sistemler gibi farkl\u0131 platformlarda kod payla\u015fmas\u0131na olanak tan\u0131yan yenilik\u00e7i bir teknolojidir. KMP’nin temel amac\u0131, i\u015f mant\u0131\u011f\u0131, veri modelleri, a\u011f katman\u0131 gibi kritik uygulama bile\u015fenlerini tek bir ortak (common) mod\u00fclde yazarak geli\u015ftirme s\u00fcrecini h\u0131zland\u0131rmak ve tutarl\u0131l\u0131\u011f\u0131 art\u0131rmakt\u0131r. Ancak, her platformun kendine \u00f6zg\u00fc API’leri (uygulama programlama aray\u00fczleri) ve yetenekleri oldu\u011fundan, bu ortak kodun platforma \u00f6zel \u00f6zelliklerle etkile\u015fime girmesi gerekti\u011fi durumlar ortaya \u00e7\u0131kar. \u0130\u015fte tam bu noktada Bu mekanizman\u0131n temel faydas\u0131, platforma \u00f6zg\u00fc kodun ortak koddan izole edilmesini sa\u011flamas\u0131d\u0131r. Bu izolasyon, ortak kodun platformdan ba\u011f\u0131ms\u0131z olarak test edilmesine ve daha temiz bir mimariye sahip olmas\u0131na yard\u0131mc\u0131 olur. Geli\u015ftiriciler, platforma \u00f6zg\u00fc API’leri do\u011frudan ortak kodda \u00e7a\u011f\u0131rmak yerine, Bir \u00f6rnekle a\u00e7\u0131klayal\u0131m. Uygulaman\u0131zda platforma \u00f6zg\u00fc bir loglama (kay\u0131t tutma) mekanizmas\u0131 kullanmak istedi\u011finizi varsayal\u0131m. Ortak kodunuzda bir mesaj\u0131 loglamak i\u00e7in bir fonksiyona ihtiyac\u0131n\u0131z var. Bu durumda \u015eimdi bu beklentiyi platforma \u00f6zg\u00fc mod\u00fcllerde ger\u00e7ekle\u015ftirmemiz gerekiyor:<\/p>\n Bu basit \u00f6rnekte, ortak kod olan Her platforma \u00f6zg\u00fc k\u00fc\u00e7\u00fck bir farkl\u0131l\u0131k i\u00e7in bile bir Ortak kodunuzda \u00e7ok fazla Ger\u00e7ek d\u00fcnya senaryosu olarak, bir e-ticaret uygulamas\u0131n\u0131n KMP ile geli\u015ftirildi\u011fini ve ba\u015flang\u0131\u00e7ta sadece mobil (Android ve iOS) platformlar\u0131 hedefledi\u011fini d\u00fc\u015f\u00fcnelim. Uygulama, platforma \u00f6zg\u00fc olarak bildirim g\u00f6nderme, cihaz\u0131n konumuna eri\u015fme ve kamera kullanma gibi \u00f6zelliklere sahip. Geli\u015ftiriciler, her bir \u00f6zellik i\u00e7in Ba\u011f\u0131ml\u0131l\u0131k enjeksiyonu, KMP projelerinde platforma \u00f6zg\u00fc ba\u011f\u0131ml\u0131l\u0131klar\u0131 y\u00f6netmek i\u00e7in belki de en g\u00fc\u00e7l\u00fc ve esnek yakla\u015f\u0131mlardan biridir. Bu y\u00f6ntemde, ortak mod\u00fcl\u00fcn\u00fczde platforma \u00f6zg\u00fc bir hizmetin veya bile\u015fenin soyut bir tan\u0131m\u0131n\u0131 (aray\u00fcz veya soyut s\u0131n\u0131f) olu\u015fturursunuz. Daha sonra, her platforma \u00f6zg\u00fc mod\u00fclde bu aray\u00fcz\u00fcn somut bir implementasyonunu sa\u011flars\u0131n\u0131z. Ortak kodunuz, bu implementasyonlar\u0131 do\u011frudan \u00e7a\u011f\u0131rmak yerine, bir DI \u00e7er\u00e7evesi (\u00f6rne\u011fin Koin, Dagger\/Hilt’in KMP versiyonlar\u0131 veya basit bir el ile DI \u00e7\u00f6z\u00fcm\u00fc) arac\u0131l\u0131\u011f\u0131yla veya bir fabrika (factory) deseniyle bu ba\u011f\u0131ml\u0131l\u0131klar\u0131 al\u0131r.<\/p>\n DI’nin temel avantaj\u0131, ortak kodunuzun platforma \u00f6zg\u00fc implementasyonlardan tamamen ayr\u0131\u015fmas\u0131n\u0131 sa\u011flamas\u0131d\u0131r. Ortak kod sadece aray\u00fczleri bilir ve implementasyonlar \u00e7al\u0131\u015fma zaman\u0131nda (runtime) sa\u011flan\u0131r. Bu durum, test edilebilirli\u011fi b\u00fcy\u00fck \u00f6l\u00e7\u00fcde art\u0131r\u0131r, \u00e7\u00fcnk\u00fc testler s\u0131ras\u0131nda aray\u00fczlerin sahte (mock) implementasyonlar\u0131n\u0131 kolayca enjekte edebilirsiniz. Ayr\u0131ca, yeni bir platform eklendi\u011finde, sadece yeni platforma \u00f6zg\u00fc mod\u00fclde aray\u00fcz\u00fcn bir implementasyonunu sa\u011flaman\u0131z yeterli olur, ortak kodda herhangi bir de\u011fi\u015fiklik yapman\u0131za gerek kalmaz.<\/p>\n \u00d6nceki loglama \u00f6rne\u011fini DI kullanarak yeniden d\u00fczenleyelim:<\/p>\n \u015eimdi platforma \u00f6zg\u00fc implementasyonlar\u0131 olu\u015ftural\u0131m:<\/p>\n Bu yakla\u015f\u0131m, ortak kodun platforma \u00f6zg\u00fc detaylardan tamamen ba\u011f\u0131ms\u0131z olmas\u0131n\u0131 sa\u011flar. KMP, birden fazla ortak mod\u00fcl (\u00f6rne\u011fin K\u00fc\u00e7\u00fck ve \u00f6nemsiz platform farkl\u0131l\u0131klar\u0131 i\u00e7in Bu alternatif yakla\u015f\u0131mlar, \u00d6nceki b\u00f6l\u00fcmlerde Bu durumlarda, E\u011fer platformlar aras\u0131ndaki fark \u00e7ok k\u00fc\u00e7\u00fck, izole edilmi\u015f ve gelecekte de\u011fi\u015fme olas\u0131l\u0131\u011f\u0131 d\u00fc\u015f\u00fckse, Kotlin ekosistemindeki baz\u0131 k\u00fct\u00fcphaneler ve dil \u00f6zellikleri, zaten dahili olarak Vaka Analizi: Platforma \u00d6zg\u00fc Dosya Kaydetme \u0130\u015flevi<\/strong><\/p>\n Bir uygulaman\u0131n, kullan\u0131c\u0131 taraf\u0131ndan olu\u015fturulan bir raporu PDF format\u0131nda cihaz\u0131n yerel depolama alan\u0131na kaydetmesi gerekti\u011fini varsayal\u0131m. Bu i\u015flevsellik, her platformda farkl\u0131 API’ler gerektirecektir. Android’de Platforma \u00f6zg\u00fc implementasyonlar:<\/p>\n Bu \u00f6rnekte, KMP projelerinin uzun vadede ba\u015far\u0131l\u0131 olmas\u0131 i\u00e7in esnek, bak\u0131m\u0131 kolay ve \u00f6l\u00e7eklenebilir bir mimariye sahip olmas\u0131 kritik \u00f6neme sahiptir. Bu, sadece do\u011fru ara\u00e7lar\u0131 se\u00e7mekle de\u011fil, ayn\u0131 zamanda belirli tasar\u0131m prensiplerini ve en iyi uygulamalar\u0131 benimsemekle de m\u00fcmk\u00fcnd\u00fcr. \u0130\u015fte KMP projelerinizde bu hedeflere ula\u015fman\u0131za yard\u0131mc\u0131 olacak baz\u0131 stratejiler:<\/p>\n KMP projelerinde mod\u00fcler tasar\u0131m, karma\u015f\u0131kl\u0131\u011f\u0131 y\u00f6netmenin temel yollar\u0131ndan biridir. Uygulaman\u0131z\u0131n farkl\u0131 katmanlar\u0131n\u0131 ve i\u015flevselliklerini ayr\u0131 mod\u00fcllere ay\u0131r\u0131n. \u00d6rne\u011fin:<\/p>\n Bu mod\u00fcler yap\u0131, her mod\u00fcl\u00fcn belirli bir sorumlulu\u011fa sahip olmas\u0131n\u0131 sa\u011flar ve de\u011fi\u015fikliklerin etkisini s\u0131n\u0131rlar. Ortak mod\u00fcller, platforma \u00f6zg\u00fc detaylar\u0131 bilmemeli, sadece soyutlamalarla \u00e7al\u0131\u015fmal\u0131d\u0131r. Bu, “Ba\u011f\u0131ml\u0131l\u0131klar\u0131n Tersine \u00c7evrilmesi” (Dependency Inversion Principle) prensibini destekler.<\/p>\n Ortak kodunuzda platforma \u00f6zg\u00fc davran\u0131\u015flar\u0131 soyutlamak i\u00e7in m\u00fcmk\u00fcn oldu\u011funca aray\u00fczler (interfaces) veya soyut s\u0131n\u0131flar kullan\u0131n. Ortak mod\u00fcl sadece bu aray\u00fczleri tan\u0131mlar ve bu aray\u00fczlerin implementasyonlar\u0131 platforma \u00f6zg\u00fc mod\u00fcllerde sa\u011flan\u0131r. Bu yakla\u015f\u0131m, ortak kodunuzun platform detaylar\u0131ndan tamamen ayr\u0131\u015fmas\u0131n\u0131 sa\u011flar ve gelecekteki de\u011fi\u015fikliklere kar\u015f\u0131 daha diren\u00e7li hale getirir. \u00d6rne\u011fin, bir a\u011f istemcisi i\u00e7in Ba\u011f\u0131ml\u0131l\u0131k enjeksiyonu, KMP projelerinde esnekli\u011fi ve test edilebilirli\u011fi art\u0131ran temel bir desendir. Bir DI \u00e7er\u00e7evesi (Koin, Kodein gibi) kullanarak veya manuel olarak basit bir servis bulucu (Service Locator) uygulayarak, platforma \u00f6zg\u00fc implementasyonlar\u0131 ortak mod\u00fcl\u00fcn\u00fcze enjekte edin. Bu, ortak kodunuzun platforma \u00f6zg\u00fc implementasyonlar\u0131 do\u011frudan olu\u015fturmak yerine, d\u0131\u015far\u0131dan almas\u0131n\u0131 sa\u011flar. B\u00f6ylece, testlerde sahte (mock) implementasyonlar enjekte etmek \u00e7ok daha kolay hale gelir ve farkl\u0131 platformlar i\u00e7in farkl\u0131 implementasyonlar sa\u011flamak esnekle\u015fir.<\/p>\n KMP’nin en b\u00fcy\u00fck avantajlar\u0131ndan biri, i\u015f mant\u0131\u011f\u0131n\u0131z\u0131n \u00e7o\u011funu ortak kodda yazabilmeniz ve bu kodu bir kez test ederek t\u00fcm platformlarda g\u00fcvenilirli\u011fini sa\u011flaman\u0131zd\u0131r. Ortak kodunuz i\u00e7in kapsaml\u0131 birim testleri ve entegrasyon testleri yaz\u0131n. Platforma \u00f6zg\u00fc mod\u00fcller i\u00e7in ise, UI testleri ve platforma \u00f6zg\u00fc API entegrasyon testlerine odaklan\u0131n. Ba\u011f\u0131ml\u0131l\u0131k enjeksiyonu kullanarak, ortak kodun testlerini platforma \u00f6zg\u00fc ba\u011f\u0131ml\u0131l\u0131klardan izole edebilirsiniz. Bu, test s\u00fcrecini h\u0131zland\u0131r\u0131r ve hatalar\u0131 erken a\u015famada tespit etmenize yard\u0131mc\u0131 olur.<\/p>\n KMP projelerinde tutarl\u0131l\u0131k, \u00f6zellikle birden fazla geli\u015ftiricinin \u00e7al\u0131\u015ft\u0131\u011f\u0131 ekiplerde hayati \u00f6neme sahiptir. D\u00fczenli kod incelemeleri (code reviews) yaparak, Deneyimli kullan\u0131c\u0131lar i\u00e7in ek ipu\u00e7lar\u0131: B\u00fcy\u00fck KMP projelerinde, mimari desenler (\u00f6rne\u011fin MVI – Model-View-Intent veya MVVM – Model-View-ViewModel) ve \u00e7oklu mod\u00fcl yap\u0131lar\u0131, kodun daha iyi organize edilmesine yard\u0131mc\u0131 olabilir. CI\/CD (S\u00fcrekli Entegrasyon\/S\u00fcrekli Da\u011f\u0131t\u0131m) s\u00fcre\u00e7lerinizi, t\u00fcm platformlar i\u00e7in otomatik testler ve derlemeler i\u00e7erecek \u015fekilde yap\u0131land\u0131r\u0131n. \u00d6zellikle yeni bir platform ekledi\u011finizde veya b\u00fcy\u00fck bir mimari de\u011fi\u015fiklik yapt\u0131\u011f\u0131n\u0131zda, otomatik testler ve derleme pipeline’lar\u0131, potansiyel sorunlar\u0131 erkenden yakalaman\u0131z\u0131 sa\u011flar. Ayr\u0131ca, Kotlin Multiplatform (KMP), tek bir kod taban\u0131ndan birden fazla platforma uygulama geli\u015ftirme vizyonuyla mobil uygulama geli\u015ftirme d\u00fcnyas\u0131nda devrim yaratmaya devam ediyor. Bu mimarinin temel ta\u015f\u0131 olan Unutmay\u0131n ki, do\u011fru arac\u0131 do\u011fru senaryoda kullanmak, ba\u015far\u0131l\u0131 yaz\u0131l\u0131m geli\u015ftirmenin anahtar\u0131d\u0131r. 1. Genel olarak, 2. Her platforma \u00f6zg\u00fc kod i\u00e7in Hay\u0131r, kesinlikle kullanmamal\u0131s\u0131n\u0131z. Bu makalede vurguland\u0131\u011f\u0131 gibi, 3. B\u00fcy\u00fck bir projede Evet, m\u00fcmk\u00fcnd\u00fcr ancak projenin b\u00fcy\u00fckl\u00fc\u011f\u00fcne ve mevcut 4. Hangi KMP k\u00fct\u00fcphaneleri Bir\u00e7ok pop\u00fcler KMP k\u00fct\u00fcphanesi, platforma \u00f6zg\u00fc i\u015flevselli\u011fi soyutlamak i\u00e7in dahili olarak 5. #KotlinMultiplatform #KMP #expectActual #Yaz\u0131l\u0131mMimarisi #Ba\u011f\u0131ml\u0131l\u0131kEnjeksiyonu #\u00c7okluPlatformGeli\u015ftirme #KodPayla\u015f\u0131m\u0131<\/p>\nexpect\/actual<\/code> mekanizmas\u0131, platforma \u00f6zg\u00fc kodlar\u0131 y\u00f6netmek i\u00e7in g\u00fc\u00e7l\u00fc bir \u00e7\u00f6z\u00fcm gibi g\u00f6r\u00fcnse de, her zaman varsay\u0131lan tercih olmamas\u0131 gerekti\u011fini savunuyoruz. Bu makalede, expect\/actual<\/code> yakla\u015f\u0131m\u0131n\u0131n inceliklerini, potansiyel tuzaklar\u0131n\u0131 ve alternatif \u00e7\u00f6z\u00fcm yollar\u0131n\u0131 derinlemesine inceleyece\u011fiz.<\/p>\nKotlin Multiplatform Nedir ve ‘expect\/actual’ Mekanizmas\u0131 Nas\u0131l \u00c7al\u0131\u015f\u0131r?<\/h3>\n
expect\/actual<\/code> mekanizmas\u0131 devreye girer.<\/p>\nexpect\/actual<\/code>, KMP’nin platforma \u00f6zg\u00fc ba\u011f\u0131ml\u0131l\u0131klar\u0131 y\u00f6netmek i\u00e7in sundu\u011fu bir dildir. Ortak mod\u00fclde, bir i\u015flevin, s\u0131n\u0131f\u0131n, aray\u00fcz\u00fcn veya t\u00fcr takma ad\u0131n\u0131n (type alias) belirli bir platformda nas\u0131l davranmas\u0131 gerekti\u011fini “beklersiniz” (expect<\/code> anahtar kelimesiyle tan\u0131mlars\u0131n\u0131z). Bu beklenti, ilgili platforma \u00f6zg\u00fc mod\u00fcllerde “ger\u00e7ekle\u015ftirilir” (actual<\/code> anahtar kelimesiyle implemente edilir). Bu sayede, ortak kodunuz platforma \u00f6zg\u00fc detaylar\u0131 bilmek zorunda kalmadan soyutlamalar \u00fczerinden \u00e7al\u0131\u015fabilir. \u00d6rne\u011fin, bir cihaz\u0131n platform ad\u0131n\u0131 almak istedi\u011finizde, ortak mod\u00fclde sadece bir fonksiyon beklersiniz ve her platform kendi ad\u0131n\u0131 d\u00f6nd\u00fcrecek \u015fekilde bu fonksiyonu implemente eder.<\/p>\nexpect\/actual<\/code> \u00e7iftleri arac\u0131l\u0131\u011f\u0131yla bir soyutlama katman\u0131 olu\u015ftururlar. Bu, \u00f6zellikle dosya sistemi eri\u015fimi, kullan\u0131c\u0131 aray\u00fcz\u00fc (UI) bile\u015fenleri, platforma \u00f6zg\u00fc sens\u00f6r eri\u015fimi veya a\u011f istekleri gibi alanlarda b\u00fcy\u00fck kolayl\u0131k sa\u011flar. Ancak, bu kolayl\u0131\u011f\u0131n her zaman en iyi \u00e7\u00f6z\u00fcm olup olmad\u0131\u011f\u0131n\u0131 sorgulamak, daha s\u00fcrd\u00fcr\u00fclebilir ve esnek KMP uygulamalar\u0131 geli\u015ftirmek i\u00e7in kritik \u00f6neme sahiptir.<\/p>\nexpect\/actual<\/code> nas\u0131l kullan\u0131l\u0131r?<\/p>\n\n\/\/ commonMain\/kotlin\/com\/example\/mylibrary\/PlatformLogger.kt\npackage com.example.mylibrary\n\nexpect fun logMessage(tag: String, message: String)\n\n\/\/ commonMain\/kotlin\/com\/example\/mylibrary\/MyBusinessLogic.kt\npackage com.example.mylibrary\n\nfun doSomeWork() {\n logMessage(\"MyFeature\", \"\u0130\u015flem ba\u015flat\u0131l\u0131yor...\")\n \/\/ ... i\u015f mant\u0131\u011f\u0131 ...\n logMessage(\"MyFeature\", \"\u0130\u015flem tamamland\u0131.\")\n}\n <\/code><\/pre>\n<\/div>\n\n\/\/ androidMain\/kotlin\/com\/example\/mylibrary\/PlatformLoggerActual.kt\npackage com.example.mylibrary\n\nimport android.util.Log\n\nactual fun logMessage(tag: String, message: String) {\n Log.d(tag, message)\n}\n <\/code><\/pre>\n<\/div>\n\n\/\/ iosMain\/kotlin\/com\/example\/mylibrary\/PlatformLoggerActual.kt\npackage com.example.mylibrary\n\nimport platform.Foundation.NSLog\n\nactual fun logMessage(tag: String, message: String) {\n NSLog(\"[%@] %@\", tag, message)\n}\n <\/code><\/pre>\n<\/div>\ndoSomeWork()<\/code> fonksiyonu, hangi platformda \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131 bilmeden logMessage<\/code> fonksiyonunu \u00e7a\u011f\u0131rabilir. Derleme zaman\u0131nda, Kotlin derleyicisi her platform i\u00e7in uygun actual<\/code> implementasyonunu ba\u011flar. Bu, KMP’nin temel g\u00fcc\u00fcn\u00fc ve platformlar aras\u0131 kod payla\u015f\u0131m\u0131n\u0131 nas\u0131l m\u00fcmk\u00fcn k\u0131ld\u0131\u011f\u0131n\u0131 g\u00f6steren g\u00fczel bir \u00f6rnektir. Ancak, bu basitli\u011fin ard\u0131nda yatan potansiyel karma\u015f\u0131kl\u0131klar\u0131 ve “varsay\u0131lan” olarak kullan\u0131lmas\u0131n\u0131n getirebilece\u011fi sorunlar\u0131 anlamak, daha karma\u015f\u0131k projeler i\u00e7in hayati \u00f6nem ta\u015f\u0131r.<\/p>\n‘expect\/actual’ Varsay\u0131lan Tercih Oldu\u011funda Kar\u015f\u0131la\u015f\u0131lan Zorluklar ve Tuzaklar<\/h3>\n
expect\/actual<\/code> mekanizmas\u0131, KMP’nin platformlar aras\u0131 kod payla\u015f\u0131m\u0131n\u0131 kolayla\u015ft\u0131ran g\u00fc\u00e7l\u00fc bir ara\u00e7 olsa da, her platforma \u00f6zg\u00fc ihtiya\u00e7 i\u00e7in otomatik olarak bu yakla\u015f\u0131m\u0131 benimsemek, zamanla projenizin karma\u015f\u0131kl\u0131\u011f\u0131n\u0131 ve bak\u0131m maliyetini art\u0131rabilir. Bu durum, \u00f6zellikle projenin \u00f6l\u00e7e\u011fi b\u00fcy\u00fcd\u00fck\u00e7e veya yeni platformlar desteklenmeye ba\u015fland\u0131k\u00e7a daha belirgin hale gelir. \u0130\u015fte expect\/actual<\/code>‘\u0131n varsay\u0131lan tercih olarak kullan\u0131lmas\u0131n\u0131n getirdi\u011fi ba\u015fl\u0131ca zorluklar ve tuzaklar:<\/p>\nTekrarlayan Kod (Boilerplate) ve Bak\u0131m Y\u00fck\u00fc<\/h4>\n
expect<\/code> bildirimi ve ard\u0131ndan her desteklenen platform i\u00e7in ayr\u0131 bir actual<\/code> implementasyonu yazmak, h\u0131zla ciddi bir tekrarlayan kod (boilerplate) y\u0131\u011f\u0131n\u0131 olu\u015fturabilir. \u00d6rne\u011fin, uygulaman\u0131zda platforma \u00f6zg\u00fc birka\u00e7 farkl\u0131 depolama mekanizmas\u0131, a\u011f konfig\u00fcrasyonu veya sens\u00f6r eri\u015fimi varsa, her biri i\u00e7in ayr\u0131 ayr\u0131 expect\/actual<\/code> \u00e7iftleri olu\u015fturman\u0131z gerekecektir. Bu, kod taban\u0131n\u0131n b\u00fcy\u00fcmesine, okunabilirli\u011finin azalmas\u0131na ve \u00f6zellikle yeni bir platform eklendi\u011finde veya mevcut bir platformda de\u011fi\u015fiklik yap\u0131ld\u0131\u011f\u0131nda bak\u0131m y\u00fck\u00fcn\u00fcn artmas\u0131na neden olur. Her de\u011fi\u015fiklik, t\u00fcm actual<\/code> implementasyonlar\u0131n\u0131 g\u00f6zden ge\u00e7irmeyi gerektirebilir, bu da hata yapma olas\u0131l\u0131\u011f\u0131n\u0131 art\u0131r\u0131r ve geli\u015ftirme h\u0131z\u0131n\u0131 yava\u015flat\u0131r.<\/p>\nS\u0131k\u0131 Ba\u011flant\u0131 (Tight Coupling) ve Esneklik Kayb\u0131<\/h4>\n
expect<\/code> bildirimi kullanmak, ortak mod\u00fcl\u00fcn\u00fcz ile platforma \u00f6zg\u00fc mod\u00fcller aras\u0131nda s\u0131k\u0131 bir ba\u011flant\u0131 (tight coupling) olu\u015fturabilir. Ortak kod, platforma \u00f6zg\u00fc detaylardan tamamen soyutlanm\u0131\u015f gibi g\u00f6r\u00fcnse de, asl\u0131nda her bir expect<\/code> bildirimi, belirli bir actual<\/code> implementasyonunun varl\u0131\u011f\u0131n\u0131 “bekler”. Bu durum, bir platformu kald\u0131rmak veya yeni bir platform eklemek istedi\u011finizde, t\u00fcm expect<\/code> bildirilerini ve bunlar\u0131n ba\u011f\u0131ml\u0131l\u0131klar\u0131n\u0131 g\u00f6zden ge\u00e7irmenizi gerektirir. \u00d6rne\u011fin, uygulaman\u0131z ba\u015flang\u0131\u00e7ta Android ve iOS i\u00e7in tasarlanm\u0131\u015f ve her platform i\u00e7in ayr\u0131 ayr\u0131 expect\/actual<\/code> kullanarak bir dosya indirme y\u00f6neticisi implemente etti\u011finizi d\u00fc\u015f\u00fcn\u00fcn. Sonradan bir web (JavaScript) s\u00fcr\u00fcm\u00fc eklemeye karar verdi\u011finizde, mevcut t\u00fcm expect<\/code> bildirimleri i\u00e7in bir JS actual<\/code> implementasyonu sa\u011flamak zorunda kal\u0131rs\u0131n\u0131z. Bu, projenin mimarisinin esnekli\u011fini azalt\u0131r ve gelecekteki de\u011fi\u015fikliklere kar\u015f\u0131 diren\u00e7li hale getirir.<\/p>\nTest Edilebilirlik Sorunlar\u0131<\/h4>\n
expect\/actual<\/code> mekanizmas\u0131, ortak kodun test edilebilirli\u011fini bir miktar zorla\u015ft\u0131rabilir. Ortak kodunuzdaki bir expect<\/code> fonksiyonunu do\u011frudan test etmek istedi\u011finizde, bu fonksiyonun bir actual<\/code> implementasyonuna sahip olmas\u0131 gerekir. Bu, birim testleri yazarken sahte (mock) veya taklit (fake) implementasyonlar sa\u011flaman\u0131z gerekti\u011fi anlam\u0131na gelir. Her bir test ortam\u0131 (JVM i\u00e7in JUnit, iOS i\u00e7in XCTest vb.) i\u00e7in ayr\u0131 ayr\u0131 sahte actual<\/code> implementasyonlar\u0131 olu\u015fturmak, test kodunun karma\u015f\u0131kl\u0131\u011f\u0131n\u0131 art\u0131r\u0131r ve test s\u00fcrecini uzat\u0131r. Ba\u011f\u0131ml\u0131l\u0131k enjeksiyonu (Dependency Injection – DI) gibi yakla\u015f\u0131mlar, bu t\u00fcr senaryolarda test edilebilirlik a\u00e7\u0131s\u0131ndan daha esnek \u00e7\u00f6z\u00fcmler sunabilir.<\/p>\nAPI Tasar\u0131m\u0131n\u0131n K\u0131s\u0131tlanmas\u0131<\/h4>\n
expect\/actual<\/code> kullan\u0131rken, ortak API’nizi genellikle t\u00fcm platformlar\u0131n destekledi\u011fi “en d\u00fc\u015f\u00fck ortak payda” (lowest common denominator) prensibine g\u00f6re tasarlamak zorunda kal\u0131rs\u0131n\u0131z. Bu, belirli bir platformda bulunan zengin ve g\u00fc\u00e7l\u00fc API’leri veya \u00f6zellikleri kullanamayaca\u011f\u0131n\u0131z anlam\u0131na gelebilir. \u00d6rne\u011fin, iOS’ta \u00e7ok geli\u015fmi\u015f bir animasyon API’si varken, Android’deki kar\u015f\u0131l\u0131\u011f\u0131 daha basitse, expect<\/code> bildirimi her iki platformun da destekledi\u011fi temel animasyon \u00f6zellikleriyle s\u0131n\u0131rl\u0131 kalmak zorunda kal\u0131r. Bu durum, platforma \u00f6zg\u00fc deneyimi (native experience) tam olarak sunma yetene\u011finizi k\u0131s\u0131tlayabilir ve ortak kodunuzun potansiyelini d\u00fc\u015f\u00fcrebilir.<\/p>\nexpect\/actual<\/code> \u00e7iftleri olu\u015fturmu\u015flar. Bir y\u0131l sonra, \u015firket uygulaman\u0131n bir masa\u00fcst\u00fc (Desktop) versiyonunu \u00e7\u0131karmaya karar veriyor. Bu durumda, geli\u015ftiricilerin mevcut t\u00fcm expect<\/code> bildirimleri i\u00e7in masa\u00fcst\u00fc platformunda da actual<\/code> implementasyonlar\u0131 sa\u011flamas\u0131 gerekiyor. Masa\u00fcst\u00fc ortam\u0131nda konum veya kamera eri\u015fimi mobil kadar yayg\u0131n veya ayn\u0131 API’lerle olmayabilir. Bu, ya masa\u00fcst\u00fc i\u00e7in sahte (dummy) implementasyonlar yazmay\u0131 ya da ortak kodda b\u00fcy\u00fck de\u011fi\u015fiklikler yaparak bu \u00f6zelliklerin iste\u011fe ba\u011fl\u0131 hale getirilmesini gerektirecektir. Bu senaryo, expect\/actual<\/code>‘\u0131n varsay\u0131lan olarak her yerde kullan\u0131lmas\u0131n\u0131n uzun vadede ne kadar b\u00fcy\u00fck bir bak\u0131m ve uyumluluk sorunu yaratabilece\u011fini a\u00e7\u0131k\u00e7a g\u00f6stermektedir.<\/p>\n‘expect\/actual’ Yerine Kullan\u0131labilecek Alternatif Yakla\u015f\u0131mlar Nelerdir?<\/h3>\n
expect\/actual<\/code> mekanizmas\u0131 KMP’de belirli durumlar i\u00e7in vazge\u00e7ilmez olsa da, her platforma \u00f6zg\u00fc ihtiya\u00e7 i\u00e7in varsay\u0131lan \u00e7\u00f6z\u00fcm olarak kullan\u0131lmas\u0131, yukar\u0131da bahsedilen zorluklar\u0131 beraberinde getirebilir. Neyse ki, daha esnek, bak\u0131m\u0131 kolay ve test edilebilir KMP uygulamalar\u0131 geli\u015ftirmek i\u00e7in kullanabilece\u011fimiz \u00e7e\u015fitli alternatif yakla\u015f\u0131mlar mevcuttur. Bu alternatifler, \u00f6zellikle i\u015f mant\u0131\u011f\u0131 veya soyutlama seviyesi y\u00fcksek olan durumlar i\u00e7in daha uygun olabilir.<\/p>\nBa\u011f\u0131ml\u0131l\u0131k Enjeksiyonu (Dependency Injection – DI)<\/h4>\n
\n\/\/ commonMain\/kotlin\/com\/example\/mylibrary\/ILogger.kt\npackage com.example.mylibrary\n\n\/\/ Ortak mod\u00fclde soyut bir aray\u00fcz tan\u0131ml\u0131yoruz\ninterface ILogger {\n fun log(tag: String, message: String)\n}\n\n\/\/ commonMain\/kotlin\/com\/example\/mylibrary\/CommonServiceLocator.kt\npackage com.example.mylibrary\n\n\/\/ Basit bir servis bulucu veya DI konteyneri\nobject CommonServiceLocator {\n lateinit var logger: ILogger\n private set \/\/ D\u0131\u015far\u0131dan sadece okunabilir\n\n fun init(platformLogger: ILogger) {\n if (::logger.isInitialized) {\n println(\"Logger zaten ba\u015flat\u0131lm\u0131\u015f!\")\n return\n }\n logger = platformLogger\n }\n}\n\n\/\/ commonMain\/kotlin\/com\/example\/mylibrary\/MyBusinessLogic.kt\npackage com.example.mylibrary\n\nfun doSomeWorkWithDI() {\n \/\/ Ortak kod, logger'\u0131 CommonServiceLocator \u00fczerinden al\u0131r\n CommonServiceLocator.logger.log(\"MyFeatureDI\", \"DI ile i\u015flem ba\u015flat\u0131l\u0131yor...\")\n \/\/ ... i\u015f mant\u0131\u011f\u0131 ...\n CommonServiceLocator.logger.log(\"MyFeatureDI\", \"DI ile i\u015flem tamamland\u0131.\")\n}\n <\/code><\/pre>\n<\/div>\n\n\/\/ androidMain\/kotlin\/com\/example\/mylibrary\/AndroidLogger.kt\npackage com.example.mylibrary\n\nimport android.util.Log\n\n\/\/ Android'e \u00f6zg\u00fc logger implementasyonu\nclass AndroidLogger : ILogger {\n override fun log(tag: String, message: String) {\n Log.d(tag, message)\n }\n}\n\n\/\/ Android uygulamas\u0131n\u0131n ba\u015flang\u0131\u00e7 noktas\u0131nda (\u00f6rne\u011fin Application s\u0131n\u0131f\u0131nda)\n\/\/ CommonServiceLocator.init(AndroidLogger()) \u00e7a\u011fr\u0131l\u0131r.\n <\/code><\/pre>\n<\/div>\n\n\/\/ iosMain\/kotlin\/com\/example\/mylibrary\/IOSLogger.kt\npackage com.example.mylibrary\n\nimport platform.Foundation.NSLog\n\n\/\/ iOS'a \u00f6zg\u00fc logger implementasyonu\nclass IOSLogger : ILogger {\n override fun log(tag: String, message: String) {\n NSLog(\"[%@] %@\", tag, message)\n }\n}\n\n\/\/ iOS uygulamas\u0131n\u0131n ba\u015flang\u0131\u00e7 noktas\u0131nda (\u00f6rne\u011fin AppDelegate'de)\n\/\/ CommonServiceLocator.init(IOSLogger()) \u00e7a\u011fr\u0131l\u0131r.\n <\/code><\/pre>\n<\/div>\nexpect\/actual<\/code>‘da oldu\u011fu gibi derleme zaman\u0131 bir ba\u011flama yerine, \u00e7al\u0131\u015fma zaman\u0131nda bir implementasyon sa\u011flan\u0131r. Bu, \u00f6zellikle b\u00fcy\u00fck ve karma\u015f\u0131k projelerde mod\u00fclerli\u011fi ve esnekli\u011fi art\u0131r\u0131r.<\/p>\nKMP’nin Kendi Mod\u00fcl Yap\u0131s\u0131 ve \u00c7oklu Mod\u00fcller<\/h4>\n
common-core<\/code>, common-data<\/code>, common-ui-shared<\/code>) ve platforma \u00f6zg\u00fc mod\u00fcller (android-app<\/code>, ios-app<\/code>) olu\u015fturarak da platform farkl\u0131l\u0131klar\u0131n\u0131 y\u00f6netme esnekli\u011fi sunar. Ortak mod\u00fcller, genellikle i\u015f mant\u0131\u011f\u0131n\u0131 ve veri modellerini i\u00e7erirken, platforma \u00f6zg\u00fc mod\u00fcller UI veya platform API’leri ile etkile\u015fimden sorumlu olur. Bu yap\u0131, expect\/actual<\/code> kullanmadan da platforma \u00f6zg\u00fc kodun izole edilmesine yard\u0131mc\u0131 olur. \u00d6rne\u011fin, bir platforma \u00f6zg\u00fc veritaban\u0131 eri\u015fimi i\u00e7in, ortak mod\u00fclde sadece bir aray\u00fcz tan\u0131mlay\u0131p, her platformda bu aray\u00fcz\u00fc implemente eden bir depolama mod\u00fcl\u00fc (android-db<\/code>, ios-db<\/code>) olu\u015fturabilirsiniz. Ortak kodunuz, bu depolama mod\u00fcl\u00fcne ba\u011f\u0131ml\u0131l\u0131k enjeksiyonu arac\u0131l\u0131\u011f\u0131yla eri\u015febilir.<\/p>\nYap\u0131land\u0131rma (Configuration) ve \u00d6zellik Bayraklar\u0131 (Feature Flags)<\/h4>\n
expect\/actual<\/code> kullanmak yerine, basit yap\u0131land\u0131rma dosyalar\u0131 veya \u00f6zellik bayraklar\u0131 (feature flags) kullanmak daha pratik olabilir. \u00d6rne\u011fin, bir API’nin temel URL’si platforma g\u00f6re de\u011fi\u015fiyorsa, bunu expect\/actual<\/code> ile yapmak yerine, her platformun kendi build konfig\u00fcrasyonunda (build.gradle.kts<\/code> veya Info.plist<\/code> gibi) tan\u0131mlay\u0131p \u00e7al\u0131\u015fma zaman\u0131nda okuyabilirsiniz. Bu, daha az tekrarlayan kod ve daha az derleme zaman\u0131 ba\u011f\u0131ml\u0131l\u0131\u011f\u0131 anlam\u0131na gelir.<\/p>\nexpect\/actual<\/code>‘\u0131n g\u00fc\u00e7l\u00fc bir ara\u00e7 olmas\u0131na ra\u011fmen, her durumda en iyi \u00e7\u00f6z\u00fcm olmad\u0131\u011f\u0131n\u0131 ve projenin ihtiya\u00e7lar\u0131na g\u00f6re farkl\u0131 stratejilerin benimsenmesi gerekti\u011fini g\u00f6stermektedir. Do\u011fru arac\u0131 do\u011fru senaryoda kullanmak, KMP projelerinizin ba\u015far\u0131s\u0131 i\u00e7in kritik \u00f6neme sahiptir.<\/p>\nNe Zaman ‘expect\/actual’ Kullanmal\u0131y\u0131z? Do\u011fru Kullan\u0131m Senaryolar\u0131<\/h3>\n
expect\/actual<\/code>‘\u0131n varsay\u0131lan tercih olarak kullan\u0131lmas\u0131n\u0131n getirebilece\u011fi zorluklar\u0131 ve alternatif yakla\u015f\u0131mlar\u0131 ele ald\u0131k. Ancak bu, expect\/actual<\/code>‘\u0131n tamamen k\u00f6t\u00fc bir ara\u00e7 oldu\u011fu anlam\u0131na gelmez. Aksine, belirli senaryolarda son derece g\u00fc\u00e7l\u00fc ve hatta vazge\u00e7ilmez bir \u00e7\u00f6z\u00fcm olabilir. \u00d6nemli olan, bu mekanizmay\u0131 ne zaman ve neden kullanaca\u011f\u0131m\u0131z\u0131 do\u011fru bir \u015fekilde anlamakt\u0131r. \u0130\u015fte expect\/actual<\/code>‘\u0131n en uygun oldu\u011fu durumlar ve do\u011fru kullan\u0131m senaryolar\u0131:<\/p>\nGer\u00e7ekten Platforma \u00d6zg\u00fc API’leri Sarmalama \u0130htiyac\u0131 Oldu\u011funda<\/h4>\n
expect\/actual<\/code>‘\u0131n en temel ve do\u011fru kullan\u0131m alan\u0131, ortak kodun do\u011frudan eri\u015femedi\u011fi, platforma \u00f6zg\u00fc temel sistem API’lerini (Application Programming Interface – Uygulama Programlama Aray\u00fcz\u00fc) sarmalamakt\u0131r. Bu t\u00fcr API’ler genellikle i\u015fletim sistemi (OS) seviyesinde i\u015flevsellik sunar ve farkl\u0131 platformlarda tamamen farkl\u0131 implementasyonlara sahiptir. \u00d6rnek olarak:<\/p>\n\n
ktor-client<\/code> gibi k\u00fct\u00fcphaneler bunu soyutlasa da, altta yatan implementasyonlar expect\/actual<\/code> kullan\u0131r).<\/li>\nexpect\/actual<\/code> kullanmak, ortak kodunuzun bu platforma \u00f6zg\u00fc detaylardan soyutlanmas\u0131n\u0131 sa\u011flar ve her platformun kendi en verimli ve g\u00fcvenli yolunu kullanmas\u0131na olanak tan\u0131r. Ortak kodunuz sadece “bir dosya kaydet” der, nas\u0131l kaydedilece\u011fi platformun sorumlulu\u011fundad\u0131r.<\/p>\n\u00c7ok K\u00fc\u00e7\u00fck, \u0130zole Edilmi\u015f ve Nadiren De\u011fi\u015fen Platform Farkl\u0131l\u0131klar\u0131<\/h4>\n
expect\/actual<\/code> basit ve etkili bir \u00e7\u00f6z\u00fcm sunabilir. \u00d6rne\u011fin, bir platforma \u00f6zg\u00fc sabit bir de\u011fer (\u00f6rne\u011fin bir API anahtar\u0131 veya bir yap\u0131land\u0131rma bayra\u011f\u0131) veya \u00e7ok basit bir yard\u0131mc\u0131 fonksiyon (utility function) i\u00e7in kullan\u0131labilir. Bu t\u00fcr senaryolarda, ba\u011f\u0131ml\u0131l\u0131k enjeksiyonu gibi daha karma\u015f\u0131k bir mekanizma kurmak, gereksiz bir m\u00fchendislik y\u00fck\u00fc yaratabilir. expect\/actual<\/code>, bu t\u00fcr basit durumlar i\u00e7in “just enough” (yeterli) soyutlama sa\u011flar.<\/p>\nDerleme Zaman\u0131 (Compile-Time) Garantileri Gerekti\u011finde<\/h4>\n
expect\/actual<\/code>, derleme zaman\u0131 (compile-time) garantileri sa\u011flar. Yani, ortak mod\u00fclde beklenen her \u015feyin, derleme an\u0131nda ilgili platform mod\u00fcllerinde bir implementasyona sahip olmas\u0131 gerekir. E\u011fer bir actual<\/code> implementasyonu eksikse, derleyici hata verir. Bu, \u00f6zellikle kritik sistem bile\u015fenleri veya temel altyap\u0131 kodlar\u0131 i\u00e7in \u00f6nemlidir, \u00e7\u00fcnk\u00fc eksik implementasyonlar\u0131n g\u00f6zden ka\u00e7\u0131r\u0131lmas\u0131n\u0131 engeller ve uygulaman\u0131n \u00e7al\u0131\u015fma zaman\u0131nda beklenmedik hatalarla kar\u015f\u0131la\u015fma riskini azalt\u0131r. Ba\u011f\u0131ml\u0131l\u0131k enjeksiyonu gibi \u00e7al\u0131\u015fma zaman\u0131 (runtime) \u00e7\u00f6z\u00fcmleri, bu t\u00fcr hatalar\u0131 ancak uygulama \u00e7al\u0131\u015ft\u0131r\u0131ld\u0131\u011f\u0131nda veya test edildi\u011finde ortaya \u00e7\u0131karabilir.<\/p>\nKotlin’in Kendisi Taraf\u0131ndan Sa\u011flanan Platforma \u00d6zg\u00fc S\u0131n\u0131flar\u0131\/Fonksiyonlar\u0131 Kullan\u0131rken<\/h4>\n
expect\/actual<\/code> mekanizmas\u0131n\u0131 kullan\u0131r. \u00d6rne\u011fin, kotlinx.coroutines<\/code> k\u00fct\u00fcphanesindeki Dispatchers<\/code> s\u0131n\u0131f\u0131, farkl\u0131 platformlarda i\u015f par\u00e7ac\u0131\u011f\u0131 (thread) y\u00f6netimi i\u00e7in expect\/actual<\/code> kullan\u0131r. Bu t\u00fcr durumlarda, mevcut k\u00fct\u00fcphanelerin mimarisine uyum sa\u011flamak i\u00e7in sizin de expect\/actual<\/code> kullanman\u0131z do\u011fal ve do\u011fru bir yakla\u015f\u0131md\u0131r. Benzer \u015fekilde, platforma \u00f6zg\u00fc bir UUID<\/code> (Evrensel Tekil Tan\u0131mlay\u0131c\u0131) olu\u015fturma fonksiyonu gibi standart k\u00fct\u00fcphane benzeri i\u015flevler i\u00e7in expect\/actual<\/code> iyi bir se\u00e7enektir.<\/p>\nFileOutputStream<\/code> veya Storage Access Framework<\/code> kullan\u0131l\u0131rken, iOS’ta FileManager<\/code> veya DocumentDirectory<\/code> gibi yap\u0131lar kullan\u0131l\u0131r. Bu senaryoda expect\/actual<\/code> kullanmak olduk\u00e7a mant\u0131kl\u0131d\u0131r:<\/p>\n\n\/\/ commonMain\/kotlin\/com\/example\/files\/FileSaver.kt\npackage com.example.files\n\nexpect class PlatformFileSaver {\n fun saveFile(filename: String, content: ByteArray): Boolean\n}\n\n\/\/ commonMain\/kotlin\/com\/example\/reports\/ReportGenerator.kt\npackage com.example.reports\n\nclass ReportGenerator {\n private val fileSaver = PlatformFileSaver() \/\/ expect class'\u0131 burada kullan\u0131r\u0131z\n\n fun generateAndSavePdf(reportData: String, filename: String): Boolean {\n val pdfContent = generatePdf(reportData) \/\/ PDF i\u00e7eri\u011fini olu\u015ftur\n return fileSaver.saveFile(filename, pdfContent)\n }\n\n private fun generatePdf(data: String): ByteArray {\n \/\/ Basit bir \u00f6rnek, ger\u00e7ek PDF \u00fcretimi daha karma\u015f\u0131k olacakt\u0131r\n return \"PDF \u0130\u00e7eri\u011fi: $data\".encodeToByteArray()\n }\n}\n <\/code><\/pre>\n<\/div>\n\n\/\/ androidMain\/kotlin\/com\/example\/files\/PlatformFileSaverActual.kt\npackage com.example.files\n\nimport java.io.File\nimport java.io.FileOutputStream\nimport android.os.Environment\n\nactual class PlatformFileSaver {\n actual fun saveFile(filename: String, content: ByteArray): Boolean {\n return try {\n val documentsDir = Environment.getExternalStoragePublicDirectory(Environment.DIRECTORY_DOWNLOADS)\n val file = File(documentsDir, filename)\n FileOutputStream(file).use { it.write(content) }\n true\n } catch (e: Exception) {\n e.printStackTrace()\n false\n }\n }\n}\n <\/code><\/pre>\n<\/div>\n\n\/\/ iosMain\/kotlin\/com\/example\/files\/PlatformFileSaverActual.kt\npackage com.example.files\n\nimport platform.Foundation.*\n\nactual class PlatformFileSaver {\n actual fun saveFile(filename: String, content: ByteArray): Boolean {\n return try {\n val documentsPath = NSSearchPathForDirectoriesInDomains(\n NSSearchPathDirectory.NSDocumentDirectory,\n NSSearchPathDomainMask.NSUserDomainMask,\n true\n ).first() as String\n val filePath = NSURL.fileURLWithPath(documentsPath).URLByAppendingPathComponent(filename)\n val nsData = content.toNSData()\n nsData.writeToFile(filePath.path!!, atomically = true)\n } catch (e: Exception) {\n println(\"Dosya kaydetme hatas\u0131: ${e.localizedDescription}\")\n false\n }\n }\n\n \/\/ ByteArray'\u0131 NSData'ya d\u00f6n\u00fc\u015ft\u00fcrmek i\u00e7in yard\u0131mc\u0131 fonksiyon\n private fun ByteArray.toNSData(): NSData {\n val data = NSMutableData.dataWithLength(this.size.toULong())\n data?.appendBytes(this.refTo(0), this.size.toULong())\n return data as NSData\n }\n}\n <\/code><\/pre>\n<\/div>\nPlatformFileSaver<\/code> s\u0131n\u0131f\u0131, her platformun kendi dosya sistemi API’lerini kullanarak dosyalar\u0131 kaydetme i\u015flevini soyutlar. Ortak kod (ReportGenerator<\/code>), bu soyutlamay\u0131 kullan\u0131r ve platforma \u00f6zg\u00fc detaylarla ilgilenmez. Bu, expect\/actual<\/code>‘\u0131n en uygun ve verimli kullan\u0131m alanlar\u0131ndan biridir.<\/p>\nKMP Projelerinde Esnek ve Bak\u0131m\u0131 Kolay Bir Yap\u0131 Nas\u0131l Olu\u015fturulur?<\/h3>\n
Mod\u00fcler Tasar\u0131m ve Sorumluluklar\u0131n Ayr\u0131lmas\u0131<\/h4>\n
\n
common-core<\/code>:<\/strong> Temel i\u015f mant\u0131\u011f\u0131, veri modelleri, yard\u0131mc\u0131 fonksiyonlar. Platforma \u00f6zg\u00fc hi\u00e7bir \u015feye ba\u011f\u0131ml\u0131 olmamal\u0131d\u0131r.<\/li>\ncommon-data<\/code>:<\/strong> Veri depolama aray\u00fczleri, API istemcileri i\u00e7in soyutlamalar.<\/li>\ncommon-domain<\/code>:<\/strong> \u0130\u015f kurallar\u0131 ve kullan\u0131m senaryolar\u0131 (use cases).<\/li>\nandroid-app<\/code>, ios-app<\/code>, web-app<\/code>):<\/strong> UI katman\u0131, platforma \u00f6zg\u00fc API implementasyonlar\u0131 ve ba\u011f\u0131ml\u0131l\u0131k enjeksiyonu ayarlar\u0131.<\/li>\n<\/ul>\nAray\u00fcz Odakl\u0131 Geli\u015ftirme (Interface-Oriented Development)<\/h4>\n
common-data<\/code> mod\u00fcl\u00fcnde bir NetworkClient<\/code> aray\u00fcz\u00fc tan\u0131mlay\u0131p, android-data<\/code> ve ios-data<\/code> mod\u00fcllerinde bu aray\u00fcz\u00fcn ktor-client<\/code> veya platforma \u00f6zg\u00fc HTTP k\u00fct\u00fcphaneleriyle implementasyonlar\u0131n\u0131 sa\u011flayabilirsiniz.<\/p>\nBa\u011f\u0131ml\u0131l\u0131k Enjeksiyonu (DI) Prensiplerini Benimsemek<\/h4>\n
Test Stratejileri ve Kapsaml\u0131 Testler<\/h4>\n
Kod \u0130ncelemesi ve Ekip \u0130\u00e7i Standartlar<\/h4>\n
expect\/actual<\/code> kullan\u0131m\u0131n\u0131n do\u011fru senaryolarda yap\u0131ld\u0131\u011f\u0131ndan ve alternatif yakla\u015f\u0131mlar\u0131n gerekti\u011finde tercih edildi\u011finden emin olun. Ekip i\u00e7i kodlama standartlar\u0131 ve mimari prensipler belirlemek, projenin uzun vadede s\u00fcrd\u00fcr\u00fclebilirli\u011fini art\u0131r\u0131r. Hangi durumlarda expect\/actual<\/code>, hangi durumlarda DI veya ba\u015fka bir yakla\u015f\u0131m\u0131n kullan\u0131laca\u011f\u0131na dair net y\u00f6nergeler olu\u015fturmak, geli\u015ftiricilerin do\u011fru kararlar\u0131 vermesine yard\u0131mc\u0131 olacakt\u0131r.<\/p>\nexpect\/actual<\/code> bildirimlerini minimumda tutmak ve bunlar\u0131 genellikle sadece platforma \u00f6zg\u00fc API’leri sarmalayan d\u00fc\u015f\u00fck seviyeli k\u00fct\u00fcphaneler i\u00e7in ay\u0131rmak, genel proje karma\u015f\u0131kl\u0131\u011f\u0131n\u0131 \u00f6nemli \u00f6l\u00e7\u00fcde azaltacakt\u0131r.<\/p>\nSonu\u00e7 ve S\u0131k\u00e7a Sorulan Sorular<\/h3>\n
expect\/actual<\/code> mekanizmas\u0131, platforma \u00f6zg\u00fc kodlar\u0131 y\u00f6netmek i\u00e7in g\u00fc\u00e7l\u00fc ve kullan\u0131\u015fl\u0131 bir ara\u00e7t\u0131r. Ancak, bu makalede detayl\u0131ca ele ald\u0131\u011f\u0131m\u0131z gibi, expect\/actual<\/code> yakla\u015f\u0131m\u0131n\u0131 her platforma \u00f6zg\u00fc ihtiya\u00e7 i\u00e7in varsay\u0131lan tercih olarak kullanmak, uzun vadede projenizin karma\u015f\u0131kl\u0131\u011f\u0131n\u0131, bak\u0131m maliyetini ve esnekli\u011fini olumsuz etkileyebilir.<\/p>\nexpect\/actual<\/code>‘\u0131n g\u00fc\u00e7l\u00fc y\u00f6nleri, \u00f6zellikle ger\u00e7ekten platforma \u00f6zg\u00fc temel sistem API’lerini sarmalama, derleme zaman\u0131 garantileri sa\u011flama ve \u00e7ok k\u00fc\u00e7\u00fck, izole edilmi\u015f farkl\u0131l\u0131klar\u0131 y\u00f6netme durumlar\u0131nda ortaya \u00e7\u0131kar. Ancak, tekrarlayan kod (boilerplate), s\u0131k\u0131 ba\u011flant\u0131 (tight coupling), test edilebilirlik zorluklar\u0131 ve API tasar\u0131m k\u0131s\u0131tlamalar\u0131 gibi potansiyel tuzaklar\u0131 g\u00f6z ard\u0131 etmemek gerekir. Bu zorluklar\u0131n \u00fcstesinden gelmek i\u00e7in ba\u011f\u0131ml\u0131l\u0131k enjeksiyonu (DI), mod\u00fcler tasar\u0131m ve aray\u00fcz odakl\u0131 geli\u015ftirme gibi alternatif yakla\u015f\u0131mlar\u0131 benimsemek, KMP projelerinizin daha s\u00fcrd\u00fcr\u00fclebilir ve \u00f6l\u00e7eklenebilir olmas\u0131n\u0131 sa\u011flayacakt\u0131r.<\/p>\nexpect\/actual<\/code>, KMP ara\u00e7 kutunuzdaki de\u011ferli bir \u00f6\u011fedir, ancak ak\u0131ll\u0131ca ve stratejik olarak kullan\u0131lmas\u0131 gereken bir \u00f6\u011fedir. Projenizin ihtiya\u00e7lar\u0131n\u0131 dikkatlice de\u011ferlendirerek, esnek, bak\u0131m\u0131 kolay ve performansl\u0131 KMP uygulamalar\u0131 in\u015fa edebilirsiniz.<\/p>\nS\u0131k\u00e7a Sorulan Sorular<\/h4>\n
expect\/actual<\/code> performans\u0131 etkiler mi?<\/strong><\/p>\nexpect\/actual<\/code> mekanizmas\u0131n\u0131n kendisi performans\u0131 do\u011frudan ve \u00f6nemli \u00f6l\u00e7\u00fcde etkilemez. Derleme zaman\u0131nda uygun actual<\/code> implementasyonu ba\u011fland\u0131\u011f\u0131 i\u00e7in, \u00e7al\u0131\u015fma zaman\u0131nda ek bir soyutlama katman\u0131 maliyeti olmaz. Performans \u00fczerindeki olas\u0131 etkiler, actual<\/code> implementasyonunun kendisinin verimlili\u011finden kaynaklan\u0131r; yani platforma \u00f6zg\u00fc kodun ne kadar iyi yaz\u0131ld\u0131\u011f\u0131na ba\u011fl\u0131d\u0131r.<\/p>\nexpect\/actual<\/code> kullanmal\u0131 m\u0131y\u0131m?<\/strong><\/p>\nexpect\/actual<\/code>‘\u0131 varsay\u0131lan tercih olarak kullanmak, tekrarlayan kod, s\u0131k\u0131 ba\u011flant\u0131 ve bak\u0131m zorluklar\u0131na yol a\u00e7abilir. Sadece ger\u00e7ekten platforma \u00f6zg\u00fc temel API’leri sarmalaman\u0131z gerekti\u011finde, derleme zaman\u0131 garantileri arad\u0131\u011f\u0131n\u0131zda veya \u00e7ok k\u00fc\u00e7\u00fck, izole edilmi\u015f farkl\u0131l\u0131klar i\u00e7in kullanmal\u0131s\u0131n\u0131z. Di\u011fer durumlarda ba\u011f\u0131ml\u0131l\u0131k enjeksiyonu gibi alternatifleri de\u011ferlendirmek daha iyidir.<\/p>\nexpect\/actual<\/code>‘\u0131 DI’ye d\u00f6n\u00fc\u015ft\u00fcrmek m\u00fcmk\u00fcn m\u00fc?<\/strong><\/p>\nexpect\/actual<\/code> kullan\u0131m\u0131n\u0131n yayg\u0131nl\u0131\u011f\u0131na ba\u011fl\u0131 olarak zaman ve \u00e7aba gerektirebilir. Genellikle, her expect<\/code> bildirimi i\u00e7in ortak mod\u00fclde bir aray\u00fcz tan\u0131mlan\u0131r ve platforma \u00f6zg\u00fc actual<\/code> implementasyonlar\u0131 bu aray\u00fcz\u00fc implemente edecek s\u0131n\u0131flara d\u00f6n\u00fc\u015ft\u00fcr\u00fcl\u00fcr. Daha sonra bu s\u0131n\u0131flar, bir DI \u00e7er\u00e7evesi veya manuel DI kullan\u0131larak enjekte edilir. Bu, kademeli olarak yap\u0131labilir, her bir expect\/actual<\/code> \u00e7ifti ayr\u0131 ayr\u0131 d\u00f6n\u00fc\u015ft\u00fcr\u00fclerek risk minimize edilebilir.<\/p>\nexpect\/actual<\/code> kullan\u0131r?<\/strong><\/p>\nexpect\/actual<\/code> kullan\u0131r. \u00d6rnekler aras\u0131nda kotlinx.coroutines<\/code> (Dispatchers<\/code> i\u00e7in), ktor-client<\/code> (HTTP istemci implementasyonlar\u0131 i\u00e7in), kotlinx.serialization<\/code> (platforma \u00f6zg\u00fc serile\u015ftirme\/deserile\u015ftirme i\u00e7in) ve SQLDelight<\/code> (veritaban\u0131 s\u00fcr\u00fcc\u00fcleri i\u00e7in) bulunmaktad\u0131r. Bu k\u00fct\u00fcphaneler, expect\/actual<\/code>‘\u0131n do\u011fru ve stratejik kullan\u0131m\u0131na iyi \u00f6rnekler te\u015fkil eder.<\/p>\nexpect\/actual<\/code> olmadan KMP’de platforma \u00f6zg\u00fc kod nas\u0131l yaz\u0131l\u0131r?<\/strong><\/p>\nexpect\/actual<\/code> olmadan platforma \u00f6zg\u00fc kod yazman\u0131n temel yolu, ortak mod\u00fclde aray\u00fczler tan\u0131mlamak ve bu aray\u00fczlerin implementasyonlar\u0131n\u0131 platforma \u00f6zg\u00fc mod\u00fcllerde sa\u011flamakt\u0131r. Ortak kod, bu implementasyonlar\u0131 do\u011frudan \u00e7a\u011f\u0131rmak yerine, bir ba\u011f\u0131ml\u0131l\u0131k enjeksiyonu mekanizmas\u0131 (bir DI \u00e7er\u00e7evesi veya basit bir fabrika deseni) arac\u0131l\u0131\u011f\u0131yla al\u0131r. Bu, ortak kodun platforma \u00f6zg\u00fc detaylardan tamamen ayr\u0131\u015fmas\u0131n\u0131 sa\u011flar ve test edilebilirli\u011fi art\u0131r\u0131r. Ayr\u0131ca, platforma \u00f6zg\u00fc build konfig\u00fcrasyonlar\u0131 veya \u00f6zellik bayraklar\u0131 da k\u00fc\u00e7\u00fck farkl\u0131l\u0131klar i\u00e7in kullan\u0131labilir.<\/p>\n