Referenz Verwaltung

[shmia]

Zitat von NamenLozer:

Eigentlich hat das nichts mit globalen Variablen zu tun.
Es kann einfach sein, dass man das selbe Objekt an zwei verschiedenen Stellen verwendet, wobei es von der einen Stelle freigegeben wird.

Genau hier liegt der Hase im Pfeffer!
Der Entwickler muss eben genau die Lebenzeiten seiner Objekte unter Kontrolle halten.
Wenn man sich die Lebenszeit eines Objekts als Rechteck vorstellt, dann besteht die Kunst darin, die Rechtecke so ineinander zu schachteln, dass sich die Grenzen nicht überschneiden.
Wenn es ein Objekt A gibt, dass von Objekt B und C benützt wird, dann wird einfach ein Objekt D benötigt, dass alle 3 Objekte in der richtigen Reihenfolge erzeugt und zerstört.
Und Probleme entstehen auch dadurch, dass häufig nicht erkannt wird, dass dieses Objekt D benötigt wird.
Und wenn Objekt A von B und C benötigt wird, dann wird A eben vor B und C erzeugt und nach B und C zerstört.

Globale Objekte stören diese Ordnung, da sie potentiell länger leben können als das Hauptformular.

[Bummi]

ich hatte bereits vor einiger Zeit in einem Thread von stahli (der sich seit längerem intensiv mit diesem Thema auseinanderzusetzen scheint) vorgeschlagen eine weitere Dereferenzierung vorzunehmen. Die "Zeiger" also global zu halten und nur noch Zeiger auf die "Zeiger" zu übergeben. Bei dieser Vorgehensweise müsste IMHO bei korrekter Implementierung alles wie gewünscht funktionieren.

[Namenloser]

@shmia: Nicht jede Anwendung ist eine Formularanwendung.

Ich stelle mir jetzt mal beispielhaft ein Spiel vor: Es geht um Raketen und Raketenabwehrsysteme, jede Rakete ist ein Objekt. Wenn ein Raketenabwehrsystem eine feindliche Rakete detektiert, schickt es eine Abwehrrakete los, die die Rakete verfolgt. Dazu wird der Abwehrrakete bei Erstellung eine Referenz auf die feindliche Rakete gegeben.

Die Abwehrrakete liest nun bei jedem Bewegungsschritt die Position der feindlichen Rakete aus und passt entsprechend ihre Flugrichtung an. Wenn die Abwehrrakete mit der feindichen Rakete kollidiert, explodieren beide und die Objekte werden freigegeben.

Soweit so gut – aber was, wenn es ein zweites Raketenabwehrsystem gibt, das ebenfalls eine Abwehrrakete auf das gleiche Ziel losgeschickt hat? Dann befindet sich die Rakete des 2. Abwehrsystems noch in der Luft, während die feindliche Rakete explodiert – und verfolgt forthin ein Objekt, das gar nich mehr existiert.

[Sir Rufo]

Zitat von NamenLozer:

Soweit so gut – aber was, wenn es ein zweites Raketenabwehrsystem gibt, das ebenfalls eine Abwehrrakete auf das gleiche Ziel losgeschickt hat? Dann befindet sich die Rakete des 2. Abwehrsystems noch in der Luft, während die feindliche Rakete explodiert – und verfolgt forthin ein Objekt, das gar nich mehr existiert.

Das ist dann falsch implementiert
Denn es ändert sich bei der "Zerstörung im Spiel" erst mal nur der Zustand in "zerstört". Deshalb muss aber das Objekt selber nicht gleich zerstört werden.

Hier würde sich auch die Verwendung von Interfaces anbieten.

[BUG]

Zitat von Sir Rufo:

Hier würde sich auch die Verwendung von Interfaces anbieten.

Ich glaube, es ging eher darum, klar zu machen, dass eine hierarchische Organisation von Objekte, wie sie shmia fordert, nicht immer sinnvoll/möglich ist.

Zitat von shmia:

Wenn man sich die Lebenszeit eines Objekts als Rechteck vorstellt, dann besteht die Kunst darin, die Rechtecke so ineinander zu schachteln, dass sich die Grenzen nicht überschneiden.

Um mir die Lebenszeit eines Objekts als Rechteck und nicht auf einem Zeitstrahl vorzustellen, fehlt mir allerdings die Phantasie

[Namenloser]

Zitat von Sir Rufo:

Zitat von NamenLozer:

Soweit so gut – aber was, wenn es ein zweites Raketenabwehrsystem gibt, das ebenfalls eine Abwehrrakete auf das gleiche Ziel losgeschickt hat? Dann befindet sich die Rakete des 2. Abwehrsystems noch in der Luft, während die feindliche Rakete explodiert – und verfolgt forthin ein Objekt, das gar nich mehr existiert.

Das ist dann falsch implementiert
Denn es ändert sich bei der "Zerstörung im Spiel" erst mal nur der Zustand in "zerstört". Deshalb muss aber das Objekt selber nicht gleich zerstört werden.

Ja, in der Regel implementiert man das in der Praxis auch so. Aber das Problem bleibt letztlich trotzdem, denn irgendwann muss man das Objekt endgültig entfernen, wenn man kein Memory Leak haben will. Das Beispiel sollte aber sowieso nur zur Veranschaulichung dienen.

Man kann immer alles auch anders lösen, keine Frage – aber man kann auch auf Klassen als Sprachkonstrukt verzichten und stattdessen wieder mit Records und Funktionen programmieren. Klassen erleichtern aber die Arbeit; Smart-Pointers ebenso.

[Jonas Shinaniganz]

Okay nachdem Ich alles sorgfältig gelesen habe entscheide Ich mich definitiv für "Smart Pointer".

Pros:
- Ich werde keine Referenzen mehr haben die auf freien Speicher zeigen und kann vor Zugriffen auf NIL prüfen
- Meine Objekte sind sehr "verworren " und die Lebenszeit ist schwer abzuschätzen, Smartpointer bieten sich an
- Designfehler wurden in der Vergangenheit gemacht und es ist nicht möglich diese jetzt anzugehen

Cons:
- Das erkaufe Ich mir durch ermöglichen/fördern von schlechtem Design
- Die Implementation ist scheinbar halbherzig weil es kein vollständiger Garbagecollector ist
- Beim mischen von Interfaces und Objecten muss man vorsichtig sein

Das Ich Globale Variablen vermeiden soll und werde habe Ich schon vor längerer Zeit für mich entschieden.

Also insgesammt kann ein Smartpointer scheinbar nicht schaden, er HINDERT einen ja nicht an gutem Design und löst mein Problem.
Deswegen entscheide Ich mich für Smartpointer und lese jetzt eure Verweise um eine möglichst schnittige Implementierung hinzubekommen,

beste Grüße!

[Furtbichler]

Wenn ich mein Programmdesign so aufbaue, das es für alle Instanzen jeweils eine Entität gibt, die dafür zuständig ist (ein anderes Objekt oder eine Klasse bzw. die Unit für unsere globalen Freunde), dann stellt sich das Problem nicht, das ich auf Instanzen zugreife, die nicht mehr existieren. Eine Ausnahme stellen zirkuläre Bezüge dar, die dann aber aufgelöst werden können, sodaß die Grundregel (Zuständigkeiten!) wieder greift.

Ich möchte die Kontrolle haben, wann genau ein Objekt freigegeben wird.

Es kann sein, das ich dann im Design etwas statischer agieren muss, und nicht mehr so elegant arbeiten kann. Aber sicherer bin ich damit in jedem Fall. Wenn man das stringent durchzieht, hat so ein Design auch eine gewisse Ordnung bzw. Eleganz. Ja gut, altbacken. Aber solide. Die Abhängigkeiten sind nur in einer Richtung.

Bei Interfaces habe ich diese natürlich Probleme nicht. Sie sind ein mächtiges Werkzeug, aber ich muss damit umgehen können.

Arbeite ich mit Interfaces dann weiss ich nicht, wann die Objekte freigegeben werden, was ganz praktisch ist. Aber beim Design muss ich aufpassen, das ich nicht Objekte wie Kraut und Rüben (Zirkuläre Bezüge) instantiiere und Abhängigkeiten erzeuge, die ich nicht mehr verstehe.