Thema: Delphi Frage zu FreeAndNil

Einzelnen Beitrag anzeigen

Benutzerbild von negaH
negaH

Registriert seit: 25. Jun 2003
Ort: Thüringen
2.950 Beiträge
 
#10

Re: Frage zu FreeAndNil

  Alt 19. Feb 2010, 19:23
Darüber lässt sich streiten.

Szenario:

Ein Objekt verwaltet mehrere Objektvariablen als Felder in sich selbst. Alle diese Objekte greifen über einen zb. Owner/Parent auf diese übergeordnete Objekt zu. Diese untergeordneten Objekte nutzen ihren Owner/Parent um ihrerseits auf die anderen Objekte des Parten/Owners zugreifen zu können. Soweit ein ganz legales und OOP konformes Konstrukt.

Der Parent kann nun nicht zum gleichen Zeitpuinkt seine Objektfelder freigeben, er wird es immer sequentiell ausführen müssen.
Die untergeordneten Objekte des Parents fragen ihrerseits mit Assigned(Parent.Objekt_A) bei einem Zugriff ab ob das gewünschte Objekt überhaupt erzeugt wurde.

Nun passiert es gerade bei komplexeren Klassenstrukturen wie zb. Windows Controls das ein asynchrones Messagehandling benutzt wird. Also selbst beim Freigeben eines spezifischen Objektes kann es durchaus sein das dieses über Parent.Objekt_A noch weitere Behandlungen durchführt. Würde man im Destructor des parents nun njicht mit FreeAnNil() die Objekte freigeben dann funktioniert bei der Freigabe des nachfolgenden Objektes (Objekt_B im Parent) eine Abfrage wie Assignend(Parent.Objet_A) nicht korrekt.

Man kann nun behaupten das das alles "schlechtes Design" wäre.

Ich stehe auf folgendem Standpunkt:

1.) mache gutes Design
2.) benutzte ein zusätzlich Sicherheitsnetz, das kann nie schaden und kostet nichts

Wer von sich behauptet er benötigt kein
- FreeAndNil()
- if Assigned() then
- if Objekt is Klasse then

weil sein Design immer ein gutes Design ist das dies ja nicht nötig hat, der hat noch nie im Team gearbeite, noch auf Sourcen/Code anderer Programmierer aufsetzten, weiterentwickeln müssen und ist ergo arrogant und fern der Realitäten.

Gruß Hagen

PS: oder er benutzt eine Programmiersprache bei der all diese Probleme erst garnicht auftreten können, wozu Delphi nunmal nicht gehört.
  Mit Zitat antworten Zitat