FAQ Category: decorator pattern

Alle Komponenten sollten ein gemeinsames Interface implementieren, das einfache Operationen wie send(), receive() etc. bereitstellt. Jeder Decorator sollte nur dort eingreifen, wo er Funktionalität hinzufügen will, und den Rest delegieren. Ziel: Ein DataStream-Interface mit verschiedenen Dekoratoren: Alle Klassen implementieren die gleiche Schnittstelle, wodurch sie beliebig kombinierbar bleiben. Verwendung

Beispielsweise kann ein UART-Datenstrom durch einen Logging-Dekorator oder einen CRC-Dekorator erweitert werden, ohne den UART-Code selbst zu verändern. So bleibt jede Funktionalität separat testbar und wiederverwendbar.

Wenn es darum geht, Verhalten zusätzlich zu einem bestehenden Verhalten zu schichten, ist das Decorator Pattern sinnvoll. Beim Strategy Pattern geht es um Austauschbarkeit eines bestimmten Verhaltens.

Das Pattern lässt sich auch ohne Betriebssystem einsetzen, solange es keine dynamischen Speicherzugriffe oder Threads benötigt. Die Initialisierung erfolgt meist zur Compile- oder Startup-Zeit, und Funktionsaufrufe bleiben synchron und deterministisch.

Statt dynamischer RTTI (Run-Time Type Information) nutzt man in C++ oft manuell gepflegte Interfaces oder rein virtuelle Klassen. In C verzichtet man ganz darauf und nutzt explizite Strukturfelder oder Tags zur Typdifferenzierung.

Ja, z. B. statische Komposition über Präprozessor-Makros, Compile-Time-Konfigurationen, bedingte Kompilierung oder Templates (in C++). Diese Ansätze vermeiden Laufzeit-Overhead, sind aber weniger flexibel.

RAM-Verbrauch steigt mit jeder Dekorator-Schicht, da zusätzliche Instanzen angelegt werden. ROM-Verbrauch kann durch zusätzliche Funktionszeiger und komplexeren Code steigen. Der Nutzen sollte gegen diese Kosten abgewogen werden.

Nur bedingt. Jede zusätzliche Dekorator-Schicht kann die Latenz erhöhen. In sicherheits- oder zeitkritischen Systemen sollte der Einsatz gut abgewogen werden. In manchen Fällen ist eine statische Lösung vorzuziehen.

Einzeln testet man Dekoratoren, indem man sie mit einem einfachen Mock-Objekt versieht. In Integrationstests prüft man das Verhalten der gesamten Kette. Besonders wichtig ist es, Seiteneffekte und Datenweitergabe zwischen Dekoratoren zu validieren.

Die Decorator-Kette wird von außen nach innen aufgebaut. Jeder Decorator muss die gleiche Schnittstelle implementieren wie das ursprüngliche Objekt. Es empfiehlt sich, den Aufbau der Kette zur Initialisierungszeit klar zu strukturieren, z. B. per Factory-Funktion.

Dekoratoren sollten möglichst leichtgewichtig sein und unnötige Speicher- oder Zeitkomplexität vermeiden. In Embedded-Systemen wird häufig statische Komposition bevorzugt (z. B. durch Makros oder Build-Optionen), um Laufzeit-Overhead zu eliminieren.

Jeder zusätzliche Dekorator erzeugt ein weiteres Objekt im Speicher. Bei mehrfacher Verschachtelung kann dies zu unerwartetem Speicherverbrauch führen. Besonders bei dynamischer Speicherallokation (Heap) muss auf Speicherlecks und Fragmentierung geachtet werden.

Man definiert eine Struktur mit Funktionszeigern als Interface. Jeder „Decorator“ ist eine eigene Struktur, die das Interface implementiert und intern eine Referenz auf das „eingewickelte“ Objekt hält. Funktionen delegieren teilweise oder vollständig an das innere Objekt.

Beispiele sind Datenströme (z. B. UART → Logging → Verschlüsselung → CRC), Protokoll-Stacks oder flexible Treiberarchitekturen. Das Pattern hilft, Wiederverwendbarkeit und Modularität zu fördern, ohne viele spezialisierte Klassen schreiben zu müssen.

In C++ wird das Pattern meist mit Vererbung und Interfaces umgesetzt. In C, das keine Klassen kennt, wird das Pattern oft durch Strukturen mit Funktionszeigern implementiert. Dabei wird ein „Basis-Interface“ als Struct mit Zeigern auf Funktionen modelliert.