Organiser ses classes
Veillard
Membre
Bonjour,
C'est un sujet très généraliste mais avec-vous des conseils pour organiser ses classes, ce qu'il faut faire et ne pas faire pour avoir du code 'clean" 8)
C'est un sujet très généraliste mais avec-vous des conseils pour organiser ses classes, ce qu'il faut faire et ne pas faire pour avoir du code 'clean" 8)
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
J'ai tendance à dénigrer la couche modèle du MVC... :-\\
Pas simple de se mettre vraiment à l'objet. Je vois que tu t'en sors avec tes plongées néanmoins !
C'est vaste en effet comme sujet. à part "coment faire une appli Cocoa" je vois pas plus généraliste
C'est sur, pour le cas d'école (
Pour ce qui est de l'organisation des classes il me semble important de bien en concevoir la répartition des rôles et leur "hiérarchie".
Eviter, en particulier, les références croisées: Un objetA, "responsable" d'un objetB aura sans doute une référence pointant sur B. (une variable d'instance type objetB* monB; )
Mais l'objetB ne devrait pas avoir de référence sur l'objetA.
Si on est amené à faire ça c'est que soit la conception des Classes (ou instances de la même classe) A & B est erronée et peut-être A & B ne devraient être qu'un. Ou que leur répartition des tâches est mal distribuée. Ou, souvent, que l'on oublie d'exploiter les puissantes possibilités des notifications, des bindings (;) ) etc ...
Il n'est pas interdit de faire ce type de référence à double sens... D'ailleurs, tu le vois un peu partout dans cocoa (une NSView connait ses subviews via le tableau retourné par subviews, et elle connait sa superview via superview).
Ce type de référence est très utile quand tu dois remonter la hiérarchie de l'extrémité vers la racine (ce qui est souvent le cas en programmation objet, vu l'éclatement des données).
.
Pour ma part, je ne me résout à y céder qu'après avoir longuement réfléchi à d'autres alternatives. Sinon bonjour le fouilli dans nos projet avec une interdépendance totale de toutes nos classes et une pagaille assurée à chaque modifications ajoutée non ?
à‰liminer les redondances se fait en sous-classant ou en créant des méthodes privées. Dès que deux classes ont une série de méthodes similaires, il peut être utile de créer une nouvelle classe, qui utilise ces méthodes et de faire en sorte que les deux autres classes héritent de la nouvelle. Le redondance peut aussi d'éliminer au sein d'une classe par l'emploi de méthodes privées ou de fonctions. Si deux méthodes ont par exemple 90% de leur code en commun, le mieux est de créer une nouvelle méthode, qui prend alors des arguments supplémentaires pour tenir compte des 10% de différences. Bref, le copier coller de méthode c'est mal.
Pour la division en tâches simples, il s'agit que chaque méthode ne fasse qu'une seule chose à la fois. Le problème est que les débutants comprennent mal la notion "une chose à la fois". Par exemple, on veut effectuer un tri dans un tableau, puis après avoir fait le tri, on mets à jour le tableau. Le tri est une chose (couche model), la mise à jour du tableau en est une autre (couche controller), on ne peut donc pas mettre le rafraichissement du tableau dans le code du tri.
Je suis exactement dans ce type de réflexion en ce moment!
J'ai ma structure MVC, et donc sur celle-ci j'ai besoin d'afficher des infos du modèle. Dans mon cas afficher la valeur d'une variable NSInteger contenu dans le modèle évidemment. Donc je suis dans la méthode drawRect: de ma vue. La question c'est comment récupérer la valeur?
Je me suis dit, pas touche au modèle à partir de la vue je vais demander au controller. Donc j'ai fait une méthode getVariable dans le controller qui ne fait que récupérer la variable dans le modèle (donc encore une fois [model getVariable].
Au moins je suis sûr de ne pas foutre en l'air mon MVC mais ya de la redondance n'est-ce pas? Ne traduit t'elle pas une erreur de conception?
Ou bien est-ce uniquement parce que aller chercher juste la valeur d'une variable est très simple?
Pour certains cas il est envisageable de demander directement au modèle, depuis la vue, de renvoyer une valeur. Ca transgresse un peu les règles du MVC, c'est vrai, mais bon, ça passe. D'ailleurs quand on utilise le binding (sous MacOSX), c'est ce qui est fait, la vue affiche directement des valeurs du modèle, et les modifie, sans forcément passer par un contrôlleur (ou alors un NSArrayController, classe dédié aux bindings du genre... mais bon ça change pas le pb que quand on design la vue avec IB on doit connaà®tre le keyPath pour accéder à la variable qu'on veut afficher, donc on doit connaà®tre l'organisation et structuration du modèle, ce qui n'est pas cohérent avec MVC pris strictement)
Donc après soit pour des cas comme ça tu fais un accès direct, soit tu souhaites rester strictement MVC et en effet du coup tes méthodes vont un peu être vides à ne faire que du "pass-thru" de variables...
Mais l'avantage de garder le MVC jusqu'au bout même pour "si peu", c'est que si ton modèle change, et que ton NSInteger n'est finalement plus une variable directe de ton modèle mais que finalement tu la stockes dans les NSUserDefaults ou dans un NSDictionary ou NSArray ou dans un autre objet ou quoi... Bah tu pourras juste adapter ta méthode accesseur de ton controlleur et ça ne fouttra pas la zone dans le reste de ton programme.
Sinon j'ai pensé à utiliser un observer pour notifier à ma vue lorsque le modèle change. Mais bon ça ne servira pas lorsque ma vue se redessine d'elle même il faudra bien aller "chercher" l'info dans le modèle via le controller.
ps: Tu ne connaà®trais pas l'expression d'origine qui équivaut à ton "bazooka pour tuer un mouche" ça fait des mois qu'on cherche avec des amis
Au final les modèles de conception sont là pour simplifier les choses mais il ne sont pas forcément naturelle à mettre en place. Enfin pour moi en tout cas
Mais au final on voit rapidement qu'à long terme ça a des avantages et qu'en plus ce sont des patterns éprouvés car utilisés un peu partout, donc y'a des gens qui y ont réfléchi c'est pas pour rien :P
Sinon pour l'expression, il me semble que j'avais déjà vu des expressions équivalentes, mais je ne m'en souviens plus sur le coup :P C'est un peu comme "Y'a baleine sous gravillon" qui est en fait une déformation moqueuse de l'expression "Y'a anguille sous roche", ou encore "C'est capilotracté" pour "c'est tiré par les cheveux" ou "Tu fais un peu de la quadricapilosectomie" pour... héhé tiens je te laisse chercher si tu la connais pas celle-là (cette variante est en effet moins connue :P)
Couper les cheveux en 4!
Je connaissait pas non plus la Baleine, pas mal ^^
Zut de zut par contre pour le bazooka, ma version c'était écraser un moustique avec un tractopelle.
En ce qui concerne "le modèle", j'ai énormément de mal à m'y faire pour deux raisons:
- Je n'ai pas de "culture informatique" réelle. Notamment la POO c'est pour moi "Pastis Olive et Oublier le boulot".
- Les problèmes que je traite sont très simples et induisent un modèle de programmation implicite en générale.
Jettes un oe“il la dessus ce sera plus explicite:
http://www.osx-dev.com/index.php?topic=3904.0
C'est quoi le CEA-G, c'est en rapport avec le commissariat à l'énergie atomique?
Plustôt que de te faire une description forcément limitée, tu peux aller voir ce site. http://www-leti.cea.fr/ ou celui-ci http://www.cea.fr.
PS: eMail moi si tu veux plus, sur ce post le sujet ce sont les classes!