Tekrarlayan Import Sorunu
Orta büyüklükteki herhangi bir Swift projesinde, neredeyse her dosyanın başında aynı import setini yazıyorsun. Foundation, SwiftUI, OSLog, belki Observation – yeni framework’ler benimsedikçe liste büyüyor. OSLog üzerinden yapılandırılmış loglama’ya geçişle birlikte, kendimi neredeyse her dosyaya alışılagelen isimlerin yanına import OSLog eklerken buldum.
Çözüm, sık ihtiyaç duyduğun her şeyi tek bir import üzerinden yeniden export eden bir wrapper modül.
Wrapper Modülü Kurma
Swift paketinde veya Xcode projesinde yeni bir target oluştur. Benim durumumda adını AppFoundation koydum. Modülün tamamı tek bir dosyadan oluşuyor:
// Sources/AppFoundation/Exports.swift
@_exported import Foundation
@_exported import SwiftUI
@_exported import OSLog
@_exported import Observation@_exported attribute’u, her framework’ten tüm public sembolleri AppFoundation’ı import eden herhangi bir dosyaya erişilebilir yapıyor. Artık uygulamandaki her dosyanın sadece şuna ihtiyacı var:
import AppFoundationPackage.swift dosyanda, target’ın export dosyası dışında kendi kaynak kodu yok. Uygulama target’ın AppFoundation‘a bağımlılık tanımlıyor ve yeniden export edilen tüm framework’ler her yerde kullanılabilir oluyor.
Göz Önünde Bulundurulacak Ödünler
Bu yaklaşımın açık faydaları var: daha az kalıp kod, import bölümlerinde daha az merge çakışması ve yeni framework import’ları eklemek için tek bir yer. Ama ödünler de var.
Birincisi, @_exported alt çizgili bir attribute, yani resmi olarak stabil Swift API’sinin parçası değil. Pratikte yıllardır stabil ve ekosistemde yaygın olarak kullanılıyor, ama resmi bir garanti taşımıyor.
İkincisi, örtük bağımlılıklar bir dosyanın gerçekte ne kullandığını anlamayı zorlaştırabilir. Her dosyanın her şeye erişimi olduğunda, açık import’ların dokümantasyon değerini kaybediyorsun. Daha sonra bir modülü bağımsız bir pakete çıkarırsan, açık import’ları geri eklemen gerekecek.
Kolaylığın katı modülerlikten daha önemli olduğu uygulama target’ları için, wrapper modül kalıbı gerçek zaman kazandırıyor. Yeniden kullanılabilir kütüphaneler için ise açık import’lar daha iyi bir seçim olmaya devam ediyor.
