Objektpersistenz und ERZEUGER-Pattern
Bemerkungen zum Speichermanagement:
- Fabrik muß den Speicher des assoziierten Objektes bei CollectGeoObj
nicht sofort freigeben
- oft erfolgt hier eigenes Speichermanagement
-
- explizite Aufruf des Destruktors und
Einordnung des Speicherblockes in einen geeigneten Container mit schnellem
Zugriff auf die Speicherblöcke anhand der assoziierten Größe
- Warum?
- konkrete Fabrik ist für das Erzeugen einer ganz bestimmten
Produktpalette (GeoObjs) zuständig
- Anzahl der verschiedenen Größen der von dieser dynamisch anzufordernden Speicherblöcke wird weitestgehend der Anzahl
der konkreten Produkttypen entsprechen
- es kann wesentlich effizienter für eine konkrete Fabrik sein, beim
Erzeugen eines neuen Objektes für die Allokation dessen
Speicherbereiches anhand dessen Größe eine Wiederbenutzung eines alten Speicherblockes zu versuchen
-
- kein Überschreiben der globalen Operatoren new
und delete, sondern Verwendung klassenlokaler Operatoren; evtl.
Ansatz mit placement new
-
- tritt das Programm ein in eine Low-Memory-Situation,
soll die Fabrik angewiesen werden, alle überflüssigen Speicherblöcke
zu löschen; auch sollte es einen Grenzwert für die Gesamtgröße der
akkumulierten Speicherblöcke geben