Eigenschaften in Dealloc: Release dann auf Null gesetzt? oder einfach

Ich bin neu in Objective-C (und stackoverflow) und ich bin ein wenig um Best Practices in Bezug auf Eigenschaften gedreht.Eigenschaften in Dealloc: Release dann auf Null gesetzt? oder einfach

Mein Verständnis ist, dass wenn Sie vollständig mit einer Eigenschaft fertig sind, können Sie Fehler vermeiden, indem Sie sie freigeben und dann sofort auf Null setzen, so dass nachfolgende Nachrichten auch NULL anstelle einer Ausnahme zurückgeben.

[myProperty release], meineEigenschaft = null;

Wenn es jedoch um Dealloc für "kopieren" und "behalten" -Eigenschaften geht, gibt es keine Notwendigkeit, beides zu tun? oder macht eine einfache

[myProperty release] schneiden Sie es? Habe ich auch Recht, dass ich in dealloc keine "assign" -Eigenschaften freigeben muss?

Vielen Dank!

Quelle

2010-08-04 averydev

Freigeben, aber nicht auf Null setzen. Einstellen auf Null über Ihre @synthesized Setzer:

self.myProperty = nil

wird Ihren alten Wert als Teil der Neuzuweisung freizugeben (obwohl wie in den Kommentaren erwähnt, können unerwünschte Nebenwirkungen haben), sondern einfach auf Ihre Membervariable zuweisen nil:

myProperty = nil

wird nicht.

[myProperty release]

ist alles was Sie brauchen.

(und Sie sind richtig über „zuweisen“ Eigenschaften.)

Quelle

2010-08-04 02:47:32

+1, dass die Veröffentlichung alles ist, was Sie brauchen, aber ich warnen vor der Verwendung von 'self.myProperty = nil' in' dealloc '(es könnte KVO-Methoden auslösen und Beobachter benachrichtigen, um auf ein teilweise freigegebenes Objekt zuzugreifen ...) –

Wie Dave sagt, ist die aktuelle Praxisempfehlung (von Apple), die Accessoren nicht dazu zu verwenden, in dealloc nil (und damit release) zuzuweisen. Es konnte nicht nur KVO-Methoden auslösen, sondern der Set-Accessor wurde möglicherweise von einer Unterklasse außer Kraft gesetzt. – JeremyP

Älter und klüger jetzt ... best practice scheint zu sein, self.myProperty = nil für IB outlet properties in viewDidUnload zu verwenden. Dies ermöglicht es ViewController, die Ansichtshierarchie wiederherzustellen, wenn sie durch einen geringen Speicher demontiert wurde. – averydev

@ Dave DeLong und JeremyP: Ich denke, wir „mit ererbten Nachrichten (direkt oder indirekt durch einen, ruft einen Teil von Super) whil„sagen konnte, "ein Objekt zu bauen (durch Init ..., Neu ... oder Kopie ...) ist wie ein Haus zu bauen und das Dach darauf zu legen, während niemand sicher ist, ob der Keller schon da ist. Und dies zu tun, während dealloc ein Äquivalent sein könnte, um das Haus niederzureißen, indem man die Grundmauern niederschlägt und nicht sicher ist, ob es in seinem Keller ist ".

Bei der Verwendung von Methoden ohne Vererbung könnte dies auch tun - aber wenn sie Ihre eigenen sind, können Sie es steuern (und müssen).

Grüße

Quelle

2010-08-04 19:07:01

@ Dave DeLong: Wenn die dealloc Methode eines Objekts durchgeführt wird, wird das Objekt nicht mehr verwendet wird. Alle kvo-Beobachter sollten zu diesem Zeitpunkt entfernt werden, sonst wird ein Rückgang fallen gelassen. Und trotzdem - selbst wenn ein Beobachter die Veränderung sehen würde, würde das Objekt (zumindest teilweise) noch existieren.

Der Override Accessor ist das richtige Argument, denke ich. Für Ihre eigenen Klassen ist es jedoch möglicherweise einfacher, den Accessor zu verwenden. Vor allem, wenn Sie synthetisierte Methoden verwenden, wo Sie die Semantik kennen, aber keine Details über den Accessor ...

Quelle

2010-08-07 00:15:04

Eigenschaften in Dealloc: Release dann auf Null gesetzt? oder einfach

Antwort

Verwandte Themen