›

Déclaration des méthodes dans l'extension de la classe.

samirsamir Membre
dans API UIKit #1

Bonjour,


 


j'ai une question par rapport aux déclaration des méthodes privées en objective C ( bon y a pas vraiment de méthode privées mais bon...). 




@interface MyClass ()

-(void)foo;

@end



@implementation ;MyClass 



-(void)foo{

...

}

@end ;

Est-ce que vous déclarer toutes les méthodes (foo par exemple) dans l'extension de classe ? le pourquoi m'interesse plus que oui/non :)


Réponses

  • CéroceCéroce Membre, Modérateur
    #2

    Non.


     


     


     


     


     


     


     


    Ah oui, pourquoi pas ? Parce que ce n'est plus nécessaire, alors ça m'évite de faire du copier-coller pour avoir une correspondance exacte et surtout, de devoir corriger le prototype à  chaque fois que je le change dans la partie implémentation.

  • jpimbertjpimbert Membre
    #3

    Toutes les méthodes privées, oui.


    C'est la pratique recommandée par Apple, et je n'ai pas cherché plus loin.


  • samirsamir Membre
    #4

    Merci.


     


    Deux réponses, deux avis différents :).


     


    @jpimbert t'as le lien de documentation ou Apple recommande cette pratique STP ? Merci.

  • jpimbertjpimbert Membre
    #5

    Dans le guide Programming with Objective-C, dans le chapitre Customizing Existing Classes, section Use Classe Extensions to Hide Private Information.


  • SystemSystem
    #6

    Pour la lisibilité du code je trouve ça mieux de déclarer les méthodes privées quand même. Mais j'avoue que des fois j'oublie un peu et je préfère faire un #pragma mark spécifique à  l'implémentation des méthodes privées


  • AliGatorAliGator Membre, Modérateur
    #7
    Avant je le faisais. Et à  tous les coups j'en oubliais parfois, donc étais obligé de faire des copier/coller de ceux qui manquaient quand je m'en apercevais (= quand j'avais des warnings, ce qui n'étais pas toujours le cas selon l'ordre des déclarations et des appels)

    Maintenant que ce n'est plus nécessaire, je ne le fais plus car justement sinon à  tous les coups au fur et à  mesure qu'on rajoute des méthodes on oublie de les remonter. Et rien de pire que d'avoir une liste incomplète (mais sur laquelle on se base quand on lit notre code car on la croit complète) : puisqu'elle est vouée à  être incomplète car à  tous les coups on va en oublier, autant ne pas en avoir plutôt qu'en avoir une jamais à  jour.

    Par contre je continue d'utiliser les extensions de classe quand c'est nécessaire. Par exemple quand je veux déclarer une @property qui est privée, ou encore pour redéclarer une @property qui était readonly dans l'API privée (=.h) mais doit être readwrite en interne (en fait je crois que c'est les 2 seuls cas que je vois où c'est nécessaire)
  • samirsamir Membre
    #8

    Merci pour vos réponses.


     




    (en fait je crois que c'est les 2 seuls cas que je vois où c'est nécessaire)




     


    Je peux rajouter un troisième dans le cas ou on veux tester les méthodes privées ( test unitaires), au lieux de mettre tout dans le .h de la calasse, moi je construit une extension de ladite classe dans un .h et je met dedans toutes les méthodes/property  privées a tester. et bien sur importer ce .h dans les deux targets.

  • AliGatorAliGator Membre, Modérateur
    juin 2013 modifié #9
    Ah oui en effet, je fais ça effectivement pour les TU aussi, bien vu.
    Déclaré séparément dans un MaClasse_private.h (ou MaClasse+private.h selon l'humeur)
  • jpimbertjpimbert Membre
    #10

    Puisqu'on en est à  partager ses petites manies, MaClasse_private.h pour une extension et MaClasse+Private.h pour une catégorie qui s'appellerait Private.


Connectez-vous ou Inscrivez-vous pour répondre.