Petite question à Propos du type enum
Greensource
Membre
Bonsoir!
Comme tout le monde j'utilise des type enum parfois. Là je me pose une petite question, si j'ai envi d'associé à chaque élément du type enum, disons une NSString, je vais avoir besoin d'un fonction avec un bon gros switch.
Mais où je met une tel méthode pour que mon architecture reste bien foutu?
Moi j'ai pour habitude de faire un .h qui se charge de déclarer mes enum. J'aimerais bien n'avoir à importer que ce fichier .h lorsque j'utilise mes enum.
Or si j'ai une fonction ailleurs qui associe un NSString à chaque élément de mon enum je serais aussi obliger de l'importer...
Vous faites comment vous?
Comme tout le monde j'utilise des type enum parfois. Là je me pose une petite question, si j'ai envi d'associé à chaque élément du type enum, disons une NSString, je vais avoir besoin d'un fonction avec un bon gros switch.
Mais où je met une tel méthode pour que mon architecture reste bien foutu?
Moi j'ai pour habitude de faire un .h qui se charge de déclarer mes enum. J'aimerais bien n'avoir à importer que ce fichier .h lorsque j'utilise mes enum.
Or si j'ai une fonction ailleurs qui associe un NSString à chaque élément de mon enum je serais aussi obliger de l'importer...
Vous faites comment vous?
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
J'y vois un intérêt dans du réseau ou de la communication inter process, ça simplifie l'échange de donnée, pour le reste j'avoue que je suis dubitatif
Si on gardait une chaà®ne, on ne pourrait pas utiliser le principe de masquage avec les & et | bits à bits si on en a besoin, et on ne pourrais pas faire de switch/case, et seraient réduits à faire un [tt]if ([... isEqualToString:...]) / else if isEqualToString / else if isEqualToString / ...[/tt]
Après bien sûr pour mon exemple de "MacTypes.h", l'intérêt est loin d'être flagrant. Mais dans un projet sur lequel je suis en train de travailler, où il faut gérer plein de use cases en fonction de ces valeurs, etc... C'est non seulement bien plus efficace mais aussi bien plus lisible (grace aux switch/case mais aussi au fait qu'on peut juste faire un "==" ou "!=" au lieu de isEqualToString) d'avoir des enums.
Surtout que pour un cas je peux aller plus loin et faire une comparaison "<" car je sais que tous les enums avant cette valeur sont des cas "simples", et les enums après cette valeur sont des cas qui ont besoin d'un traitement particulier...
Bref, ça dépend des cas, bien souvent un [tt]static NSString* const kMachin = @truc;[/tt] est tout aussi efficace, mais dans bien d'autres cas un enum est quand même bien plus pratique. Et dans ce cas une fonction pour la convertir en NSString*, essentiellement pour le debug par exemple, est toujours pratique quand même.
Si tu n'as que ces fonctions là et donc que du C comme la fonction NSStringFromMacType(...), tu peux effectivement mettre ça dans un fichier à l'extension ".c", et le compilateur le compilera comme du C.
Si tu as en plus des méthodes Objective-C dans ce même fichier, il faut mettre une extension ".m" pour que le compilateur compile l'Objective-C.
Mais tu peux tout à fait mettre du code C dans un fichier ".m", puisque l'Objective-C est une surcouche du C et que tu peux tout à fait mixer C et Objective-C dans le même code.
Donc mettre a dans un .m ne pose aucun problème. Et perso c'est souvent ce que je fais car je n'ai en général pas que ça dans mon fichier, mais aussi des classes Objective-C qui me servent de conteneur pour manipuler des données, etc...
Ici c'est pas de simples NSString isolées qu'il faudrait mais un Array de chaines...
Sinon, comme Ali, j'apprécie tout particulièrement les switch-case
Mais les int rendent le code moins lisible et j'ai pris l'habitude de les remplacer.
En particuliers, mes fichiers .m de mes contrôleurs commencent souvent par une liste de define des tags ainsi:
Ce qui me permet des switch plus lisibles avec des "[tt]switch(tag)[/tt]" et des "[tt] case _TableView_Documents_ :[/tt]" toujours plus lisible que des "[tt]case 63 :[/tt]"
En plus de ça, ça a le mérite d'avoir un inventaire exhaustif de mes tags utilisés dans IB dans mon .m
un coup de
#define kMaConstante 10
et basta !
Sinon j'aime bien me faire aussi des énumérations de temps en temps, notamment pour définir des styles ou des types différents pour un élément d'interface, j'ai en effet remarqué que Apple faisait ça très souvent
C'est génial pour la clarté, par exemple, pour mes boutons de plein écran indépendant de la résolution, et qui me servent dans mon NavigationController perso, leur forme générale peut varier suivant leur "type" :
Encore trop de monde utilise des "magic numbers" (c'est comme cela qu'on appelle des nombres qui trainent dans du code source sans qu'on sache trop d'où ils sortent) au lieu de créer une constante, un #define ou équivalent. Donc oui, utilisez les static const (constantes locales à un bloc de code ou à un fichier), extern const (constantes app-wide, genre le nom d'une d'une notification perso que l'on poste dans le NSNotificationCenter), les #define, ... pour tout ça.
Les enum c'est plus pour un choix / liste de valeurs possibles (comme l'exemple de nebuchad34 pour choisir le type d'un bouton parmi 4 types possibles), pour définir un type avec une liste limitée de valeurs possibles.
Tout dépend donc du contexte et de l'usage. Mais en tout cas quelle que soit la solution qui convient le mieux à votre usage, enum, const, #define, ... ça sera toujours mieux qu'une valeur à traà®ner en dur dans le code. Non seulement parce que c'est beaucoup plus explicite qu'une valeur qui traà®ne toute seule sans explication, en plus parce que ça permet de ne changer cette valeur si besoin qu'à un seul endroit dans le code, et enfin parce que ça génère proprement des erreurs de compilation en cas de faute de frappe par exemple.
Ha mais non, mais non, moi je suis pas d'accord moi >:(
J'aurais plutôt dit ... heu ...
Enfin, pour les enum il aurait pu préciser que ... ah non, il l'a dit ça aussi ...
Ah ben si, tient, je suis d'accord en fait ;D
C'est dommage parce qu'un peu de désaccord aurait alimenté la discussion/réflexion ... mais si tout est dit alors ... OK
Là , t'es content, tu l'as ton désaccord ;D
Y'avais longtemps ça ! :-*
;D