Modernes Ziel-C (2013) und Deklarieren von Ivars/Verwenden von @property, @dynamic und @synthesize

Question

Was sind mit der aktuellen Version von Objective-C die offiziellen Standards und Best Practices für die Erklärung von IVARs, und verwenden @property und @synthesize? Es gibt viele Beiträge und Ressourcen zu diesem Thema, aber die meisten von ihnen sind von vor ein oder zwei Jahren ziemlich veraltet. Ich habe kürzlich gelernt, IVARs nur in einem Erklärungblock in der Umsetzung einer Klasse zu deklarieren, damit die Einkapselungsprinzipien von OOP nicht gebrochen sind, aber in dieser Zeit sogar für notwendig erklärt? Was wäre ein möglicher Anwendungsfall, in dem es tut:

@interface MyClass()
@property (nonatomic) NSString* data;
@end

@implementation MyClass{
    @private
        NSString* _data;
}
@end

ist notwendig? Um das zu fördern, ist es jemals notwendig zu verwenden? @synthesize? Mein Verständnis ist, dass die Verwendung @property synthetisieren Sie sowohl die Accessor-Methoden als auch die Backing IVARS. Ich habe einige Experimente durchgeführt und habe das bemerkt, wenn ich nicht erkläre NSString* _data', I can still access_data 'in meiner Klassenimplementierung. Bedeutet das, dass die Erklärung von Ivars auf eine Frage des Stils zurückzuführen ist, bis zum Ermessen des Programmierers? Könnte ich meinen Code verdichten und alle IVAR -Erklärungen in den Anweisungsblöcken in meiner Implementierung entfernen und nur verwenden @property in meiner privaten Schnittstelle? Wenn dies nicht der Fall ist, welche Vor- und Nachteile der explizit deklarierenden IVARs sind die Vor- und Nachteile?

Endlich, @dynamic. Nach dem, was ich sammeln kann, wird es dem Compiler verwendet: "Hey Compiler, generieren Sie die Accessor-Methode nicht automatisch und machen Sie sich keine Sorgen, wenn Sie keine Implementierung dafür finden, ich werde zur Laufzeit eine zur Verfügung stellen ". Ist das alles @dynamic Wird für oder gibt es mehr?

Ich möchte nur all diese Dinge klären, weil es so aussieht, als ob es viele verschiedene Meinungen gibt und dass es nicht unbedingt eine richtige Antwort gibt. Mit zunehmendem Objektiv-C wächst und Fortschritte, diese Antworten ändern sich, sodass es schön ist, einen kurzen und aktuellen Leitfaden zu haben. Danke an alle! (Auch wenn es etwas gibt, das ich besser Wort machen oder klarer machen könnte, lassen Sie es mich wissen)

BEARBEITEN:

Zusammenfassend frage ich Folgendes:

1) Ist es notwendig, IVARs mit modernem Ziel zu deklarieren? 2) Kann ich die gleichen Auswirkungen der Deklaration von IVARs und entsprechenden Eigenschaften erreichen, indem ich nur verwendet? @property? 3) Wofür wird @Dynamic verwendet? 4) Kann ich vollständig auf die Verwendung von verzichten? @synthesize Oder gibt es einen guten Anwendungsfall dafür?

Stimmen Sie auf und ab, wie Sie es für richtig halten.

Answer 1

Hier gibt es viel zu beantworten. Ich werde es zerlegen:

Ivars deklarieren

Wie Sie korrekt bemerkt haben, werden moderne Versionen des Compilers Backing -Instanzvariablen für deklarierte @Properties synthetisieren. Die Ausnahme davon liegt bei 32-Bit-Macs, bei denen die moderne Ziel-C-Laufzeit, einschließlich nicht-fragiler Instanzvariablen, nicht verfügbar ist. Unter der Annahme, dass Ihre Bewerbung nicht auf 32-Bit-OS X abzielt @property.

Wenn Sie immer noch einen IVAR direkt verwenden möchten, ohne einen entsprechenden @property (Etwas, das ich die meiste Zeit für eine schlechte Idee halte), Sie müssen natürlich den IVAR ausdrücklich erklären.

@dynamic

@dynamic ist, wie Sie gesagt haben, dem Compiler zu sagen, dass "Accessors für diese Immobilie nicht synthetisieren, ich werde es selbst zur Laufzeit tun". Es wird nicht so oft verwendet. Ein Ort, an dem es verwendet wird, ist an NSManagedObject Unterklassen, wenn Sie, wenn Sie eine modellierte Eigenschaft im Header deklarieren, nicht zusammenstellen möchten, dass es sich beschweren, dass es keine Implementierung von Zubehör für diese Eigenschaft gibt, und Sie möchten auch nicht, dass sie Zubehör selbst generieren. NSManagedObject Generiert Accessors für modellierte Eigenschaften zur Laufzeit. Die Geschichte ist für benutzerdefinierte Calayer -Unterklassen ähnlich.

@synthesize

@synthesize fordert den Compiler explizit an, Accessor-Methoden und (auf iOS und 64-Bit-Mac) einen entsprechenden IVAR für die angegebene Eigenschaft zu synthetisieren. Es gibt drei Hauptfälle, in denen Sie es noch verwenden müssen:

1. 32-Bit-Mac-Apps.
2. Wenn Sie Ihren eigenen benutzerdefinierten Setter und Getter geschrieben haben (oder nur Getter für Readonly -Eigenschaften). In diesem Fall synthetisiert der Compiler Accessors nicht, da er Ihre sieht. Es wird jedoch auch den Backing IVAR nicht synthetisieren. Sie müssen also verwenden @synthesize someProperty = _someProperty;, um dem Compiler zu sagen, er solle einen Ivar synthetisieren. Es wird natürlich immer noch keine Accessor -Methoden synthetisieren. Alternativ können Sie explizit einen Backing -IVAR deklarieren. Ich bevorzuge @synthesize in diesem Fall.
3. Wenn Sie einen anderen Namen für den Backing IVAR der Eigenschaft als den Standard verwenden möchten (Eigenschaftsname mit einem zusätzlichen Unterstrich). Das ist selten. Der Hauptfall, an den ich mich für die Verwendung vorstellen kann, ist der Übergang vorhandener älterer Code, der den direkten IVAR-Zugriff umfasst und wenn die IVARs nicht unterstreichen.

Answer 2

Die beste aktuelle Praxis scheint darin bestehen zu sein, Eigenschaften für alle IVARs zu verwenden, die die Eigenschaft entweder in der .H -Datei platzieren, wenn sie ausgesetzt werden sollen, und in der .m -Datei in einer Klassenerweiterung, wenn sie in der Klasse lokal sind.

Nein @synthesize wird benötigt, es sei denn, der IVAR muss sich von dem unterstrichenbezogenen Eigenschaftsnamen unterscheiden.

Ja, @dynamic ist wie Sie beschreiben.

Darüber hinaus ist es nicht mehr erforderlich, lokale Instanzmethoden oder -auftrag so zu deklarieren, dass die Methode über der Verwendung liegt.

Answer 3

Zunächst einmal ist @synthesize für diese Szenarien verschwunden: Muss es nicht mehr tun.

Zweitens brauchen Sie auch nicht mehr den privaten IVAR.

Im Wesentlichen können Sie einfach Eigenschaften machen.

Die Art und Weise, den Zugriff zu kontrollieren offen und eng an den Palen).

Beachten Sie auch, dass viele der Dinge, die die öffentliche Schnittstelle in der Vergangenheit überfüllt haben, jetzt nur in der privaten Schnittstelle sein können, also beispielsweise Iboutlets usw., da der Controller das einzige sein wird, was sie darstellt.

Ich sehe nie, dass @dynamic nirgendwo verwendet wird, außer in gekonnt generierten Entitäten.

Für jemanden, der zum ersten Mal mit C ++ gearbeitet hat, wo der Traum immer war, dass die Header/die Schnittstelle dem Benutzer der Klasse lediglich zeigt, was er brauchte, und alle anderen Details versteckt wären, denke ich, dass Moc (Moderne Objective C) ein wahr gewordener Traum ist.

Übrigens empfehlen die Intro -Sitzung von WWDC Modern Ziel C (ab 2012) und die in diesem Jahr war auch großartig.