Organisation des macros, constantes et autres imports
muqaddar
Administrateur
Salut,
Je voulais savoir comment vous organisiez vos fichiers de macros, constantes ou autres.
Au départ, je mettais tout dans prefix.pch. Seulement, avec le temps ce fichiers s'est alourdit... (+ de 400 lignes).
Donc, je voulais savoir quelles habitudes vous aviez pour diviser ce genre de choses (sachant que des macros génériques, des contantes, ou même des imports de sous-classes et/ou catégories peuvent évidemment être utilisées par une multitude de classes et qu'il faudra donc les importer là où c'est nécessaire).
Je voulais savoir comment vous organisiez vos fichiers de macros, constantes ou autres.
Au départ, je mettais tout dans prefix.pch. Seulement, avec le temps ce fichiers s'est alourdit... (+ de 400 lignes).
Donc, je voulais savoir quelles habitudes vous aviez pour diviser ce genre de choses (sachant que des macros génériques, des contantes, ou même des imports de sous-classes et/ou catégories peuvent évidemment être utilisées par une multitude de classes et qu'il faudra donc les importer là où c'est nécessaire).
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
1) Tout dans le .pch au début
2) Quand il commence à y en avoir beaucoup et que je veux faire le ménage, je déporte ça dans plusieurs autres fichiers .h (LogMacros.h, StringMacros.h, ...) et je #import ces ".h" dans le pch :P
Par contre après je mets pas toujours tout dans le .pch (ou dans les .h importés depuis le .pch)
Par exemple les catégories il m'arrive de m'obliger à faire le #import là où j'en ai besoin (surtout si c'est pas partout) plutôt que les #import dans le .pch ou un des .h qu'il importe.
Les constantes style noms de NSNotification (MachinDidChoseNotification, ...), noms des clés de dictionnaires (TrucUserInfoTitleKey, TrucUserInfoAuthorKey, ...) et tous les trucs qui sont par nature associés à une classe donnée (la classe qui émet la notification, la classe qui déclare l'objet générant le userInfo dont j'utilise les clés, ...) je les laisse dans les fichiers des classes associées à ces constantes. Un peu comme quand je déclare un @protocol pour prévoir un delegate pour ma classe, je le déclare dans le .h de la classe qui l'utilise (celle qui déclare une ivar delegate, et qui envoie les messages du @protocol au delegate)...
Ah, OK, c'est ça que je voulais savoir !
Ok, oui c'est le mieux.
Ok, j'y vois plus clair et je vais découper tout ça parce que c'est devenu la foire. :P
En plus comme je partage des choses entre versions iPad et iPhone, et d'autres non, y'a intérêt à faire très attention et s'organiser !
De même les méthodes communes à l'ensemble d'un projet sont mises dans une catégorie de NSApplication et le .h de la catégorie est également importé dans le .PCH
Les mettre au plus près de de l'endroit ou elles sont utilisées.
Juste au-dessus d'une fonction, si elles ne sont utilisées que dans la fonction.
En haut d'un .m si plusieurs fonctions du .m y accédent.
Dans le .h d'une classe, si elles font partie de l'interface de la classe.
Dans le dossier d'un module, si elles sont communes à plusieurs classess du module.
Dans un .h global si elles sont utilisées plus largement que les cas précédent.
Dans une grosse appli, faite en équipe, c'est bien de prevoir un decoupage à l'avance de l'arborscence du projet et décider où on va mettre les constantes, etc afin que chaque module soit homogene.
Dans une appli iPhone, j'imagine que ça peut vite devenir le bordel car on peut se faire pièger par la rapidité du developpement, les nouvelles fonctionnalités pas forcément prévue mais qui semble bien marcher chez les autres, ou même les nouvelles api d'apple.
D'ailleurs je n'ai jamais vu de SDK aussi dynamique, tous les 6 mois il y a des nouveaux frameworks.
C'est vrai que l'approche des .h de constantes est la plus modulaire possible (comme le disait Ali aussi).
Il peut s'avérer que des classes différentes aient besoin des mêmes constantes mais que les autres n'aient pas besoin de les connaà®tre, exit donc de les mettre dans le .pch ou de les importer dans ce .pch. Il faudra donc importer le fichier dans les classes qui en ont besoin.
Tiens. Tu as des exemples de méthodes où ça peut servir ?
Oui mais ce n'est pas genant car c'est explicite. Quand il y a un compromis à faire, je choisis souvent la solution la plus explicite.
Je prefere avoir vingt lignes d'include par fichier que de tout mettre dans le .pch car cela permet de savoir ce qu'une classe utilise. Si elle va etre facile a reutiliser dans un autre projet ou pas.
Bon si t'as vingt lignes d'include, tu sais que quand tu vas vouloir reutiliser la classe, tu vas tirer tout le plat de spaghetti avec.
Bon, j'ai commencé le ménage. :P