Il y a un peu moins de deux ans, après avoir lu un article humblement intitulé "Les commandements de code: meilleures pratiques pour le codage Objective-C" par Robert McNally , j'ai adopté la pratique d'utiliser des propriétés pour à peu près tous les membres de données de mes classes Objective-C ( 3e commandement en mai 2012). McNally énumère ces raisons pour le faire (c'est moi qui souligne):
- Les propriétés appliquent des restrictions d'accès (comme en lecture seule)
- Les propriétés appliquent la politique de gestion de la mémoire (forte, faible)
- Les propriétés permettent d'implémenter de manière transparente des setters et des getters personnalisés.
- Les propriétés avec des setters ou des getters personnalisés peuvent être utilisées pour appliquer une stratégie de sécurité des threads.
- Avoir une seule façon d'accéder aux variables d'instance augmente la lisibilité du code.
Je mets la plupart de mes propriétés dans des catégories privées, donc les numéros 1 et 4 ne sont généralement pas des problèmes auxquels je suis confronté. Les arguments 3 et 5 sont plus «souples» et, avec les bons outils et autres consistances, ils pourraient devenir non problématiques. Enfin, pour moi, le plus influent de ces arguments était le numéro 2, la gestion de la mémoire. Je fais ça depuis.
@property (nonatomic, strong) id object; // Properties became my friends.
Pour mes derniers projets, je suis passé à l'utilisation d'ARC, ce qui m'a fait douter que la création de propriétés pour à peu près n'importe quoi soit toujours une bonne idée ou peut-être un peu superflue. ARC s'occupe de la gestion de la mémoire des objets Objective-C pour moi, ce qui fonctionne bien pour la plupart des strong
membres si vous déclarez simplement les ivars. Les types C que vous deviez gérer manuellement de toute façon, avant et après ARC, et les weak
propriétés sont principalement publiques.
Bien sûr, j'utilise toujours des propriétés pour tout ce qui nécessite un accès depuis l'extérieur de la classe, mais ce ne sont pour la plupart qu'une poignée de propriétés, tandis que la plupart des membres de données sont répertoriés comme des ivars sous l'en-tête de l'implémentation
@implementation GTWeekViewController
{
UILongPressGestureRecognizer *_pressRecognizer;
GTPagingGestureRecognizer *_pagingRecognizer;
UITapGestureRecognizer *_tapRecognizer;
}
En tant qu'expérience, j'ai fait cela un peu plus rigoureusement, et l'abandon des propriétés pour tout a de beaux effets secondaires positifs.
- Les exigences de code de membre de données (
@property
/@synthesize
) ont été réduites à la seule déclaration ivar. - La plupart de mes
self.something
références ont été nettoyées juste_something
. - Il est facile de distinguer quels membres de données sont privés (ivars) et lesquels sont publics (propriétés).
- Enfin, il `` semble '' plus que c'était le but pour lequel Apple souhaitait les propriétés, mais c'est une spéculation subjective.
Passons à la question : je glisse lentement vers le côté obscur, en utilisant de moins en moins de propriétés en faveur des ivars d'implémentation. Pouvez-vous m'expliquer pourquoi je devrais m'en tenir à l'utilisation de propriétés pour tout, ou confirmer mon courant de pensées quant à la raison pour laquelle je devrais utiliser plus d'ivars et moins de propriétés uniquement là où c'est nécessaire? La réponse la plus convaincante de chaque côté recevra ma note.
EDIT: McNally intervient sur Twitter, disant : "Je pense que ma principale raison de rester avec les propriétés est: une façon de tout faire, qui fait tout (y compris KVC / KVO.)"