›

Organisation classe Open Source

JegnuXJegnuX Membre
juillet 2012 modifié dans Objective-C, Swift, C, C++ #1
Salut à  tous,



Je suis sur le point de mettre sur github une classe que je me suis faite, mais je me posais une question...



En fait y'a trois classes, mais une seule est vraiment utile, les deux autres étants utilisées par la première, et n'ont pas vraiment d'intérêt à  être utiliser hors contexte.



Du coup je sais pas quoi faire :



- Utiliser un seul couple de fichier .h/.m et je met l'interface et l'implémentation de ces deux classes dans le .m

- Utiliser un couple de fichier .h/.m par classe.



ou éventuellement :

- Utiliser un seul couple de fichier .h/.m et je met l'interface de ces deux classes dans le .h et l''implémentation dans le .m





En gros, préférer la lisibilité du code, ou la facilité à  inclure ma classe dans un projet ?

Réponses

  • AliGatorAliGator Membre, Modérateur
    #2
    Si tes deux classes secondaires sont des classes "privées" et que l'utilisateur de ta classe principale n'est vraiment pas sensé connaà®tre leur existence et les utiliser par lui-même (seule l'implémentation interne de ta classe l'utilise, et le couplage est fort entre la classe principale et les 2 classes privées), je mettrais l'interface et l'implémentation des classes privées dans le .m
  • JegnuXJegnuX Membre
    #3
    Ok ok, c'est ce que j'allais faire mais j'étais pas contre un avis externe image/smile.png' class='bbc_emoticon' alt=':)' />
  • AliGatorAliGator Membre, Modérateur
    #4
    Bah franchement j'ai pas non plus un avis tranché sur la question, j'hésiterais aussi ^^
  • CéroceCéroce Membre, Modérateur
    #5
    Fais surtout gaffe que les noms de tes classes commencent par un préfixe. Il n'y a pas de namespace en Objective-C.

    Après, je te dirais que j'aime autant qu'il y ait un .h par classe. Ce qui compte c'est que la doc indique clairement quel .h doit être importé.
  • JegnuXJegnuX Membre
    #6
    Oui oui t'inquiète, j'ai mon petit JX- image/wink.png' class='bbc_emoticon' alt=';)' />
  • SystemSystem
    #7
    Très honnêtement, que ça soit OpenSource ou non, tout dépend de la quantité de code contenu dans ces classes privées.

    Pour du gros code privé je privilégie la création de nouveaux fichiers. Quand il s'agit de compiler sous forme d'une library il suffit d'indiquer qu'on ne souhaite pas exporter les headers de nos classes privées.

    Concernant le cas d'un projet Open Source, la même chose s'applique mais pour une raison différente: la lisibilité du code. Même si c'est privé, le but de l'Open Source c'est aussi que chacun puisse éventuellement contribuer, que ça soit dans son coin ou publiquement. Donc niveau re-lecture du code, avoir une classe ou plusieurs classes privées dans des fichiers dédiés ne pose pas de problème, tant que la notation est explicite:


    JXToto.h

    JXToto.m

    _JXCeintureDeChastete.h

    _JXCeintureDeChastete.m




    Rien que le fait de voir ce underscore avant le namespace suffit à  faire comprendre qu'il s'agit d'une classe privée.
  • JegnuXJegnuX Membre
    #8
    Le truc c'est que moi quand je prend une classe sur github, ça me saoule quand y'a plusieurs fichier alors que au final y'a juste une classe que je veux utiliser.



    Si on regarde JSONKit par exemple, y'a qu'un seul couple .h/.m pour tout.
  • SystemSystem
    #9
    Oui enfin tu crées un dossier "Private" et voilà . ça s'appelle de l'organisation.
  • JegnuXJegnuX Membre
    juillet 2012 modifié #10
    Certes, mais à  importer dans un autre projet je trouve ça plus chiant. ^^



    après, avec tout dans un seul fichier, mon .m fait toujours moins de 1000 lignes. C'est pas non plus le seigneur des anneaux.
  • AliGatorAliGator Membre, Modérateur
    #11
    En même temps, tu fais des libs quand tu importes du code externe, non ?

    Moi je fais toujours des libs avec des projets séparés dans le workspace de mon appli.

    Au niveau organisation de code, lisibilité, ça change tout... mais aussi au niveau navigation dans le code, et surtout au niveau des project settings



    Par exemple, quand je veux utiliser AFNetworking dans mon appli, dans mon xcworkspace je fais un nouveau projet de type "Static Library" que je nomme AFNetworking.xcodeproj. Je met dans ce nouveau projet Xcode tous les fichiers de AFNetworking (récupérés sur le github de AFN). Puis dans mon projet principal MonAppli.xcodeproj (qui est dans le même workspace), dans la Build Phase "Link with binaries", je rajoute libAFNetworking.a (qu'il détecte tout seul et me propose en tout premier dans la liste quand je clique sur le "+")



    Les avantages sont super nombreux :
    • Ca ne pollue pas mon projet MonAppli.xcodeproj et c'est mieux organisé. Je n'ai pas des fichiers qui trainent partout dans mon arbo projet
    • C'est facilement réutilisable dans une autre appli. Si je veux utiliser AFNetworking dans une autre appli, j'ai juste à  rajouter AFNetworking.xcodeproj dans le workspace de l'autre appli
    • Si je recherche dans mon code tous les NSOperationQueue par exemple, je peux ne faire cette recherche que dans mon propre code, en focalisant la recherche uniquement sur le projet MonAppli.xcodeproj. Il ne risque pas de me polluer les résultats de la recherche avec toutes les occurrences de NSOperationQueue qui se trouvent dans AFNetworking.
    • Si je dois mettre à  jour AFNetworking, ça se fait très facilement également
    • Comme mentionné par ldesroziers, tu peux en plus indiquer quels headers rendre public et lesquels doivent rester privés. Ce qui t'évite de risquer d'utiliser un header privé de AFNetworking dans ton appli.
    • Mais surtout, surtout, ça te permet d'avoir des réglages de projet indépendants. Et ça, en particulier avec ARC, c'est vraiment utile. Par exemple AFNetworking n'est pour l'instant pas ARC. Si ton propre projet est ARC, pas de problème : tu as deux xcodeproj indépendants, ça ne va pas te gêner, chacun vis ça vie avec ses settings propres. Alors que si tu mettais tous les fichiers .m dans un seul gros xcodeproj, c'est la galère, faut mettre le flag -fobjc-no-arc en face de tous les .m de AFNetworking et pas en face des autres.


    Et franchement, c'est rien à  faire. Avec Xcode4 et les workspace, tout est assez rapide et assisté.

    - A créer le projet pour la lib t'as rien à  faire ou presque. Tu crées un nouveau projet de type "Static Library", tu mets tes fichiers dedans, et basta t'as une lib.

    - A importer dans un autre projet du coup c'est une histoire de simple glisser-déposer du xcodeproj dans le workspace + ajouter la lib dans les Build Phases du projet de ton appli, et c'est tout (ça c'est bien simplifié avec les workspaces par rapport à  Xcode 3 !)



    Franchement je vois pas pourquoi s'en priver image/wink.png' class='bbc_emoticon' alt=';)' />
  • JegnuXJegnuX Membre
    #12
    Je suis globalement d'accord avec toi Ali, je fais ça pour les grosse librairies.



    Après par exemple quand c'est des petites classes genre, AU HASARD, OHAlertView, je trouve que ça fait beaucoup de mic mac pour pas grand chose...
Connectez-vous ou Inscrivez-vous pour répondre.