Xcode génère désormais une catégorie vide.Pourquoi?

Question

J'ai remarqué cela en utilisant iOS6 bêta 3

Lorsque je crée une nouvelle sous-classe d'un UIViewContoller (aucune autre classe parent ne génère ce comportement que j'ai remarqué), le fichier .m a désormais une catégorie vide en haut du fichier.Dans le passé, en me renseignant sur les catégories, j'ai remarqué que certaines personnes utilisaient cette même technique pour indiquer des méthodes privées (bien que pas vraiment privées).

Est-ce là l'intention?Y a-t-il eu un changement pour rendre les choses réellement privées maintenant ?Je remarque également la directive @private.

Quel est votre style de codage personnel concernant les variables et méthodes privées ?

MISE À JOUR:Puisque XCode nous pousse à utiliser les extensions de classe, je les ai utilisées pour les méthodes privées/ivar pour ce projet.J'ai cependant trouvé un inconvénient.J'ai vu que je pouvais réutiliser l'un de mes UIViewControllers sous-classés avec tous ses UIButtons, UILabels, etc....J'ai eu cet héritage :UIViewController <- FirstViewController <- SecondViewController.

Eh bien, toutes les méthodes privées que j'ai mises dans l'extension de classe de FirstViewController n'apparaissent pas dans la saisie semi-automatique lorsque je code dans SecondViewController.Un léger désagrément....

Answer 1

Vous faites référence à cette définition d'interface :

@interface MYViewController ()
@end

Il s'agit techniquement d'une extension de classe plutôt que d'une catégorie.Les catégories ont une chaîne entre parenthèses.Les extensions de classe sont ajoutées à la classe au moment de la compilation et peuvent donc ajouter des ivars (généralement sous forme de propriétés).Les catégories sont ajoutées au moment de l'exécution et ne peuvent pas ajouter d'ivars.

Cela dit, votre point est correct.Ceci est utilisé pour définir des méthodes et des propriétés privées.

Dans le monde ObjC, « privé » est un panneau « interdiction d'intrusion », pas un mur de barbelés.Alors qu'il existe un @private mot-clé (qui ajoute l'application du compilateur), il ne s'applique qu'aux ivars et n'est généralement pas nécessaire.Ce type de confidentialité basé sur des avertissements fonctionne très bien dans ObjC et est tout à fait suffisant.

Placez vos propriétés privées dans cette extension de classe, et les appelants extérieurs recevront des avertissements « peut ne pas répondre au sélecteur » s'ils tentent d'y accéder (tout comme ils le feraient pour appeler une méthode non définie).Vous ne devez jamais autoriser l'existence d'avertissements dans un projet ObjC, cela applique donc l'encapsulation des données.

---

MODIFIER

S'ils sont privés, ils ne devraient pas apparaître dans votre sous-classe.Ce que vous voulez est protégé.Il n'existe pas de système efficace pour les méthodes protégées dans ObjC, mais une technique courante consiste à les placer dans une catégorie dans un fichier .h comme MYViewController+Protected.h.Je trouve que cela arrive très rarement dans la pratique, car une grande partie des bonnes conceptions ObjC ne sont pas sous-classées.Il utilise plutôt la composition et la délégation.

Concernant «Pourquoi voir les contrôleurs». Tout d'abord, ce ne sont pas seulement les contrôleurs de vue.Il s'agit simplement de contrôleurs de vue sur iOS (enfin, VC, TableViewController et GLKViewController).Sur Mac, il s'agit également de contrôleurs de fenêtres et d'importateurs de projecteurs.Regarder dans:

.../Developer/Platforms/iPhoneOS.platform/Developer/Library/Xcode/Templates
.../Library/Xcode/Templates

Mais pourquoi ceux-là ?Eh bien, ce sont tous des contrôleurs, et il est incroyablement courant que les contrôleurs aient besoin de propriétés privées.En fait, si vous n'avez pas de propriétés privées dans un contrôleur, vous en rendez probablement trop publiques.Ce n'est pas aussi universel pour les classes de modèles et de vues.Je soupçonne que cela a joué dans leur décision.Il se peut également que différentes personnes soient propriétaires des modèles ou qu'ils aient été mis à jour à des moments différents.Parfois, vous voyez de petites incohérences qui s’estompent avec le temps.

Vous pouvez également créer vos propres modèles.Voir Création de modèles de fichiers Xcode 4 personnalisés.