Déclarer ou non des méthodes surchargées
Philippe49
Membre
dans 1202236655:
ajouter la "déclaration" du awakeFromNib() dans le AppControler.h
Non, on ne redéclare pas les méthodes qui ont déjà été déclarées dans une classe dont on hérite.
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Duncan dit la même chose que toi:
" Vous n'êtes pas obligé de redéclarer la méthode redéfinie, mais il est d'usage de le faire"
[ EDIT ] page 15 d'Objective-C précis et concis
Ceci dit, je n'ai jamais vu une seule fois ce genre de redéclaration : C'est-à -dire que l'usage est quoi exactement ... Si on suit cette idée toute méthode définie dans le .m serait à déclarer dans le .h ?
Pour un framework cela peut sembler intéressant de le signaler, mais pour une classe dans une appli je n'en vois pas l'intérêt.
Justement non, ce n'est pas l'usage.
En général, on ne redéclare jamais une méthode héritée dans le .h, même et surtout si on la redéfinit dans le .m. Redéclarer une méthode héritée dans un .h n'apporte rien du tout puisque normalement les .h des super-classes sont lisibles et qu'en plus on n'a pas la possibilité de modifier les types d'une méthode héritée (c'est potentiellement un problème).
Ben oui, toute méthode du .m devrait être dans le .h, mis à part les méthodes privées...
Le but me semble être plutôt documentaire, histoire de pouvoir connaà®tre rapidement les méthodes (re)définies pour cette classe.
C'était Duncan qui me l'avait dit (Objective-C précis et concis), alors je l'avais cru :brule:
Bah alors faudrait que tu me dises où tu le lis parce que j'ai le livre aussi et il n'est rien dit de tel... Ce qui s'en approche le plus c'est :
en tout catimini, je crois qu'il ne l'a pas fait exprès ! ;D
Logiquement, je ne vois pas ce qui justifierait cela, à part l'aspect documentaire dans des classes dont l'utilisation serait ultra-courante. Mais dans les .h de Cocoa, est-ce que c'est pas fait ?
(remarque : il serait bon qu'un administrateur déplace ce sous-topic)
Ca me semble suffisamment clair pour que ce ne soit pas une erreur
(sauf si j'ai mal interprété le terme "redéfinie")
En effet, il faudrait sortir cette disgrétion du topic en cours...
- Je ne redéclare jamais dans les .h les méthodes "classiques de Cocoa" genre awakeFromNib: ou windowControllerDidLoadNib: ou dealloc: ou autre
- Il m'arrive, mais rarement, de redéclarer dans le .h une méthode qu'une classe parent, mais en général ce n'est pas sur une classe parent Cocoa (mais sur une classe qui dérive d'une classe à moi ou d'une classe d'un framework). Et dans ce cas je sais que ce n'est pas du tout utile, et que le seul but c'est l'aspect documentaire, pour avoir rapidement sous les yeux les déclarations sans chercher partout.
- Et ça m'arrive d'ailleurs de les supprimer ensuite (ou de les commenter) une fois que je commence à les connaà®tre car du coup je ne les trouve plus utile.
Donc après tout est une question de préférences et d'habitudes, chacun fait comme il veut. Perso, des codes sources que j'ai déjà eu entre les mains j'ai rarement (voire jamais à mon souvenir) vu, pour prendre un exemple typique, les awakeFromNib: ou dealloc: redéclarés dans le .h des classes...
Bon je vois que le temps de rédiger, comme à mon habitude, je me suis fait griller... Et je pense que la citation de la page 12 est une très bonne conclusion : si on surcharge une méthode, ça peut avoir du sens et faire plus propre de la redéclarer dans le .h aussi. Par contre si la méthode n'était même pas implémentée dans les classes mères, c'est moins utile... Ah mince, ça s'applique pas pour [tt]dealloc:[/tt], ce truc... grml ;D
Je viens seulement de découvrir l'interface pour séparer des messages "choisis" dans un sujet donné. Vu que ce n'est pas un modèle d'ergonomie, n'hésitez pas à me le signaler* avant de revenir dans le droit chemin (dans quel cas, je peux utiliser "séparer après ce message" et ça ne prend que quelques secondes).
*par MP ou mieux en utilisant le bouton "signaler" comme ça j'ai un lien direct du message à partir duquel il faut séparer: dans ces 2 cas, je suis averti par mail (qui sont relevés bien plus souvent que je ne visite le forum).