Oui le drag c'est fait ^^. Apres ton idée de modifier le nom est cool, je vais le faire ! En fait à te lire Ali je crois que j'ai mal organisé les choses. J'ai mes deux classes Arc et Sommet et une classe NSView où je dessine tout mais ou je gere les cliques, mais aussi mon algo dijkstra etc ... Il ne fallait pas mettre tout dedans ?
Sinon j'ai créé une petite croix sympa en png, il n'y aura pas de soucis pour l'afficher avec drawSommet (et donc drawRect) ?
Les algorithmes de traitement des données sont à mettre... dans la classe de gestion de données (= Modèle dans MVC).
Modèle = les liste de Sommets et Arcs + les différents traitements dessus Vue = la NSView où est faite le dessin Contrôleur = la classe qui fait l'interaction entre les deux (peut être dans Vue pour les projets simples comme ça...)
Dans les projets très simples comme l'exemple d'animation BezierPath, je mets tout dans la classe Vue, mais je suis pas un modèle
La vue a une référence directe sur le modèle (dont elle est la représentation) Le contrôleur a lui une référence directe sur le modèle et sur la vue pour pouvoir modifier l'un et dire à l'autre de se rafraà®chir.
Les flèches pointillées représentent en quelque sorte des callbacks (= Delegate et Notifications en Cocoa).
Et le controlleur il est de quel type? Poua j'ai tout à refaire. Enfin je dois tout réorganiser.
Ah ben si t'avais lu le livre de Hillegass, t'en aurais bouffé du contrôleur C'est la classe perso qu'on instancie dans le fichier d'interface (nib / xib) et qui contient tous les outlets et actions. Elle descend de NSObject directement et s'appelle souvent par convention Controller, MyController ou "<Nom App>Controller".
Mais comme j'ai dit au dessus, dans les petits projets, la vue peut jouer ce rôle sans problème (c'est rapide, mais pas une bonne habitude à prendre quand on débute cela dit) :P
Oui mais ca veut donc dire que je dois déclarer un outlet "maVue" pour pouvoir afficher mes sommets et faire des actions dessus (mouseDown etc ...) ? Et par exemple pour mes méthodes de traitement de graphe je choisi de les mettre dans ma classe arc puisque je me sert déjà dedans de ma classe sommet ?
Oui mais ca veut donc dire que je dois déclarer un outlet "maVue" pour pouvoir afficher mes sommets et faire des actions dessus (mouseDown etc ...) ? Et par exemple pour mes méthodes de traitement de graphe je choisi de les mettre dans ma classe arc puisque je me sert déjà dedans de ma classe sommet ?
Houlà à à à à , y a encore du boulot...
L'outlet "maVue", tu lui fais rien afficher du tout, tu lui dis "setNeedsDisplay", et elle se débrouille. Ce n'est pas toi qui fait les actions "mouseDown:" etc., elle les reçoit de l'interface graphique et transmet les informations au Contrôleur qui agit en conséquence. Les méthodes de traitement de graphe n'ont rien à faire dans la classe Arc, puisqu'un Arc n'est pas censé du tout connaà®tre le graphe entier.
- "Vue" (que tu pourrais renommer en un nom plus explicite quand même genre GraphView ) semble être ta partie.... Vue, ça ça va. "Sommet" et "Arc" ne sont que des éléments représentatifs d'objets dans ton
- ton Modèle : Un modèle est en général représenté par plusieurs choses... En fait il te faut plutôt un modèle décrivant tes données à représenter dans ton ensemble (là par exemple une classe "Graphe"), à laquelle tu vas pouvoir demander des actions et traitements du genre "addSommet", "addArcFromSommet:toSommet:", "sommetsCount", "shortestPathFromSommet:toSommet:" (la méthode qui implémente ou appelle ton algo de Djikstra), des choses comme ça. - Pour pouvoir plus facilement manipuler tes données dans ton modèle, tu vas bien sûr décomposer ton modèle en plusieurs objets le composant et que tu vas avoir à manipuler... en l'occurence ce sont tes Sommets et Arcs, qui sont donc bien des classes à mettre côté modèle, qui vont te permettre de constituer ton graphe. Parce que bon c'est quand même plus propre de décomposer ton Graphe en sous-objets le composant comme Sommets et Arcs que de le voir uniquement comme un tout. - Sommet et Arc sont donc juste des classes "utilitaires" pour manipuler les données constituant un Graphe, qui est l'objet de plus haut niveau de ton modèle. Ton modèle est constitué de ces 3 classes (voire pourquoi pas d'autres auxquelles je n'ai pas pensé), la classe Graphe étant le front-end de ton modèle (celle que le contrôlleur va interroger, celle qui représente ton modèle comme un tout, le reste n'étant que des composants de ce modèle).
- Le contrôlleur faisant la glue, c'est la partie qui va faire la communication entre tout ça. Pour ton cas comme dit plus haut on peut éventuellement tolérer que ce soit la vue qui joue ce rôle... mais c'est pas forcément un bon exercice pour commencer, autant prévoir une classe Controller dédiée à cette "glue" entre la vue (qui va lui envoyer les évènements souris etc) et le modèle (que le controlleur va interroger)
Ben oui, NSObject... Tu veux que ça descende de quoi d'autre ? :P Les sous-objets sont les tableaux d'arcs et de sommets... sous-objets en tant que i-vars du Modèle.
Les Controlleurs de type NSWindowController ne doivent être utilisés que quand on veut charger des .nib dynamiquement.
Oui cette classe Graphe je la vois comme un NSObject.
Après conceptuellement un graphe contient des sommets et des arcs reliants les sommets entre eux, c'est la définition d'un graphe. Pour implémenter ce concept dans ton modèle, il semble donc logique que tu aies une classe Graphe, qui "contient" (= elle a une variable d'instance de type NSMutableArray* tabSommets et une du genre NSMutableArray* tabArcs) des sommets et arcs.
Ton contrôlleur, quand il va demander des trucs au modèle (genre donne moi le nombre de sommets), il va demander ça au Graphe (pour le coup l'implémentation est simple : [tt]-(NSUInteger)sommetsCount { return [tabSommets count]; }[/tt]. Après que le graphe contienne des (ait un tableau de) Sommets et d'Arcs, c'est juste que ça semble logique comme représentation interne de ton modèle, mais tu pourrais faire ça autrement (genre plutôt stocker dans ton modèle pour les arcs une matrice NxN N nombre de sommets, la matrice indiquant dans sa case (i,j) les distances entre les sommets i et j... ça pourrait être une autre représentation interne de ton graphe possible donc... mais à mon avis bien moins adapté à la manipulation, surtout si tu ajoutes des sommets au fur et à mesure donc bon, je toruve mieux d'avoir une classe Arc qui pointe sur un sommet de début et un de fin...)
Justement c'est aussi la beauté du modèle MVC, si un jour tu décides de changer le modèle, de le réorganiser complètement pour gérer en interne tes données de façon complètement différente (par exemple stocker ton graphe dans une base SQLite ou MySQL, ou changer la façon d'organiser tes objets Sommet et Arc...), ça n'affectera pas le reste de ton appli, la Vue pourra toujours fonctionner avec ce nouveau modèle.
Réponses
En fait à te lire Ali je crois que j'ai mal organisé les choses. J'ai mes deux classes Arc et Sommet et une classe NSView où je dessine tout mais ou je gere les cliques, mais aussi mon algo dijkstra etc ... Il ne fallait pas mettre tout dedans ?
Sinon j'ai créé une petite croix sympa en png, il n'y aura pas de soucis pour l'afficher avec drawSommet (et donc drawRect) ?
Modèle = les liste de Sommets et Arcs + les différents traitements dessus
Vue = la NSView où est faite le dessin
Contrôleur = la classe qui fait l'interaction entre les deux (peut être dans Vue pour les projets simples comme ça...)
Dans les projets très simples comme l'exemple d'animation BezierPath, je mets tout dans la classe Vue, mais je suis pas un modèle
http://fr.wikipedia.org/wiki/Modèle-Vue-Contrôleur
La vue a une référence directe sur le modèle (dont elle est la représentation)
Le contrôleur a lui une référence directe sur le modèle et sur la vue pour pouvoir modifier l'un et dire à l'autre de se rafraà®chir.
Les flèches pointillées représentent en quelque sorte des callbacks (= Delegate et Notifications en Cocoa).
Ah ben si t'avais lu le livre de Hillegass, t'en aurais bouffé du contrôleur
C'est la classe perso qu'on instancie dans le fichier d'interface (nib / xib) et qui contient tous les outlets et actions.
Elle descend de NSObject directement et s'appelle souvent par convention Controller, MyController ou "<Nom App>Controller".
Mais comme j'ai dit au dessus, dans les petits projets, la vue peut jouer ce rôle sans problème (c'est rapide, mais pas une bonne habitude à prendre quand on débute cela dit) :P
Et par exemple pour mes méthodes de traitement de graphe je choisi de les mettre dans ma classe arc puisque je me sert déjà dedans de ma classe sommet ?
Houlà à à à à , y a encore du boulot...
L'outlet "maVue", tu lui fais rien afficher du tout, tu lui dis "setNeedsDisplay", et elle se débrouille.
Ce n'est pas toi qui fait les actions "mouseDown:" etc., elle les reçoit de l'interface graphique et transmet les informations au Contrôleur qui agit en conséquence.
Les méthodes de traitement de graphe n'ont rien à faire dans la classe Arc, puisqu'un Arc n'est pas censé du tout connaà®tre le graphe entier.
C'est ça que j'ai du mal à saisir (enfin avec pleins d'autres trucs).
"Sommet" et "Arc" ne sont que des éléments représentatifs d'objets dans ton
- ton Modèle : Un modèle est en général représenté par plusieurs choses... En fait il te faut plutôt un modèle décrivant tes données à représenter dans ton ensemble (là par exemple une classe "Graphe"), à laquelle tu vas pouvoir demander des actions et traitements du genre "addSommet", "addArcFromSommet:toSommet:", "sommetsCount", "shortestPathFromSommet:toSommet:" (la méthode qui implémente ou appelle ton algo de Djikstra), des choses comme ça.
- Pour pouvoir plus facilement manipuler tes données dans ton modèle, tu vas bien sûr décomposer ton modèle en plusieurs objets le composant et que tu vas avoir à manipuler... en l'occurence ce sont tes Sommets et Arcs, qui sont donc bien des classes à mettre côté modèle, qui vont te permettre de constituer ton graphe. Parce que bon c'est quand même plus propre de décomposer ton Graphe en sous-objets le composant comme Sommets et Arcs que de le voir uniquement comme un tout.
- Sommet et Arc sont donc juste des classes "utilitaires" pour manipuler les données constituant un Graphe, qui est l'objet de plus haut niveau de ton modèle. Ton modèle est constitué de ces 3 classes (voire pourquoi pas d'autres auxquelles je n'ai pas pensé), la classe Graphe étant le front-end de ton modèle (celle que le contrôlleur va interroger, celle qui représente ton modèle comme un tout, le reste n'étant que des composants de ce modèle).
- Le contrôlleur faisant la glue, c'est la partie qui va faire la communication entre tout ça. Pour ton cas comme dit plus haut on peut éventuellement tolérer que ce soit la vue qui joue ce rôle... mais c'est pas forcément un bon exercice pour commencer, autant prévoir une classe Controller dédiée à cette "glue" entre la vue (qui va lui envoyer les évènements souris etc) et le modèle (que le controlleur va interroger)
Pour le controlleur j'ai créé un classe "Controlleur" de type NSWindowController , c'est bien ça?
Les sous-objets sont les tableaux d'arcs et de sommets... sous-objets en tant que i-vars du Modèle.
Les Controlleurs de type NSWindowController ne doivent être utilisés que quand on veut charger des .nib dynamiquement.
Après conceptuellement un graphe contient des sommets et des arcs reliants les sommets entre eux, c'est la définition d'un graphe. Pour implémenter ce concept dans ton modèle, il semble donc logique que tu aies une classe Graphe, qui "contient" (= elle a une variable d'instance de type NSMutableArray* tabSommets et une du genre NSMutableArray* tabArcs) des sommets et arcs.
Ton contrôlleur, quand il va demander des trucs au modèle (genre donne moi le nombre de sommets), il va demander ça au Graphe (pour le coup l'implémentation est simple : [tt]-(NSUInteger)sommetsCount { return [tabSommets count]; }[/tt]. Après que le graphe contienne des (ait un tableau de) Sommets et d'Arcs, c'est juste que ça semble logique comme représentation interne de ton modèle, mais tu pourrais faire ça autrement (genre plutôt stocker dans ton modèle pour les arcs une matrice NxN N nombre de sommets, la matrice indiquant dans sa case (i,j) les distances entre les sommets i et j... ça pourrait être une autre représentation interne de ton graphe possible donc... mais à mon avis bien moins adapté à la manipulation, surtout si tu ajoutes des sommets au fur et à mesure donc bon, je toruve mieux d'avoir une classe Arc qui pointe sur un sommet de début et un de fin...)
Justement c'est aussi la beauté du modèle MVC, si un jour tu décides de changer le modèle, de le réorganiser complètement pour gérer en interne tes données de façon complètement différente (par exemple stocker ton graphe dans une base SQLite ou MySQL, ou changer la façon d'organiser tes objets Sommet et Arc...), ça n'affectera pas le reste de ton appli, la Vue pourra toujours fonctionner avec ce nouveau modèle.
Dans ta fonction - (void)mouseDragged:(NSEvent *)monEvenement {}
Il vaut mieux mettre:
plutôt que:
pareil avec l'ordonnée.
Le résultat est beaucoup plus fluide puisqu'il n'y a pas le "saut" direct à la position de la souris