Referenz Verwaltung

[Thom]

Zitat von shmia:

Die VCL verwendet keine Tricks sondern nur den etablierten Weg über Komponenten.

Eben. Und eine Komponente ist kein Objekt? Du hast mir also meine Frage noch nicht beantwortet: Weshalb soll man "Smart Pointer", "Smart Interfaces" oder wie immer solche Dinge auch genannt werden, nicht verwenden? Weil sie nicht "etabliert" sind?

Zitat von shmia:

Das Problem ist, dass man globale Objekte vermeiden sollte wann immer es möglich ist.

Ja - weshalb denn? Nenne bitte einen nachvollziehbaren Grund.

Zitat von shmia:

Manchmal lässt es sich nicht vermeiden ein Objekt global anzulegen, aber jedes globale Objekt erzeugt auch Probleme wie schlechte Testbarkeit.

Auch das ist nur eine pauschale Aussage. Es wäre schön, wenn Du Deine Behauptungen auch untermauern würdest...

[shmia]

Zitat von Thom:

Weshalb soll man "Smart Pointer", "Smart Interfaces" oder wie immer solche Dinge auch genannt werden, nicht verwenden? Weil sie nicht "etabliert" sind?

Nein, weil der Programmierer damit seine schlechte Struktur (globale Objekte, keine Vorstellung über die Lebendauer von Objekten) überdeckt was langfristig zu schlecht wartbarem Code führt.

Zitat von Thom:

Zitat von shmia:

... dass man globale Objekte vermeiden sollte wann immer es möglich ist.

Ja - weshalb denn? Nenne bitte einen nachvollziehbaren Grund.

Also das gehört zu den Grundlagen eines jeden Programmierers, der sein Handwerk ernsthaft betreibt.
http://c2.com/cgi/wiki?GlobalVariablesAreBad

[Namenloser]

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. Die andere Stelle kriegt davon aber nichts mit und hat keine Möglichkeit zu überprüfen, ob das Objekt noch existiert, weil Assigned nur den Pointer auf nil prüft.

Für den Fall, dass man ein Objekt nur an einer einzigen Stelle verwendet, gibt es FreeAndNil, aber bei mehreren, unabhängige Referenzen hilft das nichts. Mal unabhängig davon, dass man immer leicht alles pauschal als „schlechtes Design“ abtun kann, ist das irgendwie asymmetrisch.

Man kann das Problem natürlich „klassisch“ mithilfe eines Observer-Patterns o.ä. angehen (so ähnlich wie es die VCL afaik auch macht), aber das ist erstens umständlich und zweitens wieder eine potenzielle Fehlerquelle, weil man jedes mal darauf achten muss, manuell einen Observer hinzuzufügen oder zu entfernen.

Ein Smart-Pointer automatisiert das Prozedere einfach nur und wäre daher aus meiner Sicht eine Verbesserung – schlechtes Design gibt es mit und ohne Smart Pointer. Aber mit Smart-Pointer hat man zumindest eine Fußangel weniger, an der es knallen kann.

Und an dieser Stelle muss ich natürlich noch mal auf meine Frickel-Lösung aus diesem Thread verweisen, der das gleiche Thema hatte . Vielleicht fühlt sich ja jemand inspiriert und entwickelt etwas daraus, das man tatsächlich einsetzen kann (eventuell mithilfe von neuen Sprachfeatures wie Generics, die ich unter TDE leider nicht zur Verfügung habe)...

[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.