Usage détourné de NSDictionary ?

23:18 modifié dans API AppKit #1
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 ?

Réponses

  • TiffTiff Membre
    23:18 modifié #2
    Pas besoin de catégories, mais peut-être que c'est pratique ?
    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.
  • 23:18 modifié #3
    Je vois ce que tu veux dire Tiff, c'est l'une des solutions que j'avais envisagé, mais je trouvais dommage de faire un objet pour juste encapsuler un autre objet. Du coup sur le moment l'utilisation des catégories me semblait plus élégant et plus rapide.

    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 :o)
  • TiffTiff Membre
    23:18 modifié #4
    "
    dans 1086680619:

    Mais je trouvais dommage de faire un objet pour juste encapsuler un autre objet.


    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.
  • 23:18 modifié #5
    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.

    Oui absolument, je suis d'accord.


    Les catégories ne sont pas à proprement parler une sous-classe, mais pas loin tout de même.

    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é).
  • nucleusnucleus Membre
    23:18 modifié #6
    dans 1086685774:

    "
    dans 1086680619:

    Mais je trouvais dommage de faire un objet pour juste encapsuler un autre objet.


    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.


    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)..
Connectez-vous ou Inscrivez-vous pour répondre.