FAQ Category: DI Pattern

Typische Design Patterns, die sich gut mit dem DI Pattern kombinieren lassen: Beispiel: Factory Pattern für Logger

Für klassische Embedded-Systeme ohne Betriebssystem gibt es kaum vollständige Dependency Injection Frameworks. In C++ gibt es leichte Lösungen wie „Boost.DI“ oder „fruit“, die aber meist nicht für ressourcenbeschränkte Systeme optimiert sind. Daher wird das DI Pattern in Embedded-Projekten fast immer manuell implementiert, was auch maximale Kontrolle über Speicher und Laufzeit ermöglicht.

Durch das DI Pattern lassen sich echte Hardwareabhängigkeiten durch Mock-Objekte ersetzen. Beispielsweise kann ein SPI-Treiber durch eine simulierte Testimplementierung ersetzt werden, ohne dass sich der Anwendungscode ändert. Das reduziert den Aufwand für Unit-Tests erheblich und ermöglicht echtes Test-Driven Development (TDD) in Embedded-Projekten.

Um das DI Pattern in bestehende Embedded-Software einzuführen, empfiehlt sich ein schrittweises Vorgehen: Zuerst sollte die Codebasis refaktorisiert werden, um Interfaces oder Abstraktionen für Hardwarekomponenten einzuführen. Danach werden Abhängigkeiten anstatt intern erzeugt, von außen übergeben – zunächst manuell, später eventuell mithilfe von statisch konfigurierten Containern.

Alternativen zum DI Pattern sind Service Locator, Singleton oder einfache globale Strukturen. Diese sind jedoch oft weniger testbar und führen zu starker Kopplung. Das DI Pattern bietet eine saubere, modulare Alternative, ist aber in Embedded-Systemen mit statischer Konfiguration besonders effizient umzusetzen.

In Clean Architecture wird das DI Pattern verwendet, um die Abhängigkeit von Frameworks und Treibern zu minimieren. Die Business-Logik bleibt unabhängig von Details wie I/O oder Kommunikation. In Embedded-Systemen bedeutet das, dass beispielsweise ein Sensormodul nur ein Interface verwendet, während die konkrete Implementierung – etwa via I2C – injiziert wird.

Richtig angewendet verursacht das DI Pattern keine signifikanten Overheads. In statisch konfigurierten Embedded-Systemen kann DI ohne dynamische Speicherallokation implementiert werden. Entscheidend ist die sparsame Verwendung von virtuellen Funktionen oder Pointern. Bei geschickter Implementierung profitiert die Wartbarkeit und Testbarkeit deutlich, ohne die Laufzeitleistung zu beeinträchtigen.

C++ erlaubt eleganteres DI durch Vererbung und Polymorphie. Beispiel: Interface für ein Logger-Modul Implementierung für UART Anwendung via Konstruktor-Injektion In main.cpp Vorteil: Der Logger kann zur Testzeit durch eine Mock- oder RAM-basierte Implementierung ersetzt werden.

Das DI Pattern ermöglicht lose Kopplung zwischen Modulen, wodurch der Quellcode modularer und leichter testbar wird. Besonders bei Unit-Tests lässt sich Hardwarecode leichter mocken oder simulieren. Zudem unterstützt DI eine klarere Trennung von Anwendungscode und Plattformcode (z. B. HAL oder Treiber), was die Wartbarkeit verbessert.

In C wird das DI Pattern häufig manuell umgesetzt, z. B. durch das Übergeben von Funktionszeigern oder strukturierten Interfaces. In C++ kann das DI Pattern über abstrakte Basisklassen (Interfaces) und Konstruktorinjektion realisiert werden. Dabei werden konkrete Implementierungen von außen in Komponenten eingespeist, anstatt sie intern zu erstellen.