Technical Tutorials

Masaüstü ve sunucu tarafı geliştirmede Spring, Guice veya IoC konteynerleri gibi Bağımlılık Enjeksiyonu (DI) çerçeveleri standart uygulamadır. Bu çerçeveler, nesne grafiği oluşturma karmaşıklığını soyutlayarak kodu modüler ve test edilebilir hale getirir. Ancak, gömülü sistemler ve kenar bilişim alanına adım attığınızda, bu ağır çözümler genellikle dezavantaja dönüşür. Sınırlı RAM'a sahip, sıkı gecikme gereksinimleri olan veya hiç işletim sistemi olmayan sistemlerde yansıma (reflection), dinamik bellek tahsisi ve karmaşık başlatma dizilerinin getirdiği yük kabul edilemez olabilir.

Bu makale, şişkinlik olmadan modülerliği koruyan özel, hafif DI stratejilerinin nasıl tasarlanacağını ele alıyor. Derleme zamanı çözümleme, açık sahiplik ve minimal soyutlamadan yararlanarak, kaynak kısıtlı ortamlarda DI'nin faydalarını elde edebiliriz.

Gömülü Bağlamlarda Standart DI'nin Sorunları

Geleneksel DI konteynerleri, gömülü hedefler için sorunlu olan iki mekanizmaya genellikle dayanır:

Dinamik Bellek Tahsisi: Çoğu konteyner nesneleri yığın (heap) üzerinde tahsis eder. Gömülü sistemlerde yığın parçalanması ve öngörülemezlik önemli risklerdir.
Yansıma ve Meta Veri: Sınıfları etiketler veya arayüzler için taramak, çalışma zamanı denetimi gerektirir; bu, çıplak donanımda (bare-metal) C++'ta imkansızdır veya talimat döngüleri ve bellek açısından son derece maliyetlidir.

Her mikrosaniyenin ve her kilobaytın önemli olduğu kenar cihazları için statik, deterministik ve açık bir DI stratejisine ihtiyacımız var.

Strateji 1: Derleme Zamanı Bağımlılık Enjeksiyonu

C++ gömülü sistemleri için en sağlam çözüm, şablonları (templates) ve derleme zamanı anlık oluşturmayı (instantiation) kullanmaktır. Bu yaklaşım, çalışma zamanı yükünü tamamen ortadan kaldırır. Bağımlılıklar derleme zamanında çözülür, bu da derleyicinin kullanılmayan kodu optimize etmesine ve sıfır dinamik tahsis sağlanmasına olanak tanır.

Basit bir `TelemetrySensor`'un `DataLogger`'a ihtiyaç duyduğunu varsayalım. Çalışma zamanında bir işaretçi enjekte etmek yerine, bağımlılığı bir şablon parametresi üzerinden bağlarız:


template <typename Logger>
class TelemetrySensor {
public:
    void read() {
        double value = readHardware();
        logger.log(value);
    }
private:
    Logger logger;
    double readHardware() { /*...*/ }
};

class FileLogger {
public:
    void log(double val) { /*...*/ }
};

// Anlık oluşturma açık ve statiktir
TelemetrySensor<FileLogger> mySensor;

Bu desen, `Logger` türünün derleme zamanında bilindiğinden emin olur. Nesne grafiği yığın (stack) üzerinde veya statik bellekte oluşturulur, böylece yığın (heap) kullanımı ortadan kalkar. Dezavantajı, esnekliğin azalmasıdır; ikili dosyayı yeniden bağlamadan çalışma zamanında uygulamaları değiştiremezsiniz. Ancak, birçok gömülü senaryoda mimari geliştirme sonrası sabitlendiği için bu ödün kabul edilebilir.

Strateji 2: Statik Kayıt Defteri ile Servis Konumlayıcı (Service Locator)

Bazı düzeyde çalışma zamanı esnekliğine ihtiyaç duyulduğunda (örneğin, test için veya eklentilerin sıcak değiştirilmesi için), yansıma olmadan hafif bir Servis Konumlayıcı (Service Locator) uygulanabilir. Sınıfları taramak yerine, başlangıçta doldurulan statik bir kayıt defteri kullanırız.


class ServiceRegistry {
public:
    template <typename T>
    static void registerService(T* instance) {
        services_[typeid(T).name()] = instance;
    }

    template <typename T>
    static T* getService() {
        auto it = services_.find(typeid(T).name());
        return it != services_.end() ? static_cast<T*>(it->second) : nullptr;
    }

private:
    static std::map<const char*, void*> services_;
};

// Kullanım
// 1. Örnekleri global/statik bellekte oluşturun
static Logger myLogger;
static TelemetrySensor mySensor;

// 2. init() içinde kayıt edin
void init() {
    ServiceRegistry::registerService(&myLogger);
    ServiceRegistry::registerService(&mySensor);
}

// 3. Erişim
Logger* log = ServiceRegistry::getService<Logger>();

Bu, hâlâ bir `std::map` kullanır (daha fazla verimlilik için sabit boyutlu bir diziyle değiştirilebilir), ancak nesnelerin kendilerinin dinamik tahsisinden kaçınır. Kayıt defteri tek bir arıza noktasıdır, bu nedenle dikkatli kullanılmalı ve yalnızca çekirdek, kararlı arayüzler için kullanılmalıdır.

Strateji 3: Fabrika Desenleriyle Oluşturucu Enjeksiyonu

Orta yol çözümleri için, açık oluşturucu enjeksiyonu ve fabrika fonksiyonları temiz ve okunabilir bir yol sunar. Bağımlılıklar açıkça geçirilir ve fabrikalar oluşturma mantığını ele alarak oluşturucuları temiz ve başlatmaya odaklı tutar.


class DataProcessor {
public:
    DataProcessor(ILogger* logger, IConfig* config) 
        : logger_(logger), config_(config) {}
    
    void process() { /*...*/ }

private:
    ILogger* logger_;
    IConfig* config_;
};

// Fabrika bağımlılık grafiğini oluşturur
std::unique_ptr<DataProcessor> createProcessor() {
    auto config = std::make_unique<FileConfig>();
    auto logger = std::make_unique<SyslogLogger>();
    
    // Ham işaretçileri geçirin veya ömür yönetimi karmaşıksa std::shared_ptr kullanın
    return std::make_unique<DataProcessor>(logger.get(), config.get());
}

Bu yaklaşım son derece test edilebilirdir. Tam bir sistem başlatmasına ihtiyaç duymadan birim testlerde sahte (mock) `ILogger` ve `IConfig` uygulamalarını enjekte edebilirsiniz. Ayrıca bağımlılıkları açık hale getirir, bu da kodun okunabilirliğini ve bakımını kolaylaştırır.

Gömülü DI İçin En İyi Uygulamalar

Dinamik Tahsisten Kaçının: Mümkün olan yerlerde DI konteynerleri için `constexpr` dizileri, `std::array` veya statik depolama kullanın.
Sanal Fonksiyonları Azaltın: Performans açısından kritik yollarda sanal dağıtım yerine şablon tabanlı polimorfizmi tercih edin.
Açık Ömür Yönetimi: Bağımlılıkları kimin sahip olduğunu ve kimin yok ettiğini net bir şekilde tanımlayın. `unique_ptr` veya açık kapatma dizileri kullanarak sarkan işaretçilerden kaçının.
Sahtelerle Test Edin: Taklit etmesi (mock) kolay arayüzler tasarlayın. Bir DI stratejisi, test edilebilirliği kadar iyidir.

Sonuç

Bağımlılık Enjeksiyonu, her duruma uyan tek bir çözüm değildir. Gömülü ve kenar sistemlerinde hedef, kolaylıktan öngörülebilirlik ve verimliliğe kayar. Ağır çerçeveleri terk ederek derleme zamanı çözümleme, statik kayıt defterleri ve açık oluşturucu enjeksiyonunu benimseyen geliştiriciler, modüler, test edilebilir ve yüksek performanslı sistemler inşa edebilir. Anahtar nokta, DI stratejisini hedef platformun kısıtlamalarına uydurmak ve mimarinin donanımın hizmetinde olduğunu, tersinin değil, sağlamaktır.