Ich schreibe einen Message-Handling-Code, wobei jede Nachricht eine POD-Struktur ist. Auf dem Wege des Schreibens würde dies eine abstrakte Basisklasse definieren, mit virtuellen Funktionen für jeden Nachrichtentyp, zum Beispiel:
%Vor%Und dann erstellen Sie abgeleitete konkrete Klassen, die die Handler-Funktionen implementieren:
%Vor% Wenn neue Nachrichten zum System hinzugefügt werden, muss AbstractHandler zusammen mit allen abgeleiteten Typen aktualisiert werden.
Alternativ könnte ich alle unterstützten Nachrichtentypen in einer mpl Sequenz halten und mpl::inherit_linearly verwenden, um die abstrakte Basisklasse zu generieren.
(Hinweis: Ich verwende bereits einen mpl::vector der Nachrichtentypen an anderer Stelle im Code.)
z.B.:
%Vor% Konkrete Handler werden dann von AbstractHandler abgeleitet. Dies bedeutet, dass immer, wenn neue Nachrichtentypen zum System hinzugefügt werden, einfach die mpl::vector< types... > message_types -Sequenz geändert wird, indem neue handleMessage -Funktionen zu abgeleiteten Klassen hinzugefügt werden.
Meiner Meinung nach reduziert dies die Langzeitwartung, da der AbstractHandler automatisch reine virtuelle Funktionen für alle Nachrichten in mpl::vector message_types
In Bezug auf die Leistung gibt es irgendwelche Nachteile bei der Verwendung dieses Ansatzes?
Was sind die Auswirkungen der Verwendung von mpl::inherit_linearly zum Generieren abstrakter Basisklassen?
Ich habe vorher ähnlichen Code gemacht (und ich mache es heute wieder).
Es gibt keine anderen Kosten als die erblichen Kosten. Hauptsächlich weil der endgültige Typ zur Kompilierzeit bestimmt wird, nicht zur Laufzeit.
Dies kann jedoch Ihre Übersetzungszeit im Vergleich zur Listengröße der Nachrichtentype natürlich verlängern. Wenn Sie wie ich auch eine Message-Dispatcher-Klasse schreiben (die alles an einen beliebigen Handler für diesen Typ schicken kann), dann kann es beim Kompilieren teuer werden.
Ansonsten ist es gut.
Verstehen Sie einfach die Implikation dieser Art von Setup: Die Liste der behandelten Nachrichten wird zur Kompilierzeit und nicht zur Laufzeit definiert. Einige Ereignissysteme sind aufgrund der Nutzungsvoraussetzungen Laufzeit. Stellen Sie also sicher, dass es in Ihren Anwendungsfällen so ist.