(HS @Neckara Pour explicit, à lire : C++11 - Les opérateurs de conversion explicites)
Version imprimable
(HS @Neckara Pour explicit, à lire : C++11 - Les opérateurs de conversion explicites)
C'est l'uml qui ne me convient pas, il est bien plus limité que ne l'est le C++11.Citation:
Oui, je comprends ce point de vue...
Moi aussi, je cherches désespérément un outil qui transforme mes diagrammes uml en code, me prépare le café et me l'apporte avec un petit gateau et un sourire
Mais, si on oublie le café, le gâteau et le sourire, bouml est pas si mal dans son genre
Et si une machine doit coder à ma place, où est le plaisir :D, sachant qu'il y a fort à parier que le code en sortie soit totalement en opposition avec mon style.
Même chose. L'uml est limité.Citation:
Pourtant, si tu t'y prends correctement, la conception (de tes classes comme de tes algorithmes) devrait pouvoir être de "traduction automatique"...
Peut être t'y prends tu simplement pas "correctement"
Il n'y a que deux solutions en sortie de mon approche (c'est à dire en appliquant les principes dont j'ai parlé) : ça compile donc le code est robuste, ça ne compile pas donc il est faible. Les seules erreurs restantes sont les erreurs de logiques (toujours pour éviter le HS :aie: : on ne peut pas en dire autant du C :-°).Citation:
Mais il y a des décision de conceptions qui ne sont pas forcément opportunes et que le compilateur ne pourra pas vérifier (cf la discussion sur LSP que j'ai déjà citée )
Je ne fais pas d'abord la conception ensuite le code, je fais le code par remodelages successifs. C'est une approche comme une autre, critiquable certes ^^, mais qui a l'avantage d'exploiter réellement le multi-paradigme et les outils du C++ voire même d'en faire un art (oui, la beauté du code ça se travaille par remodelage).
Rien n'est figé dans le code.
Citation:
Envoyé par iolco51
Je pense que des debutants doivent apprendre a exprimer ce qu'ils ont besoin d'exprimer avant d'aprendre a tester ce qu'ils ont fait.
Autrement dit, pas au tout debut, mais plutot quand on leur a appris a designer des interfaces (de code j'entends).
Concernant l'article dont tu as mis le lien, tu noteras que les remarques de Carmack ne vont pas dans ton sens...
Mais cela dis il ne parlait pas exactement du sujet dont il est question ici donc je trouve que ce lien n'apporte pas grand chose a la discussion a part pointer que l'auteur de l'article (et donc de Dayad) n'a pas eu une education ideale des languages C++ et C.......Citation:
Envoyé par John Carmack
J’ai un peu la même approche itérative sur la réalisation du code. Néanmoins, tu te rends compte que ce sont bien les principes acquis que tu appliques : à chaque fois que tu fais une itération / refactorisation, c’est parce que dans ton code, le respect de certains principes laissait à désirer, et qu’au fur et à mesure il devient bon de nettoyer et réorganiser tout ça. Il faut aussi savoir être modéré : je ne mets pas sur le même plan une violation du LSP (pendu en place publique !) à une petite violation du SRP (ce sera 100 lignes et on en parle plus). C’est d’ailleurs le reproche principal que je pourrai faire à SOLID : à vouloir faire un acronyme qui fait classe, on met sur le même plan, sans notion d’ordre, des principes qui ne sont pas tous égaux en terme de conséquences. Pas sûr que ce soit si productif que ça.Citation:
Envoyé par germinolegrand
Au final, avec l’expérience, le respect des principes est bon dès le départ, et les itérations extrêmement limitées. Et ce sans formaliser forcément la conception du code (ça ne veut pas dire qu’elle n’a pas eu lieu, avant le codage vient toujours une grosse réflexion).
Et je te rejoins parfaitement sur les limites d’uml et l’inadéquation de l’outil. Au final, ça va aussi vite d’écrire un bon vieux .h pour décrire l’interface (et doxygen a la gentillesse de me générer de l’uml avec ça pour les collègues qui y tiennent ;) ).
hum, c'est le seul point sur lequel je diffère peut-être sachant que si je refais du code c'est parce ça m'empêche de coder aisément la suite, j'essaie toujours de respecter l'intégralité de mes principes dès le début :D (oui, ça c'est inapplicable avec les principes de conception, c'est pour ça que mes principes directeurs sont des principes techniques applicable en codant et non en analysant).Citation:
à chaque fois que tu fais une itération / refactorisation, c’est parce que dans ton code, le respect de certains principes laissait à désirer
Et le LSP, bah... instinctivement je tend plus à respecter et intégrer le SRP (dont je vois bien l'intérêt même dans mon approche) que le LSP qui m'intéresse finalement assez peu.
Je ne sais pas comment tu fais pour faire de l’héritage correct si tu ne te soucies pas de LSP.Citation:
Envoyé par germinolegrand
Note que tu n’es pas tout seul : les libs y compris standard java et .net sont truffées de cas de rupture de LSP (les langages eux-mêmes en ont !), mais ça engendre inévitablement des problèmes, parfois pénibles à corriger ;).
Comme déjà dit... ça n'empêche pas le LSP d'être vérifié au final, c'est juste que je ne m'en préoccupe pas quand je code :).
Et ça ne te pose pas de problème d’avoir une fonction menteuse ? 8O (le nom dit une chose, le code en fait une autre).Citation:
Envoyé par nickyla
Moi, si…
L'UML n'est jamais qu'un moyen de permettre aux gens de se passer l'information ;)Citation:
Envoyé par germinolegrand
C'est perfectible, mais il ne faut pas non plus essayer de lui faire faire des choses pour lesquelles il n'est pas prévu ;)
Personnellement, j'utilise volontiers la méthode qui consiste à décrire très précisément ce que je veux, en expliquant chaque terme qui mérite de l'être en plus d'un nom ou d'un verbe.
A partir de là, je pars du principe qu'un nom est un type et un verbe est une fonction ;)