NSKVONotifying_MyClass, un Automatic SubClassing: Attention à vos Initialize !
ClicCool
Membre
Bonjour,
Je ne retrouve pas le Thread exact mais on en a parlé à plusieurs reprises sur ce forum.
Il faut veiller à ce que nos méthodes +Initialize ne soient appelées qu'un seule fois avec, comme Apple le recommande dans la doc: Initializing a Class Object, un template de ce type
Et cela du fait que, s'il existe une sous classe n'implémentant pas cette fonction l'appel d'Initialize sera alors transmis à sa superClasse (la notre) et donc exécutée une deuxième fois.
Pour une de mes Classe de controlleur de vue qu'en aucun cas je ne serais amené à sous-classer, je me suis donc senti autorisé à me passer de cette toute petite lourdeur d'écriture.
Grave erreur de ma part !Â
Et il m'a fallu un moment pour mettre le doigt sur le problème. Cocoa a, en effet, sournoisement sousClassé mon controlleur à l'insu de mon plein grés !
Et, bien sur, mes initialisations ont été exécutées deux fois:
- Une fois par l'Initialize de ma classe: PatientViewCTRL
- Une autre fois par le Initialise de: NSKVONotifying_PatientViewCTRL (Classe créée automatiquement par Cocoa ... )Â ???
Sur ce coup j'ai compris la leçon et, à l'avenir je respecterait à la lettre le Template proposé par Apple pour les Initialize.
Ceci dit, je ne trouve rien dans la doc d'Apple sur les Automatic SubClassing en général ni sur ceux de NSKVONotifying_ en particuliers.
- Qu'est-ce qui provoque le NSKVONotifying_ subClassing ? (Xcode, IB, le runTime ... ?
- Y'a-t-il d'autres situations ou un Automatic SubClassing peut entrer en jeu ?
Je ne retrouve pas le Thread exact mais on en a parlé à plusieurs reprises sur ce forum.
Il faut veiller à ce que nos méthodes +Initialize ne soient appelées qu'un seule fois avec, comme Apple le recommande dans la doc: Initializing a Class Object, un template de ce type
+ (void)initialize<br />{<br />Â if (self == [ThisClass class]) {<br />Â Â Â Â // Perform initialization here.<br />Â Â Â Â ...<br />Â Â }<br />}
Et cela du fait que, s'il existe une sous classe n'implémentant pas cette fonction l'appel d'Initialize sera alors transmis à sa superClasse (la notre) et donc exécutée une deuxième fois.
Pour une de mes Classe de controlleur de vue qu'en aucun cas je ne serais amené à sous-classer, je me suis donc senti autorisé à me passer de cette toute petite lourdeur d'écriture.
Grave erreur de ma part !Â
Et il m'a fallu un moment pour mettre le doigt sur le problème. Cocoa a, en effet, sournoisement sousClassé mon controlleur à l'insu de mon plein grés !
Et, bien sur, mes initialisations ont été exécutées deux fois:
- Une fois par l'Initialize de ma classe: PatientViewCTRL
- Une autre fois par le Initialise de: NSKVONotifying_PatientViewCTRL (Classe créée automatiquement par Cocoa ... )Â ???
Sur ce coup j'ai compris la leçon et, à l'avenir je respecterait à la lettre le Template proposé par Apple pour les Initialize.
Ceci dit, je ne trouve rien dans la doc d'Apple sur les Automatic SubClassing en général ni sur ceux de NSKVONotifying_ en particuliers.
- Qu'est-ce qui provoque le NSKVONotifying_ subClassing ? (Xcode, IB, le runTime ... ?
- Y'a-t-il d'autres situations ou un Automatic SubClassing peut entrer en jeu ?
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
C'est quoi c'te classe qu'il semble te créer tout seul ? Zarb en effet !
Ben j'en tombe des nues moi aussi !
J'avais bien entendu parlé d'automatic subClassing dans d'autres languages mais je savais pas que ça pouvais survenir en ObjC2 sous Cocoa.
En tout cas le truc me semble assez sournois pour qu'on y fasse gaffe.
Dans mon projet ça ne se produit, semble-t-il, qu'avec ce controlleur là .
Ne trouvant pas de doc là dessus, j'ai essayé de comprendre le pourquoi du comment en créant une SousClasse de NSObjet pour tester le comportement à l'Initialize, d'abbord en y ajoutant des property, puis des @synthetize sur ces property, pensant que l'implémentation automatique des accesseurs KVO provoquaient peut-être ce sousClassement ... ben non.
Puis j'ai inscrit un objet de cette classe au NotificationCenter, pensant que peut-être c'est la mise en jeu des Notifications qui était en cause ... ben non
Peut-être que je devrais mettre cette sous classe dans un XIB et la binder pour voir ?
Mais si quelqu'un a une piste ce serait mieux
J'ai eu le même genre de surprise quand j'ai voulu utiliser un NSTreeController bindé sur un NSMutableArray: Dans IB lors du binding, tu n'as pas accès directement aux instances des objets contenus dans le tableau, mais tu y accèdes indirectement par l'intermédiaire d'objets "proxy" créés automatiquement par le framework.
Merci Zoc
Je comprends mieux maintenant.
Je trouve quand même ça un peu cavalier.
- De ne pas documenter ce sous-classage automatique
- De ne pas sous classer proprement en mettant un Initialize même vide pour pas sournoisement nous cochoner le comportement d'une de nos chère classe perso.