Twitter und Facebook-Anbindung
X
Tweet Follow @twitterapi
!!! Anbindung an twitter und facebook öffnen !!!

Wenn Ihnen mein Online-Buch gefällt,
dann bedanken Sie sich doch mit einer kleinen Spende...

34.5 Flyweight

34.5 Flyweight

Das Entwurfsmuster der Fliegengewichte ist etwas schwerer zu erklären, da es kein Grundlegenden Bauplan gibt, sondern von Fall zu Fall anders implementiert wird. Die Grundidee ist, dass man so viele Attribute wie möglich auslagert. Somit bricht es mit dem klassischen objektorientierten Ansatz. Während eine Klasse normalerweise so aufgebaut wird, dass sie weitestgehend autark ist (sie bringt alle Attribute und Methoden mit um sich selbst zu verwalten), werden Fliegengewichte so konzipiert, dass sie nur die Eigenschaften beinhalten, welche sie einzigartig machen. Alle berechenbaren Zustände werden in den Container verlagert, welche sie beinhaltet.

Warum bricht man also mit diesem "alt bewährtem" Konzept? Man entscheidet sich nur dann für dieses Entwurfsmuster, wenn abzusehen ist, dass man Unmengen dieser Objekte benötigt und somit würde jedes Attribut, welches auch berechenbar ist, unnötig Speicher verschwenden. Ein häufiges Anwendungsgebiet ist die 3D Programmierung. Hier gibt es oft tausende bis Millionen von Objekten/Polygonen. Würde man diese in eine große Objekthierarchie zwingen und am besten noch virtuelle Methoden überschreiben, blähen sich solche Objekte schnell auf und irgendwann besitzt man nicht mehr genügend Grafikspeicher, um sie darzustellen. Man beschränkt sie also auf ein Minimum. Beispielsweise werden Methoden zur Darstellung entfernt. Es wird dann eher einen zentralen Renderer geben, welcher sich um das Zeichnen kümmert. Das Ganze geht sogar soweit, dass selbst Positionswerte der Verteces, nicht mehr in den Objekten gehalten wird. Sie besitzen dann lediglich einen Zeiger auf eine große Liste, in welcher alle Vektoren gehalten werden. Selbst Farben und oder Texturen werden ausgelagert und man findet in der Klasse der Körper nur noch Verweise.

Im ersten Moment denk man, dass man damit ein Programm langsamer macht und für spezielle Fälle trifft das auch zu, aber wenn man sich die Programmstruktur im Ganzen betrachtet erkennt man, dass man doch einiges einsparen kann. Zum Beispiel wird das Transformieren eines bestimmten Objektes länger dauern, da es für den Zugriff auf seine Matrix, eine Indirektion benötigt. Möchte man jetzt aber alle Objekte zeichnen, sieht die Sache ganz anders aus. Wenn man beliebig viele Objekte verwalten will, benötigt man definitiv Zeiger auf diese Objekte. Ein Renderer der also tausend Polygone zeichnen will, müsste also tausend Indirektionen vornehmen, um an die Matrizen zu gelangen. Verwaltet man aber diese Matrizen in einer zentralen Liste, benötigt man nur die eine Indirektion auf jene Liste. Hinzu kommt, dass man jetzt viel schonender mit dem Speicher arbeitet, also wesentlich freundlicher mit dem Cache umgeht. Statt also unnötige Informationen wie Name usw. mit in den Cache zu laden, werden nur noch reine Vektoren geholt.

Ein anderer Anwendungsfall wäre z.B. ein Schachspiel. Das Schachbrett besteht aus 64 Feldern. Verwaltet man jene in einer Liste bzw. in einem zweidimensionalen Array, benötigen die Feldklassen keine Angabe mehr über ihre Position, weil sich diese aus der Position in der Liste bzw. im Array, ergeben. Die Schachfigur selbst benötigt auch keine Information mehr über ihre Position, wenn ein Zeiger auf das entsprechende Feld gesetzt wird. So reduziert man also zwei Angaben auf eine.

Sie sehen also, dass es in gewissen Situationen klüger sein kann, sich vom klassischen objektorientierten Ansatz zu lösen, wenn man schonendere Herangehensweisen in Betracht ziehen kann und dies mit bedacht macht. Die ganze Sache hat aber einen Hakten. Indem man immer mehr Informationen aus - bzw. umlagert, wird man immer unflexibler und kann die erstellten Klassen immer weniger wiederverwenden. Dieser Kompromiss wird aber gerade im Computerspielsektor oft eingegangen, zumal man eh die meisten Sachen nicht wiederverwendet (sie unterliegen einfach einem zu großen technischem Wandel, dass man sie eh meist von Grund auf neu konzipieren muss).

Zum Seitenanfang
Zum Inhaltsverzeichnis

© Copyright by Thomas Weiß, 2009 - 2012