Déclaration dans MaVue.h ou dans MonDocument.h ?

TiffTiff Membre
15:00 modifié dans API AppKit #1
Je dessine des bezierPath dans une vue. La gestion de la souris et du tracé est codée dans MaVue.m. Comme il y a plusieurs bezierPath, je déclare NSMutableArray *listeDesPaths dans MaVue.h.
Maintenant, je veux sauvegarder mes tracés. La classe MonDocument est là pour ça. Mais alors, est-ce que je dois déclarer listeDesPaths dans MonDocument.h au lieu de MaVue.h ?
Ou déclarer une autre liste, qui sera une copie de la première au moment de la sauvegarde ?

Réponses

  • nucleusnucleus Membre
    15:00 modifié #2
    Il faut le faire dans ton document (modele) plutôt que dans ta vue pour respecter le pattern Model-View-Controller..
    Séparer la gestion des données (Model) de sa représentation (View) permet une meilleure maintenabilité, une réutilisation des tes classes dans un autre contexte.. au final un gain de temps sur le long terme..

    Il faut garder en tête que la même instance d'un document doit pouvoir être représenté (differement ou pas) par plusieurs instances de vue differentes (ou pas).

    Pour faire encore plus propre, tu peux faire comme dans Cocoa, et définir un protocole d'accès aux données (Data source) que ton document va implementer et que ta vue va invoquer..
  • TiffTiff Membre
    15:00 modifié #3
    J'étais tombé sur un site qui proposait le contraire, laisser View s'occuper des données. Un lecteur s'était inquiété de la dérive : c'est le contrôleur qui est là pour ça.
    Le coup du data source me plait bien, je vais y penser, merci.
  • nucleusnucleus Membre
    15:00 modifié #4
    Non le controlleur n'est pas là pour gèrer les données, il est là pour coordonner les interraction entre le modèle et les vues..
    Dans Cocoa, NSDocument peut induire un peu en erreur dans l'utilisation standard car il mélange controlleur et modèle..
    On peut mieux séparer les deux en ayant sa propre implémentation de NSWindowController..

    Quelques phrases simples qui peuvent servir pour guider rapidement ta conception:
    • La vue est liée aux yeux de l'utilisateur (représentation graphique)
    • Le controlleur est lié aux mains de l'utilisateur (interraction avec souris, clavier..)
    • Le modèle est lié à l'esprit de l'utilisateur (concepts abstraits indépendants de l'interface utilisateur)


    Les explications Apple:
    http://developer.apple.com/documentation/Cocoa/Conceptual/AppArchitecture/Concepts/MVC.html
  • TiffTiff Membre
    15:00 modifié #5
    En théorie je te suis parfaitement mais en pratique...

    Reprenons depuis le début :
    Je veux dessiner des objets dans une vue :
    J'ai plusieurs classes Model : Cercle, Droite,...
    J'ai une classe Vue : maVue
    J'ai aussi la classe MyDocument.
    Je peux créer une sous-classe de NSWindowController si c'est nécessaire.
    Quelque part dans l'interface, l'utilisateur peut choisir entre Cercle et Droite

    Je veux avec la souris tracer des cercles ou des droites dans la vue et connaitre à chaque instant la distance entre le pointeur et les objets dessinés.

    Ma question est la suivante :
    Quelle classe va :
    s'occuper du flag cercle ou droite
    gérer les événements souris mouseMoved mouseUp etc
    s'occuper de l'inévitable liste des objets NSMutableArray *mesDessins , lui ajouter les objets au fur et à mesure et l'enregistrer dans un fichier
    calculer et faire afficher la distance entre le pointeur et l'objet le plus proche

    Est-ce une unique classe ? Ou sont-ce plusieurs ?

    Je connais, à peu près, le principe du Model-View-Controller, mais les infos que j'ai pu glaner sur les différents tuto mélangeant MyDocument et MyView ne sont pas clair sur ce point et certains se contredisent.
    J'avais commencé à décortiquer Sketch, puis j'ai laissé tomber par manque de temps. Mais est-il un bon exemple ?

  • nucleusnucleus Membre
    15:00 modifié #6
    dans 1085664394:

    En théorie je te suis parfaitement mais en pratique...
    (..;)


    En effet dans ton cas, ton modèle est composé de figures géométriques..  La frontière entre modèle est vue est forcement plus floue que dans une appli style base de données..

    dans 1085664394:

    Ma question est la suivante :
    Quelle classe va :
    s'occuper du flag cercle ou droite


    Je suppose que tu parles de boutons qui permettent de basculer entre un mode de création de cercles et un mode de création de lignes..
    Pour moi c'est le NSWindowController qui demande un changement de mode de fonctionnement de ta vue MaView..
    Ce n'est pas à la vue de changer de mode toute seule...
    (les design pattern State et Prototype pourrait t'être utiles)

    dans 1085664394:
    gérer les événements souris mouseMoved mouseUp etc


    Pour moi c'est ta classe MaView qui doit traiter les évenements bas niveau..
    Elle aurait la charge de les rafiner/transformer en evenements de plus haut niveau envoyé à un "delegate" (style maView:shouldSelectFigure:, mViewSelectionDidChange:)
    La classe MaView accèderait au modèle via une "datasource" pour récuperer les figures à dessiner (style numberOfFiguresInMaView:, maView:figureAtIndex:), savoir sur quoi on à cliqué (style maView:figuresAtPoint:)..

    Eventuellement si les objets figures ne savent pas se déssiner (c'est une possibilité qui accroit la réutilisation) le "delegate" permettrait de savoir comment les dessiner (style maView:willDisplayFigure:), en retournant un objet dans le style NSCell.

    dans 1085664394:
    s'occuper de l'inévitable liste des objets NSMutableArray *mesDessins , lui ajouter les objets au fur et à mesure et l'enregistrer dans un fichier
    calculer et faire afficher la distance entre le pointeur et l'objet le plus proche


    Gérer la liste des figures, assurer sa persistance, permette d'ajouter un figure à la liste, calculer la distance entre un point et un objet (pas besoin d'affichage pour faire des calculs): le modèle (NSDocument pour faire simple)
    Afficher la distance entre le pointeur et un objet, déclencher la sauvegarder, le choix de fichier: NSWindowController

    dans 1085664394:
    Est-ce une unique classe ? Ou sont-ce plusieurs ?


    Plusieurs!

    Personnellement, lors de la conception j'ai tendance à affecter des responsabilités aux classes..
    Si une classe à trop de responsabilité par rapport à d'autre, ou des responsabilités de nature trop différentes, cela signifie qu'il faut créer une nouvelle classe..
    Si une classe à peu ou pas de responsabilité, c'est qu'elle est peut-être inutile ou qu'elle peut être fusionnée avec une autre classe avec peu de responsabilités..

    dans 1085664394:
    J'avais commencé à décortiquer Sketch, puis j'ai laissé tomber par manque de temps. Mais est-il un bon exemple ?

    Je sais pas, j'ai pas regardé en détail ce que faisais Sketch..
    Mais si c'est une application de dessin (=informel), ce n'est pas forcement une architecture à reprendre telle quelle pour une application de géométrie (=formel), plus proche de la visualisation de graphe..

    Je m'inspirerai plutôt de framework (Java ou Smalltalk) comme HotDraw, GEF..
Connectez-vous ou Inscrivez-vous pour répondre.