Frage zu FreeAndNil

[negaH]

So lange es in der Programmiersprache kein implizites Feature gibt das die Gültigkeit von Objektreferenzen automatisiert regelt hat FreeAndNil() eine Existenzberechtigung. Es lassen sich immer sinnvolle Anwendungsbeispiele für FreeAndNil() konstruieren wenn dies nicht so ist. Klar, man kann auch auf FreeAndNil() verzichten und baut dann eben umständlich einen aufwendigen und damit fehleranfälligen Mechanismus um auf FreeAndNil() verzichten zu können, zb. Notifications usw. Denoch bleibt am Ende die Erkenntis das FreeAndNil() für eine Sprache die keine automatische Bereinigung von Referenzen bietet eben eine Notwendigkeit ist.

Betrachtet man es so so wird auch ersichtlich wie im Grunde sinnlos diese Diskussion ist. Die saubere Lösung des Problemes ist die Änderung der Sprachfeatures, nur das halte ich für konstruktiv. Alleine schon die Konzentration, eg. Beschränkung der ganzen Diskussion auf FreeAndNil() innerhalb des Destructors, als Indiz für einen Designfehler, zeigt das diese Diskussion auf schwachen Beinen steht. Es ist unbestritten das auf Grund von Designfehlern die Problematik von FreeAndNil() im Destructor sich auftut, aber darauf ist das Problem nicht allgemein beschränkt und es berücksichtigt eben auch nicht das gerade Designfehler in der Produktion die meist gemachten Fehler mit den größten Konsequenzen sind. Dh. Designfehler wird es immer geben egal ob man FreeAndNil() und Destructoren benutzt oder eben eine Programmiersprache die auf Grund ihrer Konstruktion garnicht dieses spezielle Problem haben wird.

Ergo: ich bleibe bei meiner Aussage

1.) Designfehler vermeiden
2.) FreeAndNil() benutzen, da man Designfehler nie zu 100% ausschließen kann
3.) wenn erforderlich mit bedingten Assertions() arbeiten um die Fehlersuche zu verbessern

Diese Arbeitsweise wird uns aufgezwungen da die benutzte Programmiersprache eben Defizite hat.

Designfehler kann man allein schon auf Grund der flexiblen Zielsetzungen die in der Praxis vorkommen garnicht ausschließen. Ich möchte den Auftraggeber sehen der nach ein Jahr Entwicklung und nach geänderten Anforderungen an die Software, die eben auch grundsätzliche Änderungen im Design bedingen, nun freiwillig einsieht das oft die komplette Software von Grund auf neu entwickelt werden muß, also nochmals ein Jahr an Entwicklung nötig wird. Und mir soll keiner kommen das man dann dem Auftraggeber verklickern soll auf seine Änderungswünsche nicht eingehen zu können. Man wird eher ziemlich schnell weg vom fenster sein und keine weiteren Aufträge mehr bekommen.

Man kann also über den Idealfall diskutieren wie man möchte die Praxis kennt den Idealfall garnicht, und wir Entwickler sollten Pragmaten und keine Dogmaten sein.

Gruß Hagen