{"id":3343,"date":"2026-01-30T00:00:00","date_gmt":"2026-01-29T23:00:00","guid":{"rendered":"https:\/\/kunden.weissblaumedia.de\/microconsult\/2021\/02\/09\/tb_interface-designs-2\/"},"modified":"2026-02-08T20:01:36","modified_gmt":"2026-02-08T19:01:36","slug":"tb_interface-designs-2","status":"publish","type":"post","link":"https:\/\/www.microconsult.de\/en\/tb_interface-designs-2\/","title":{"rendered":"Interface designs and their implementations \u2013 Part 2: Realization and access"},"content":{"rendered":"

Der Einsatz von Software-Interfaces ist ein elementares Mittel zur Entwicklung von langlebigen und tragf\u00e4higen Software-Architekturen. Deshalb sollten sie so fr\u00fch wie m\u00f6glich in der Architektur etabliert werden, um diese zu stabilisieren. Der Software-Architekt kann so eine schnelle Aufgabenverteilung auf unabh\u00e4ngige Personen, Teams oder Standorte ohne weitere \u201eReibungsverluste\u201c sicherstellen.
\n<\/strong><\/p>\n

Welche Varianten der Architekt beim Interface-Design kennen sollte und wie diese in den Programmiersprachen C und C++ implementierbar sind, verr\u00e4t dieser Beitrag in seinem zweiten Teil – er zeigt Implementierungsans\u00e4tze durch Assoziation, Komposition, Fassade, virtuelle Interfaces, nicht-virtuelle Interfaces, C++ Templates und CRTP<\/a>-Pattern auf.<\/p>\n

<\/p>\n

Konkrete Interface-Implementierungsbeispiele<\/h4>\n

\u00a0\"Grundlage<\/em><\/strong><\/p>\n

Bild 1<\/em>: Grundlage f\u00fcr konkrete Implementierungsbeispiele<\/em><\/p>\n

Das Software-Subsystem Controller enth\u00e4lt eine Klasse cController, die zwei Counter \u2013 einen UpCounter und einen DownCounter – ben\u00f6tigt. Hierf\u00fcr bietet das Software-Subsystem Counter dem Controller das Interface icCounter an, um mit den Countern zu arbeiten.<\/p>\n

\"\u00dcbersicht<\/p>\n

Bild 2<\/em>: \u00dcbersicht Implementierungsans\u00e4tze<\/em><\/p>\n

Der den Implementierungsbeispielen entsprechende Programmcode ist hier bereitgestellt.<\/p>\n

Assoziation ohne Interfaceklasse<\/h4>\n

Aus dem Software-Subsystem Controller greift die Klasse cController \u00fcber zwei Zeiger direkt auf je ein Objekt vom Typ cUpCounter und cDownCounter zu. Dabei ergeben sich zwischen den beiden Software-Subsystemen Controller und Counter zwei Abh\u00e4ngigkeiten (Include-Pfade).<\/p>\n

Hier wurde mit Absicht nicht die Assoziation von cController auf cCounter gezogen, damit keine virtuellen Funktionen bzw. Funktionszeiger notwendig sind, aber zum Preis der st\u00e4rkeren Kopplung.<\/p>\n

\"Assoziation\"<\/p>\n

Bild 3: <\/em>Assoziation<\/em><\/p>\n

Aggregation ohne Interfaceklasse<\/h4>\n

Im Vergleich zu dem vorherigen Assoziationsbeispiel \u00fcbernimmt hier die Klasse cController direkt die Instanziierung der ben\u00f6tigten Objekte vom Typ cUpCounter und cDownCounter. Die Instanziierung erfolgt hier dynamisch auf dem Heap mittels malloc() in C und new() in C++. Damit erreichen wir die Grundidee der Weitergabe (des \u201eAusbaus\u201c) der erzeugten Counter-Objekte bei der Aggregation. Der Einsatz des Heaps in der Embedded-Softwareentwicklung ist in vielen Projekten verboten, da er u.a. mit Risiken der Fragmentierung verbunden und damit nicht vorhersagbar bzw. nicht echtzeitf\u00e4hig ist.<\/p>\n

Wie bei der Anwendung der Assoziation ergeben sich auch bei der Aggregation f\u00fcr dieses Beispiel zwei Abh\u00e4ngigkeiten. Ebenfalls wurde gezielt auf die Anwendung von virtuellen Funktionen \/ Funktionszeiger verzichtet.<\/p>\n

\"Aggregation\"<\/p>\n

Bild 4<\/em>: Aggregation<\/em><\/p>\n

Komposition ohne Interfaceklasse<\/h4>\n

Bei den Varianten mit Assoziation und Aggregation erfolgen die Objektzugriffe jeweils mit Zeigern (optional mit Referenzen). Der komplette Verzicht auf Zeiger f\u00fchr zur Anwendung der Komposition.<\/p>\n

\"Komposition\"<\/p>\n

Bild 5<\/em>: Komposition<\/em><\/p>\n

Hierbei enth\u00e4lt die Klasse cController als Members Objekte der Klassen cUpCounter und cDownCounter. Die Anzahl der Abh\u00e4ngigkeiten bleibt bei zwei, wobei die Kopplung durch die eingebetteten Objekte bei der Komposition gegen\u00fcber der Assoziation und Aggregation verst\u00e4rkt wird.<\/p>\n

Fassade-Pattern<\/h4>\n

Das Fassade-Pattern bietet dem Zugreifer cController das Interface icCounter an, welches bereits Daten und Funktionsimplementierungen enth\u00e4lt.<\/p>\n

Was sich hinter der Fassade icCounter verbirgt, ist f\u00fcr den Zugreifer nicht wissenswert und auch nicht sichtbar.<\/p>\n

Wie bei den vorherigen Beispielen enth\u00e4lt diese Implementierung keine virtuellen Funktionen oder Funktionszeiger. Es ergibt sich nur eine Abh\u00e4ngigkeit (Include-Pfad) und damit eine geringe \/ lose Kopplung. Das Interface (Fassade) enth\u00e4lt ein Z\u00e4hler- und ein Grenzwert-Pr\u00fcfobjekt, die gemeinsam die komplette Funktionalit\u00e4t der Fassade realisieren.<\/p>\n

\"Fassade-Pattern<\/p>\n

Bild 6: Fassade-Pattern \u2013 Interfacerealisierung<\/em><\/p>\n

Interfaceklasse mit rein virtuellen Funktionen<\/h4>\n

Ein klassischer, aus der objektorientierten Welt stammender Interfaceansatz ist die Verwendung von rein virtuellen Funktionen (nur Deklarationen ohne Implementierungen) im Interface. Des Weiteren enth\u00e4lt das Interface icCounter keine Daten.<\/p>\n

Der Zugriff auf das Interface erfolgt im cController durch einen Zeiger \/ eine Referenz vom Typ des Interfaces. Dieser Zeiger \/ diese Referenz muss sp\u00e4ter auf ein Objekt der Interface-realisierenden Klassen zeigen.<\/p>\n

In C gibt es keine virtuellen Funktionen, daher m\u00fcssen dort die Mechanismen des C++ Compilers manuell mit Hilfe von Funktionszeigertabellen nachgebildet werden.<\/p>\n

Was sich hinter dem Interface verbirgt, ist f\u00fcr den Zugreifer cController zun\u00e4chst nicht wissenswert und auch nicht sichtbar. Erst beim Initialisieren der Zeiger \/ Referenzen m\u00fcssen konkrete Objekte von cUpCounter und cDownCounter vorhanden sein.<\/p>\n

\"Virtual<\/p>\n

Bild 7<\/em>: Virtual Interface \u2013 Interfacerealisierung<\/em><\/p>\n

Interfaceklasse mit nicht nur rein virtuellen Funktionen<\/h4>\n

Diese Implementierungsvariante basiert auf dem C++ Idiom Non-Virtual Interface<\/a> (NVI). Bei der Implementierung von rein virtuellen Interfaces ergeben sich im Falle mehrerer Implementierungen typischerweise redundante Programmcode-Anteile.<\/p>\n

Das Idiom Non-Virtual Interface implementiert diesen gemeinsamen Code bereits in der Interface-Funktion. Nur die kleinen varianten Anteile der typspezifischen Implementierung sind im Interface als rein virtuelle Funktionen deklariert (isInRange()) und (count_raw()) und bereits in anderen implementierten Funktionen (count())\u00a0 aufgerufen.<\/p>\n

Nur die beiden typspezifischen virtuellen Funktionen isInRange() und count_raw() sind jeweils in den Klassen cUpCpounter und cDownCounter individuell implementiert.<\/p>\n

\"Non-Virtual<\/p>\n

Bild 8<\/em>: Non-Virtual Interface<\/em><\/p>\n

In den Beispielen mit virtuellen Funktionen in Interfaces oder\/und Klassen f\u00fchrt das Ergebnis auf dem Taget zu einer dynamischen Bindung. Dadurch entstehen verschieden Aufw\u00e4nde, die aber im Vergleich zum Nutzen in dem meisten F\u00e4llen vernachl\u00e4ssigbar sind:<\/p>\n

    \n
  1. Programmspeicher<\/strong> (und Compilezeit)
    \nZur Compilezeit erzeugt die Toolkette zu jeder Klasse, die eine oder mehrere virtuelle Funktionen deklariert oder\/und implementiert, eine VMT (Virtual Method Table). Diese legt der Linker \/ Lokator \u00fcblicherweise in den Programmspeicher. Die VMT enth\u00e4lt die Funktionseinsprung-Adressen zu den klassenspezifischen Funktionsimplementierungen.<\/li>\n
  2. Datenspeicher <\/strong>und Laufzeit
    \n<\/strong>Objekte, instanziiert aus einer Klasse mit virtuellen Funktionen, enthalten als zus\u00e4tzliches, erstes Attribut die Einsprung-Adresse in dessen Klassen-VMT. Dieses Attribut f\u00fcgt der Compiler automatisch hinzu, und der Konstruktor initialisiert es ebenfalls automatisch.<\/li>\n
  3. Laufzeit<\/strong>
    \nBeim Aufruf einer virtuellen Funktion f\u00fcr ein bestimmtes Objekt \u00fcber einen Zeiger oder eine Referenz wird \u00fcber dessen VMT-Einsprung-Adresse die Funktionsadresse aus der VMT gelesen und anschlie\u00dfend zu dieser Funktionsadresse gesprungen (-> eine In-Direktion mehr als beim Aufruf nicht-virtueller Funktionen). Dies ist die Funktionalit\u00e4t der dynamischen Bindung. Sie erlaubt so die Programmierung der dynamischen Polymorphie<\/strong>. Diesen Mechanismus f\u00fchrt die C++ Toolkette automatisch aus. In C ist die dynamische Bindung mit etwas mehr Programmieraufwand manuell nachbildbar.<\/li>\n<\/ol>\n

    Interface als Template-Parameter<\/h4>\n

    Die in den Beispielen mit rein virtuellen Interfaces und nicht rein virtuellen Interfaces beschriebenen Aufw\u00e4nde und die damit verbundenen Risiken lassen sich durch die Anwendung von Template-Klassen eliminieren. Der Preis daf\u00fcr ist der Verzicht auf die dynamische Polymorphie, die in vielen Embedded-Softwaresystemen nicht zwingend erforderlich ist. Es ergibt sich nur eine statische Polymorphie<\/strong>.<\/p>\n

    Der Interface-Zugreifer tcController bekommt als Template-Parameter die Objekt- \/ Interfacetypen CounterA_T und CounterB_T, deren Realisierungen cUpCounter und cDownCounter er adressieren m\u00f6chte. Eine direkte Abh\u00e4ngigkeit im Programmcode zwischen den Software-Subsystemen Controller und Counter gibt es nicht mehr. Die indirekte Abh\u00e4ngigkeit entsteht durch die Template-Typisierung bei der Instanziierung. Die spezifizierten Typen cUpCounter und cDownCounter m\u00fcssen alles bereitstellen, was der Zugreifer tcController aufruft. Ist das nicht der Fall, meldet dies bereits der Compiler als Fehler (kein Laufzeitfehler!).<\/p>\n

    \"Interface<\/p>\n

    Bild 9<\/em>: Interface als Template-Parameter<\/em><\/p>\n

    Das Interface selbst ist bei diesem Interface-Design nicht eindeutig sichtbar und nur indirekt im Zugreifer durch dessen Aufrufe spezifiziert. Diese Problematik verbessert sich durch die Anwendung des Curiously Recurring Template Pattern (CRTP) [3].<\/p>\n

    Curiously Recurring Template Pattern (CRTP)<\/h4>\n

    \"CRT-Pattern\"<\/p>\n

    Bild 10<\/em>: CRT-Pattern<\/em><\/p>\n

    Die Template-Klasse tcCounter bzw. deren Funktionen repr\u00e4sentieren das komplette Interface und sind vom Zugreifer tcController aufrufbar:<\/p>\n

    mobjCounterA.count();
    \nmobjCounterB.count();<\/p>\n

    Die Interface-Funktion count() der Interface-Template-Klasse tcCounter ruft als Delegate \u00fcber den Template-Parameter Realization_T die count() Funktion der realisierenden Klasse tcUpCounter bzw. tcDownCounter auf:<\/p>\n

    template <typename Realization_T>\r\n\r\nvoid tcCounter<Realization_T>::count()\r\n\r\n{\r\n\r\nstatic_cast<\/strong><<\/strong>Realization_T<\/strong>*>(<\/strong>this<\/strong>)->count();<\/strong>\r\n\r\n}<\/pre>\n
    Der Template-Parameter Realization_T wird bereits direkt bei der Vererbung von tcCounter in tcUpCounter und tcDownCounter gesetzt:<\/p>\n
    class cUpCounter<\/strong> \u00a0 final : public tcCounter<\/strong><<\/strong>cUpCounter<\/strong>>
    \n<\/strong>class cDownCounter<\/strong> final : public tcCounter<\/strong><<\/strong>cDownCounter<\/strong>><\/strong><\/p>\n
    Das Setzen eines Template-Parameters mit sich selbst als Klassentyp wird als MixedIn<\/strong> bezeichnet.<\/p>\n
    Res\u00fcmee<\/h4>\n
    Die Entscheidung f\u00fcr das \u201erichtige\u201c Interface-Design ist immer von den geltenden Software-Anforderungen abh\u00e4ngig.<\/p>\n
    Interfaces unterst\u00fctzen positiv die Umsetzung von Software-Qualit\u00e4tsmerkmalen, wie beispielsweise Wiederverwendbarkeit, Portabilit\u00e4t, Austauschbarkeit und Erweiterbarkeit. Interface-Konzepte sind ein geeignetes Mittel zur Erf\u00fcllung von Software-Entwurfsprinzipien, z.B. lose Kopplung, Externalisierung von Abh\u00e4ngigkeiten, Modularisierung und Erreichen einer hohen Koh\u00e4sion.<\/p>\n
    Ein weiterf\u00fchrendes Konzept zu und mit Interfaces sind Ports<\/strong>. Ein Port vereint thematisch null bis unendlich viele bereitgestellte Interfaces und null bis unendlich viele erwartete Interfaces und l\u00e4sst sich mit anderen kompatiblen Ports verbinden.<\/p>\n
    Erfahren Sie in Teil 1<\/a> des Beitrags alles \u00fcber Interface-Konzepte und unterschiedliche Interface-Typen.<\/p>\n
    Holen Sie sich das richtige Wissen dar\u00fcber, welche Varianten Sie beim Interface-Design kennen sollten und wie diese in den Programmiersprachen C und C++ implementierbar sind.
    \n<\/strong><\/p>\n
    MicroConsult bietet Ihnen professionelle Trainings und Coachings<\/a> rund um die Themen Analyse, Design und Architektur<\/a> uvm. an – auch im Live-Online-Format.<\/strong><\/p>\n
    Weiterf\u00fchrende Informationen<\/h3>\n
    Trainings zum Thema – auch im Live-Online-Format:<\/strong><\/p>\n