Usage détourné de NSDictionary ?
aLittleWoodElfe
Membre
Bonjour,
Je voudrais savoir si il existe des contre indications à faire la chose suivante :
Dans mon appli je manipule des objets qui possèdent beaucoup de champs internes et quelques méthodes utilisant ces champs pour retourner des booléens. J'ai donc le choix entre définir 10 NSString comme variables d'instances ou bien encapsuler un NSDictionary qui contiendra ces variables.
Dans les deux cas je vais me retrouver avec un paquet d'accesseurs à définir et au final un nouvel objet qui dans les faits n'est qu'un NSDictionary avec quelques méthodes supplémentaires
D'où mon idée de remplacer chacune de mes anciennes classes d'objets par une catégorie qui va simplement étendre les méthodes de la classe NSDictionary, ainsi je ne m'occupe plus des accesseurs puisque j'utilise les méthodes de NSDictionary et mes anciennes méthodes de classe je les appelle directement sur mes NSDictionary.
Pour le moment tout marche sans problème, mais je n'ai vu nulle part cette façon de faire alors je me demande si je n'ai pas raté une raison évidente de ne pas faire ainsi ?
Je voudrais savoir si il existe des contre indications à faire la chose suivante :
Dans mon appli je manipule des objets qui possèdent beaucoup de champs internes et quelques méthodes utilisant ces champs pour retourner des booléens. J'ai donc le choix entre définir 10 NSString comme variables d'instances ou bien encapsuler un NSDictionary qui contiendra ces variables.
Dans les deux cas je vais me retrouver avec un paquet d'accesseurs à définir et au final un nouvel objet qui dans les faits n'est qu'un NSDictionary avec quelques méthodes supplémentaires
D'où mon idée de remplacer chacune de mes anciennes classes d'objets par une catégorie qui va simplement étendre les méthodes de la classe NSDictionary, ainsi je ne m'occupe plus des accesseurs puisque j'utilise les méthodes de NSDictionary et mes anciennes méthodes de classe je les appelle directement sur mes NSDictionary.
Pour le moment tout marche sans problème, mais je n'ai vu nulle part cette façon de faire alors je me demande si je n'ai pas raté une raison évidente de ne pas faire ainsi ?
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Je définis dans ma classe Modèle un dictionnaire avec 10 clefs, et je n'ai qu'un accesseur à faire.
Voir mon projet Vidéothèque 02 pour le code. Les instances de la classe Film ne déclarent qu'une variable : un dictionnaire propriete, avec les clefs @titre, @réalisateur, etc. Dans Film.m , un seul accesseur.
En fait, en y réfléchissant sur mon (petit) projet où je suis seul à travailler ça devrait aller, mais dans le cas de projets plus important c'est certainement une mauvaise idée pour les raisons suivantes :
-Si j'ai plusieurs objets que j'émule ainsi je vais définir plusieurs catégories pour NSDictionary, je vais forcément finir par me retrouver confronté à des noms de méthodes se retrouvant d'une catégorie à l'autre.
-De plus je n'ai aucun moyen de savoir à la compilation ou à l'éxécution que mon NSDictionary est effectivement en mesure de répondre à la catégorie que je lui applique. Seul moi le sais parce que dans mon code je sais que tel NSDictionary a été contruit de telle manière. Mais c'est relativement illisible pour un autre programmeur.
Donc finalement ce n'est pas vraiment une bonne idée. Il n'émpêche que j'adore les catégories, c'est un des points forts de l'obj-C par rapport à Cocoa )
C'est pourtant une des recommandations que j'avais lues quelque part (o'reilly ?), lorsque j'ai commencé à apprendre Cocoa. Pour les objets de bases, tels les dictionnaires et les listes, il vaut mieux créer une classe qui les utilise que d'essayer de créer une sous-classe. Les catégories ne sont pas à proprement parler une sous-classe, mais pas loin tout de même.
Ceci-dit, j'ai peut-être mal compris.
Oui absolument, je suis d'accord.
Ben non je ne trouve pas, justement les catégories permettent de ne pas avoir à sous classer pour ajouter des méthodes. Si on évite de sous classer c'est pour ne pas avoir à redéfinir tout un tas de méthodes, souvent internes, de la classe de départ (ce qui trés difficile à faire pour la majorité des classes cocoa du fait que ce sont souvent des clusters de classes en réalité).
Je suis du même avis que Tiff..
Avant de créer une spécialisation (par héritage ou catégorie) de la classe NSDictionnary, il faut se poser la question si la nouvelle classe est une sorte de NSDictionnary (cas ou il veux mieux spécialiser) ou ne fait que utiliser NSDictionnary (cas ou il vaut mieux encapsuler)..