Sollte ich Ivars in Objective-C verwenden?

Ich erkläre auch generell keine Ivars. Ich werde oft @synthesize foo = foo_; verwenden, um direkten Zugriff zu verhindern, wenn ich "through-method" oder umgekehrt meinte. Und ich lasse den Compiler automatisch den ivar mit dem _ Präfix synthetisieren (was versehentliche Fehler verhindert) direkter Zugang, wie in der streik -Phrase).

Und, wie Caleb sagte, es gibt immernoch Ivars, die Sie nicht explizit deklarieren, es sei denn, Sie möchten das wirklich (was Sie nicht als exponierte Ivars in den Headern für Kunden nicht nützlich sind) der Klasse, wenn Ihre API entsprechend gestaltet ist).

Ich finde auch, dass der Hype um "verwende nur direkten Zugriff in init / dealloc, benutze Setter / Getter überall sonst" weitgehend übertrieben ist und benutze daher einfach den Setter / Getter überall. Die Realität ist, dass wenn Sie Beobachter während der Initialisierung / Freigabe haben, Sie bereits abgespritzt sind; der Zustand des Objekts ist definitionsgemäß während der Konstruktion / Zerstörung undefiniert, und somit kann ein Beobachter den Zustand nicht korrekt begründen.

Wie Caleb betont, besteht ein weiterer Grund für den direkten Zugriff auf iVAR in init / dealloc darin, Unterklassen zu vermeiden, die eine benutzerdefinierte Setter / Getter-Logik implementieren, die aufgrund des nicht definierten Status des Objekts während des Init / Deallocs blockieren kann.

Obwohl das wahr sein mag, halte ich es für einen fiesen architektonischen Fehler, Setter / Getter mit benutzerdefiniertem Verhalten zu implementieren. Dies ist fragil und macht es erheblich schwieriger, den Code im Laufe der Zeit umzuformen. Ein solches benutzerdefiniertes Verhalten hat oft auch eine Abhängigkeit von einem anderen Zustand innerhalb des Objekts, und diese Abhängigkeit führt dann zu Abhängigkeiten der Reihenfolge von Zustandsänderungen, die von der scheinbar einfachen @property -Deklaration überhaupt nicht reflektiert werden.

i.e. Wenn Ihre Setter und Getter so geschrieben sind, dass foo.bar = bad; nicht in any -Zeit auf foo ausgeführt werden kann, ist Ihr Code gesperrt.

Es ist nicht so wichtig, dass Instanzvariablen nicht benötigt werden. Es ist nur so, dass die Instanzvariable deklarationen nicht benötigt wird. Bei einer Eigenschaft und einer @ synthesize-Anweisung sorgt der Compiler dafür, dass die Instanzvariable zusammen mit den entsprechenden Zugriffsmethoden erstellt wird.

Es ist nichts falsch daran, ausschließlich Eigenschaften zu verwenden. Sie vereinfachen die Speicherverwaltung. Es ist auch nichts falsch daran, iVars ohne Eigenschaften zu verwenden, wenn Sie das wollen. Wenn Sie Eigenschaften verwenden möchten, aber nicht die Accessoren für den Rest der Welt bekannt machen möchten (dh die Kapselung beibehalten), sollten Sie Ihre nicht öffentlichen Eigenschaften in einer Klassenerweiterung deklarieren (im Grunde eine anonyme Kategorie in Ihrer Implementierungsdatei) / p>     

Die Verwendung von iVars ist sicherlich nicht falsch, jedoch empfehlen die besten Praktiken nun stattdessen die Verwendung von @property.

Ein Ort, an dem Sie einen Ivar verwenden möchten, ist, wenn Sie eine geschützte Eigenschaft deklarieren möchten. Sie deklarieren die Eigenschaft in der .m-Datei für eine Klasse und deklarieren den entsprechenden ivar in der .h-Datei mit der @ protected-Direktive. Dadurch erhalten Sie einen geschützten Zugriff in der Unterklasse. Es gibt keine Alternative für geschützten Zugriff auf Mitglieder.