IBOutlet sur les propriétés et l'exposition de la classe

Question

Apple, pour les problèmes de gestion de la mémoire, recommande de définir des points de vente sur les propriétés, pas dans la déclaration d'attribut. Mais, pour autant que je sache, déclarer des propriétés expose la classe à des classes externes, donc cela pourrait être dangereux.

Sur UIViewController nous avons la définition de la vue principale et la logique, donc MVC est légèrement triché dans ce cas.

Quelle est l'approche de beter, la recommandation d'Apple pour la gestion de la mémoire ou classes blindées?

Answer 1

MVC est pas triché par UIViewController, comme cette classe implémente un contrôleur. Il définit les connexions entre les objets View (généralement stockés dans le XIB) et les objets Model (parfois des entités Core Data, parfois d'autres choses).

Quoi qu'il en soit. Le point de définir les points de vente en tant que propriétés est que vous devez indiquer explicitement quelles sont les exigences de gestion de la mémoire sur les propriétés dans l'interface de classe. Le mécanisme de chargement NIB utilise les accesseurs s'ils existent, donc si vous définissez une propriété de retenue, la sortie est conservée. S'il ne trouve pas d'accesseurs, il va définir directement la variable d'instance.

Si vous définissez des propriétés ou non pour vos points de vente est vraiment une question de goût personnel. Je le fais, car les prises sont définies par un objet externe (la classe NSBundle) donc à mon avis représentent une partie de mon contrat d'API de contrôleur de vue.

Answer 2

Je crois que vous pensez à ce problème.

Outlets existent seulement pour qu'un objet externe, le code Interface Builder et les décodeurs nib, peuvent configurer l'instance de la classe avec les points de vente. Cacher un point de vente derrière @protected ou @private irait à l'encontre de leur objectif.

En bonne conception cela ne devrait pas être un problème parce que les contrôleurs de vue doivent être des objets relativement légers dont la seule fonction est de déplacer des données entre la vue et le modèle. La logique de base de l'application doit être encapsulée en toute sécurité dans le modèle.

Si vous avez besoin d'une conception sécurisée, vous pouvez créer les vues et les rendre programme privé mais vous perdez toute la flexibilité et la réutilisation que vous obtenez avec des sorties. C'est un compromis.

Dans les deux cas, cependant, cela n'a rien à voir avec la gestion de la mémoire et les propriétés. Qu'une propriété soit publique, protégée ou privée n'a rien à voir avec la gestion de la mémoire des propriétés.