In der Spieleentwicklung und bei hochperformanter Grafik wird oft diskutiert, ob klassische objektorientierte Programmierung (OOP) gegenüber reinem Data-Oriented Design (DOD) noch bestehen kann. Während Cache-Lokalität und zusammenhängende Speicherpuffer für moderne GPU-Pipelines entscheidend sind, ist die Object-Oriented Graphics Rendering Engine (OGRE 3D) ein herausragendes Beispiel für richtig umgesetzte OOP.
1. Echte Abstraktion: Low-Level-Grafik-APIs verbergen
Ein Kernziel von OOP ist Abstraktion — ein sauberes, hochstufiges mentales Modell bereitzustellen und komplexe Implementierungsdetails zu verbergen.
OGRE abstrahiert Low-Level-Grafik-APIs, indem das Szenenmanagement vom Rendering auf Treiberebene entkoppelt wird. Mit CppDepend können wir untersuchen, wie konkrete Treiber (wie RenderSystem_GL oder RenderSystem_Direct3D11) mit den OgreMain-Abstraktionen interagieren:
Die architektonische Erkenntnis
Indem konkrete Backends von zentralen abstrakten Verträgen wie RenderSystem, Texture und HardwareVertexBuffer abgeleitet werden, stellt OGRE sicher, dass das Hinzufügen einer neuen Rendering-API (z. B. Vulkan oder WebAssembly/WebGL) keinerlei strukturelle Änderungen an der Anwendungslogik oder am Szenengraphen erfordert.
2. Polymorphie ohne Vererbungsmissbrauch
Ein häufiger Fallstrick in C++-Frameworks ist übermäßige Vererbung — tiefe, fragile Klassenhierarchien oder der Missbrauch von Mehrfachvererbung. OGRE hält eine außergewöhnliche Kohäsion aufrecht, indem es Komposition vor Vererbung bevorzugt und die Hierarchien flach hält.
Mit einer Code-Quest-Abfrage prüfen wir die Vererbungstiefe in der Kernbibliothek:
from t in Types
where t.BaseClasses.Count() > 1
select new { t, NbBaseClasses = t.BaseClasses.Count(), t.DepthOfInheritance }
Was die Daten zeigen
- Flache Vererbungsbäume: die meisten Klassen in OgreMain haben eine Vererbungstiefe (DIT) ≤ 3.
- Kontrollierte Mehrfachvererbung: nur ein winziger Bruchteil der Typen leitet von mehr als einer Basisklasse ab. Mehrfachvererbung ist in OGRE hauptsächlich auf Mixin-Schnittstellen beschränkt (etwa die Ableitung von einer Domänenschnittstelle und einer Listener- oder Factory-Basisklasse).
3. Saubere Instanziierung mit Factory- und Singleton-Mustern
In großen C++-Anwendungen erzeugt unkontrollierte Objektinstanziierung enge Kopplung. OGRE löst dies mit zwei grundlegenden Erzeugungsmustern:
Factory-Muster für die Objekterzeugung
Statt Client-Code konkrete Objekte direkt mit new erzeugen zu lassen, delegiert OGRE die Erstellung an spezialisierte Factory-Klassen (z. B. EntityFactory, SceneManagerFactory).
from m in Methods
where m.DepthOfCreateA("Ogre.Entity") == 1
select m
Ergebnis: Nur EntityFactory instanziiert Entity-Objekte direkt — Speicherverwaltung und Lebenszyklus-Hooks bleiben vollständig gekapselt.
Singleton-Manager für den Systemzustand
OGRE zentralisiert die Subsystemverwaltung über Singletons, die von einem threadsicheren Template ableiten (Ogre::Singleton<T>):
Subsysteme wie MeshManager, TextureManager und MaterialManager erben von diesem einheitlichen Template und bieten Entwicklern einen vorhersehbaren, threadsicheren Zugriff auf Engine-Ressourcen.
4. Das Facade-Muster: Engine-Subsysteme vereinfachen über Ogre::Root
Dutzende spezialisierte Manager, Loader und Render-Targets zu verwalten, kann Client-Anwendungen überfordern. OGRE nutzt das Facade-Muster in seiner Einstiegsklasse: Ogre::Root.
Über die CppDepend-Metrik Efferente Kopplung (EC) — sie misst die Anzahl der Typen, von denen eine Klasse abhängt — sehen wir, dass Ogre::Root eine hohe Kopplung aufweist (EC > 100).
Während hohe Kopplung bei normalen Klassen üblicherweise ein Code Smell ist, ist sie bei einer Facade eine bewusste Designentscheidung. Root orchestriert Initialisierungen, Frame-Listener, Rendering-Schleifen und Manager-Lebenszyklen hinter einer einheitlichen, leicht nutzbaren API.
5. Abstraktheit-vs.-Instabilität-Diagramm
Robert C. Martin hat einen interessanten Artikel über eine Reihe von Metriken geschrieben, mit denen sich die Qualität eines objektorientierten Designs anhand der Abhängigkeiten zwischen seinen Subsystemen messen lässt.
So beschreibt er die Abhängigkeit zwischen Modulen:
Was macht ein Design starr, fragil und schwer wiederverwendbar? Es ist die gegenseitige Abhängigkeit der Subsysteme innerhalb dieses Designs. Ein Design ist starr, wenn es nicht leicht geändert werden kann. Diese Starrheit rührt daher, dass eine einzelne Änderung an stark verflochtener Software eine Kaskade von Änderungen in abhängigen Modulen auslöst. Wenn das Ausmaß dieser Änderungskaskade von den Designern oder Maintainern nicht vorhergesagt werden kann, lassen sich die Auswirkungen der Änderung nicht abschätzen. Damit sind auch die Kosten der Änderung nicht kalkulierbar. Manager, die mit dieser Unvorhersehbarkeit konfrontiert sind, zögern, Änderungen zu genehmigen. So wird das Design starr.
Um dieser Starrheit entgegenzuwirken, führt er Metriken wie afferente Kopplung, efferente Kopplung, Abstraktheit und Instabilität ein.
Afferente Kopplung: die Anzahl der Typen außerhalb dieses Projekts, die von Typen innerhalb dieses Projekts abhängen.
Efferente Kopplung: die Anzahl der Typen außerhalb dieses Projekts, die von Typen dieses Projekts verwendet werden.
Efferente und afferente Kopplung lassen sich auch auf Namespaces und Typen anwenden. Die efferente Kopplung eines bestimmten Typs ist beispielsweise die Anzahl der Typen, von denen er direkt abhängt. Typen mit sehr hohem TypeCe hängen von zu vielen anderen Typen ab. Sie sind komplex und haben in der Regel mehr als eine Verantwortung.
Abstraktheit
Das Verhältnis der Anzahl interner abstrakter Typen (d. h. abstrakte Klassen und Schnittstellen) zur Anzahl interner Typen. Der Wertebereich liegt zwischen 0 und 1, wobei A=0 ein vollständig konkretes Projekt und A=1 ein vollständig abstraktes Projekt bedeutet.
A = Na / NcDabei gilt:
- A = Abstraktheit eines Moduls. Null ist ein vollständig konkretes Modul. Eins ist ein vollständig abstraktes Modul.
- Na = Anzahl der abstrakten Klassen im Modul.
- Nc = Anzahl der konkreten Klassen im Modul.
Instabilität
Das Verhältnis der efferenten Kopplung (Ce) zur Gesamtkopplung. Diese Metrik zeigt die Widerstandsfähigkeit des Projekts gegenüber Änderungen. Der Wertebereich liegt zwischen 0 und 1, wobei I=0 ein vollständig stabiles und I=1 ein vollständig instabiles Projekt bedeutet.
I = Ce / (Ce + Ca)- I steht für den Grad der Instabilität eines Projekts.
- Ca steht für die afferente Kopplung, also eingehende Abhängigkeiten.
- Ce steht für die efferente Kopplung, also ausgehende Abhängigkeiten.
Abstraktheit-vs.-Instabilität-Diagramm und die Zone of Pain
Hier ist das Abstraktheit-vs.-Instabilität-Diagramm des Ogre-Projekts.
Die Idee hinter diesem Diagramm: Je häufiger ein Code-Element in einem Programm verwendet wird, desto abstrakter sollte es sein. Mit anderen Worten: Vermeiden Sie es, sich zu stark auf konkrete Implementierungen zu stützen; verlassen Sie sich stattdessen auf Abstraktionen. Mit einem häufig verwendeten Code-Element meine ich ein Projekt (die Idee gilt aber auch für Pakete und Typen), das von vielen anderen Projekten des Programms genutzt wird.
Es ist keine gute Idee, konkrete Typen zu haben, die in der gesamten Codebasis weit verbreitet sind. Dadurch entstehen Zones of Pain in Ihrem Programm, in denen eine Änderung der Implementierungen potenziell einen großen Teil des Programms betreffen kann. Und Implementierungen entwickeln sich bekanntermaßen häufiger weiter als Abstraktionen.
Die gestrichelte Hauptsequenzlinie im obigen Diagramm zeigt, wie Abstraktheit und Instabilität ausbalanciert sein sollten. Eine stabile Komponente wäre links positioniert. An der Hauptsequenz erkennt man, dass eine solche Komponente sehr abstrakt sein sollte, um nahe der wünschenswerten Linie zu liegen — ist ihr Abstraktionsgrad dagegen gering, liegt sie in einem Bereich, der als „Zone of Pain" bezeichnet wird.
Wie bekämpft man Starrheit beim OOP-Ansatz?
Wie Robert C. Martin in seinem Artikel schreibt, müssen wir abstrakte Klassen und Schnittstellen einsetzen, um unsere Projekte flexibler zu machen und die hohe Kopplung zwischen Code-Elementen zu reduzieren.
Kopplung in OOP kann entstehen durch:
- Vererbung: sie wird beim OOP-Paradigma oft überstrapaziert und macht den Code in vielen Fällen leider starrer. Einige Designmuster helfen, diese Starrheit aufzulösen, etwa das Adapter-Muster, das die durch Vererbung eingeführte Starrheit minimiert.
- Direkte Verwendung einer konkreten Implementierung: auch hier wird der Code starr, weil er schwer zu ändern ist, wenn wir aus irgendeinem Grund eine andere Bibliothek oder ein anderes Framework einsetzen müssen. Wie bei der Vererbung gibt es Designmuster, die die Starrheit minimieren, etwa Bridge oder Proxy.
Beim OOP-Ansatz empfiehlt es sich, die strukturellen GoF-Muster zu beherrschen; sie helfen, die durch Kopplung eingeführte Starrheit zu reduzieren.
Metrik-Heatmap-Analyse: Risikokonzentration auf Methodenebene in OgreMain
Die Treemap visualisiert die Codebasis-Hierarchie innerhalb der Komponente OgreMain, wobei die Rechteckgröße die Codegröße (z. B. Lines of Code) und die Farbcodierung die Metrik-Schwere darstellt (von Blau/Grün für geringes Risiko bis Rot für hohes Risiko, etwa erhöhte zyklomatische Komplexität oder hohe technische Schulden).
Eine zentrale Erkenntnis dieser Visualisierung: Hochrisiko-Metriken sind ausschließlich auf Methodenebene isoliert und deuten nicht auf einen systemweiten architektonischen Verfall ganzer Klassen oder Namespaces hin:
- Hotspots auf Methodenebene: die auffälligen roten Rechtecke in der Treemap entsprechen einzelnen, spezifischen Routinen — etwa
translate,parse,logundvisit. Diese Funktionen sind Komplexitäts-Hotspots und enthalten vermutlich dichten Kontrollfluss (z. B. große switch-Blöcke oder verschachtelte Schleifen). - Gesunde Klassen- und Strukturcontainer: rund um diese Methoden-Hotspots bleiben die übergeordneten Container (Klassen und Namespaces) überwiegend grün und gelb. Die übergeordnete Klassenorganisation und die Modulgrenzen in OgreMain sind also strukturell solide; die Qualitätsengpässe konzentrieren sich in isolierten Member-Funktionen.
- Gezielte Refactoring-Strategie: da die roten Warnflaggen strikt auf Methoden wie
parseundtranslatelokalisiert sind, erfordert die Sanierung kein Redesign von Klassenhierarchien oder Schnittstellen. Das Refactoring kann direkt darauf abzielen, diese spezifischen Funktionen in kleinere Hilfsroutinen mit jeweils einer Verantwortung zu zerlegen.
Zusammenfassung der Metriken: Warum OGRE die Zeit überdauert
Bei der Analyse von OgreMain mit CppDepend bestätigen die übergeordneten Strukturmetriken, was Entwickler seit über zwei Jahrzehnten loben:
- Hohe Kohäsion: niedrige LCOM-Werte (Lack of Cohesion in Methods) in den zentralen Szenenkomponenten zeigen fokussierte Klassen mit jeweils einer Verantwortung.
- Geringe zyklomatische Komplexität: die Methoden sind kurz, fokussiert und leicht testbar — ohne monolithische Dispatch-Schleifen.
- Saubere Modulgrenzen: minimale zirkuläre Header-Abhängigkeiten zwischen den Namespaces.
Fazit
OGRE beweist, dass objektorientierte Programmierung in C++ nicht von Natur aus langsam oder übermäßig komplex ist, wenn architektonische Prinzipien konsequent durchgesetzt werden. Mit modernen Static-Analysis-Werkzeugen wie CppDepend können Teams Engines wie OGRE studieren, um saubere Schnittstellen durchzusetzen, architektonischen Verfall zu verhindern und langlebige C++-Software zu bauen.