Comment organisez-vous vos classes ?
colas_
Membre
Créez-vous des dossiers dans le finder pour grouper vos classes ?
Ou bien, utilisez-vous seulement les "groups" ?
Enfin, utilisez-vous beaucoup les "groups" ?
Du genre :
-> monApp
|____> Model
|_________> CoreDataClasses
|________________>ForHuman
|________________>ForMachine
C'est-à -dire faà®tes-vous plein de sous-groups, sous-sous-groups, etc.
Je vous pose cette question pour avoir l'avis de développeurs cocoa confirmés et connaà®tre les bonnes pratiques et les défauts des différentes pratiques.
J'ai essayé de garder mes classes organisées dans le finder, mais quand j'ajoute les fichiers avec l'option "Create folder references for any added folder", les dossiers sont bleus au lieu de jaune et surtout : il ajoute les dossiers dans les "compile sources" au lieu d'ajouter les .m. Du coup, les .m ne sont pas compilés.
Merci !
Réponses
Bonjour,
Pour ma part, si c'est un projet simple j'organise de cette façon
->monApp
AppDelegate.h
AppDelegae.m
|_______> Screens
|__________>UICustom
|_______>Model
|__________>Managers
|__________>Stores
|_______>Objects
Le répertoire Screens identifie les écrans mais également le fait qu'on travaille sur du View - Controller
K.
Perso en général je fais correspondre les Groups que je crée dans Xcode avec les dossiers dans le Finder.
Sauf quelques rares cas où je crée des groupes dans Xcode très bas niveau (genre grouper des classes qui pourraient aller ensemble mais j'ai voulu affiner mon groupement dans Xcode encore +), mais en général je préfère que ça corresponde entre Xcode et le Finder.
Les groupes (et donc dossiers) que je retrouve régulièrement dans la plupart de mes projets :
Groupe du nom de l'appli
|-- Classes
| |-- Services
| | '--- Un groupe par "Service" (cf ci-dessous (1))
| |-- Model
| | |-- Mon DataModel CoreData, si j'utilise CoreData
| | '-- Un groupe par classe modèle
| |-- ViewControllers
| | |-- "Generic" : groupe contenant les UIViewControllers génériques de mon appli (NavigationController custom, Container View Controller customisé, ...)
| | |-- Un groupe par UIViewController/écran de mon appli, contenant le .h, le .m et le .xib correspondant
| | '-- Parfois je groupe ces "groupes de VC" par thème (suite d'écrans genre "Tutorial", etc)
| |-- Cells
| | '-- Un groupe par UITableViewCell customisée (NB parfois je les mets aussi dans le groupe précédent avec les ViewControllers associés, mais souvent mes UITableViewCell sont utilisées par plusieurs UIViewControllers différents)
| |-- Widgets
| | '-- Un groupe par composant UI customisé/réutilisable (par exemple si je fais une UIView réutilisable pour afficher une bulle d'aide, ou pour afficher un encart avec les infos d'un utilisateur, ou pour afficher une liste d'autocomplétion...)
| '-- Tools
'-- Un groupe par classe utilitaire, en général des catégories (genre catégorie sur NSString pour encoder une chaà®ne en Base64 ou calculer son MD5, catégorie sur NSDate pour avoir le texte relatif de la date façon "il y a 1h" ou "il y a 3 jours" ou "demain"..., etc, etc) ou encore des classes pour gérer mes préférences application (wrapper autour de NSUserDefaults), ce genre de trucs
|-- Resources
| |-- data : mes fichiers de données '(Localizable.strings, des PLIST de données...)
| '-- images : mes images, en général groupées avec un groupe par thème d'images (pictos, tabIcons, frames, ...)
|-- Supporting Files
'-- Les fichiers Info.plist, main.m, Icon, Default, Prefix.pch...
Stubs
'-- Mes bouchons pour tester l'appli même si le serveur (via OHHTTPStubs) n'est pas prêt/fini ou down. Un groupe par thème de bouchon
UnitTests
|-- Fixtures : Mes fixtures (fichiers de données type PLIST ou XML utilisés comme inputs ou outputs pour les tests U)
'-- Un groupe par thème de test unitaire, avec un ".m" par "Test Suite"
Frameworks
'-- Les frameworks utilisés par mon projet (".frameworks" Apple et libs ".a" externes)
(1) Ce que j'appelle "Service" ci-dessus ce sont en général des singletons (enfin pour être précis, des classes avec une sharedInstance) fournissant des "services" au sens large.
- Typiquement j'en ai souvent de toute façon un pour communiquer avec mon serveur (par exemple une méthode +[MyService fetchUsersList] qui va envoyer la requête asynchrone pour demander à mon API serveur de me retourner la liste des utilisateurs, ce genre de méthode retournant chez moi en général un handler immédiatement (requête asynchrone), handler me permettant d'annuler la requête, de lui associer un completionBlock pour être prévenu de son succès ou son erreur...)
- Je peux avoir d'autres services, par exemple j'ai souvent ReachabilityService pour tester la connectivité de mon appli, parfois un UpdateService si j'ai un service pour vérifier la présence de mise à jour... etc, etc Bref, tu vois l'idée que je mets derrière "Service".
Bien sûr, tout ça et toute cette arborescence c'est pour le xcodeproj de mon appli. A côté dans le même workspace si j'ai les xcodeproj qui génèrent mes librairies externes, comme j'ai déjà expliqué dans ma conférence CocoaHeads Rennes #12 (voir aussi sur ce forum où j'en parle)
Je ne fais que des projets simples et j'utilise des groupes qui (normalement) correspondent à des dossiers de même nom dans le dossier du projet. L'architecture des groupes du projet est alors très semblable à l'architecture des dossiers dans le dossier projet.
Mais appDelegate par exemple reste en dehors des dossiers. Voir un exemple ci-dessous.
A noter que Classes, Lesvues et Prefs contiennent des classes triées suivant leur rôle.
Hello,
Je fais correspondre les groups avec l'architecture de mes dossiers (sauf le group supporting files).
En gros :
|- Ions & Art Works (pour les images "default" par exemple)
|- Themes (contient une classe abstraite permettant de customiser mon interface)
| |- Default (theme par défaut pour mon interface, avec les png qui vont bien)
|- Classes
| |- Utils (classe contenant des singletons, des classes category)
| |- UI (Clases pour tous mes view controllers, avec des sous dossiers par fonction)
| | |- Common (contient les view controllers génériques, par exemple un UITableViewController pour core data)
| |- DataModel (contient mon modèle de données)
|- Supporting files (contient les fichers .strings et quelques xib)
L'option à utiliser est : Recursively create groups for any added folder
la je suis sous Xcode 3.2.6 et j'espère que cette option existe toujours sous xCode 4.xx.
Pareil qu'Alligator à peu de choses près. Et j'insisterai bien plus que lui quant à la conservation de la même hiérarchie dans le Finder... Quand je vois des projets avec tous les fichiers à la racine, j'ai souvent peur d'aller voir le code qui doit être tout autant bordélique
Oui si tu fais "Create folder references for any added folder" ça va créer des dossiers y compris au sein de ton Bundle final.
Par exemple si tu as un dossier "images" et que tu l'ajoutes à ton projet Xcode ainsi, tu auras un dossier "images" avec icône bleue dans ton xcodeproj, et quand tu vas compiler ton appli au lieu que les images se mettent directement dans "Resources" et que tu puisses utiliser "[UIImage imageNamed:...]", le dossier "images" va aussi se retrouver dans le bundle de l'appli avec ses fichiers images dedans, au lieu qu'elles soient à la racine de "Resources", et du coup "imageNamed:" ne marchera pas si tu lui fournis le nom de l'image, etc...
Donc en général, ce "Create folder references" n'est vraiment pas ce que tu veux. Rares sont les cas où tu veux des "dossiers bleus" dans Xcode au final. Dans 99.9% des cas c'est bien "Recursively create groups for any added folder" qu'il faut choisir.
Pareil que Ali, peut-être en moins poussé mais j'aime que tout soit correctement organisé et link vers le Finder de manière transparente et directe.
Je vois que nous sommes tous un peu maniaque. Euh, dans le bon sens du terme bien sur!
Pas maniaques, organisés
Perso, voici mon organisation sur mon dernier projet.
@xyloweb
Les questions sont: gardes-tu une organisation dans "Finder" identique à celle que tu montres dans le projet?
Ou bien l'organisation des dossiers dans le finder est-elle totalement différentes de l'organisation interne du projet?
Pareil qu'Ali
(bon en fait ce n'est pas vrai, mais c'est juste pour me faire bien voir)
Pareil que Smy ;-)
à‰dit : Céroce, t'avais pas le droit de poster 2 ms avant moi !
Bande de copieurs
J'organise mon suivant mon envie, mais surtout en fonction de l'application : pas besoin de faire 36 "séparations" si y'a pratiquement rien.
Je n'ai pas d'organisation spécifique, même si j'ai tendance à appeler toujours de la même manière le groupe des images etc.
Par contre, au niveau Finder, c'est un vrai b*rd*l, Idesroziers ferait une crise cardiaque, mais tout est rangé via le "Group" quand on ouvre le projet avec XCode.
D'ici peu de temps je ferais correspondre Group & Folders, histoire de faire plus propre.
Comme Larme !!!!
Ben c'est à peu près la même chose dans le Finder avec un regroupement par type de classe.
Le gestionnaire Xcode fait le reste...
Je ne me préoccupe pas du Finder, je laisse xcode se débrouiller.
Voici comment je me suis organisé :
Question naà¯ve, à quoi cela vous sert que ce soit organisé dans le finder ?
Pour ma part j'utilise l'organisation en sous-dossiers plutôt pour coller à l'organisation en modules / sous-modules du gestionnaire de version. Ce qui fait que l'organisation en sous-dossiers peut être différente de l'organisation en groupes sous Xcode qui regroupe toutes les images indépendamment de leur module d'appartenance, par exemple.
Moi, ça ressemble à ça:
Ca n'est pas rangé par ordre alphabétique !
Pas a grand chose pour moi ...
Moi ça me sert à être iso par rapport à ce que j'ai sur le projet et ce que j'ai dans le Finder. Tu peux tout mettre dans une seul dossier dans le Finder et ensuite rangé en groupe dans ton projet mais je sais pas ... ça fait pas propre je trouve.
Ca me sert à :
- Etre organisé dans le Finder aussi et être cohérent, y compris pour mes collègues qui bossent avec moi sur le projet
- Retrouver facilement dans le Finder mes fichiers quand j'en ai besoin
- àŠtre cohérent avec mon système de gestion de version, y compris avec les éventuels submodules utilisés
Après c'est sûr on peut s'en passer et tout foutre en vrac dans le Finder, mais ça fait un peu brouillon quand même ^^
Pas grand chose dans l'absolu. Pour ma part je pense que cette manie d'organisation vient de mes années sur Unix. Du coup j'ai pris l'habitude de faire des dossiers. Il est vrai cependant que je ne vais que rarement piocher dans le finder.
Non, c'est rangé par ordre d'importance des fichiers utilisés.
Donc les dossiers du haut sont plus souvent ouverts que ceux du bas.
N'empêche c'est con qu'Apple propose pas une option pour garder une arborescence Finder identique à celles des groupes Xcode.
Le must serait même de pouvoir activer ou non cette option par groupe...