Dois-je déclarer les variables dans l'interface ou utiliser les propriétés dans l'arc objective-c ?

Question

Approche 1 :

@interface MyController : UIViewController {
    UILabel *myText;
}

@property (nonatomic, strong) UILabel *myText;

approche 2 :

@interface MyController : UIViewController
@property (nonatomic, strong) UILabel *myText;

approche 3 :

@interface MyController : UIViewController {
    UILabel *myText;
}

J'ai lu quelques articles traitant de ce genre de choses, mais je ne sais pas encore vraiment quelle approche je dois adopter.

J'ai également trouvé que quelqu'un a dit que l'approche 1 est une ancienne méthode. Je voudrais donc connaître la meilleure pratique pour le SDK 6 d'ios en utilisant ARC.

Je sais que la déclaration de variables à l'aide de propriétés est un moyen facile de générer des getter et setter et quelqu'un a suggéré de l'utiliser. Cependant, je voudrais demander si, dans le cas où une variable n'est pas destinée à être appelée par une autre classe, il est nécessaire de déclarer la variable à l'aide d'une propriété et de la définir comme variable privée dans l'interface ? Ou est-il préférable qu'une variable ne soit déclarée qu'à l'intérieur de l'interface ? J'aimerais apprendre les meilleures pratiques, alors pardonnez-moi si cette question est stupide.

De plus, certains développeurs écrivent @synthesize de cette manière

@synthesize myText=_myText;

mais certains écrivent ceci :

@synthesize myText;

Je voudrais également connaître la différence et savoir lequel est préférable ?

Merci beaucoup !

Answer 1

Le moyen le plus moderne 1 :

• dans la mesure du possible, déclarer les propriétés
• ne pas déclarer les iVars séparément 2
• ne pas @synthétiser 3
• trouver le moins de propriétés possible dans votre fichier .h 4
• situer le plus grand nombre possible de propriétés dans une extension de classe de votre fichier .m 5

---

1 A partir de Xcode 4.5.2. La plupart de ces éléments s'appliquent jusqu'à la version 4.4, certains ne compileront pas avec la version 4.2 (la dernière version disponible sous Snow Leopard). C'est du matériel de préprocesseur, donc tout est compatible au moins jusqu'à iOS5 (je n'ai pas testé sur iOS4 mais cela devrait aussi être OK).

2 Il n'y a aucun intérêt à déclarer un iVar ainsi que une propriété. Je suis sûr qu'il existe quelques cas obscurs où vous voudriez déclarer des iVars au lieu de de propriétés mais je n'en vois aucune.

3 Xcode créera un iVar avec le même nom que la propriété, précédé d'un _underscore. Si vous avez (rarement) besoin d'un autre type de comportement, vous pouvez manuellement @synthesize property = someOtherName . @vikingosegundo nous lie à cet article sur les ivars dynamiques qui est un cas d'utilisation de @synthesize . @RobNapier commente que vous faire doivent @synthesize iVar = _iVar (bizarrement) si vous créez vos propres getters (readonly) et setters (read/write) pour une propriété, comme dans ce cas, le préprocesseur ne générera pas l'iVar pour vous.

4 La règle générale avec votre interface : gardez-la aussi vide que possible. Vous n'avez pas besoin de déclarer votre méthodes du tout, s'ils sont destinés à un usage privé. Si vous pouvez faire fonctionner le code sans déclaration d'interface, c'est la voie à suivre.

5 Il s'agit d'un bloc @interface dans votre fichier .m, placé au-dessus de votre @implementation :

#TestClass.m

@interface TestClass()

//private property declarations here

@end

@implementation TestClass
...

Answer 2

Vous pouvez également utiliser @synthesize si vous souhaitez disposer d'une belle table des matières de vos propriétés @synthesized à laquelle vous pouvez vous référer et que vous pouvez commenter pour plus de clarté et d'organisation.

De plus, une @synthèse vous permet de fixer un point d'arrêt sur la propriété et de piéger lorsque sa valeur est modifiée.

Lorsque le compilateur fait tout pour vous, vous finissez par être éloigné de ce qui se passe réellement et par l'ignorer. Cependant, il est également agréable de ne pas avoir à tout taper soi-même en permanence.