bouquin design
Le
dug8C
bonjour,
J'ai déjà un bouquin sur les Design patterns et j'ai quelques
connaissances de UML.
Cependant j'ai encore quelques soucis avec la conception de mes
programmes et j'hésite entre:
- C++ Templates: The Complete Guide de David Vandevoorde, Nicolai M.
Josuttis
- Modern C++ Design: Generic Programming and Design Patterns Applied
de Andrei Alexander
et
- Multi-Paradigm Design for C++ de James O. Coplien
Lequel est-il le mieux adapté ?
J'ai déjà un bouquin sur les Design patterns et j'ai quelques
connaissances de UML.
Cependant j'ai encore quelques soucis avec la conception de mes
programmes et j'hésite entre:
- C++ Templates: The Complete Guide de David Vandevoorde, Nicolai M.
Josuttis
- Modern C++ Design: Generic Programming and Design Patterns Applied
de Andrei Alexander
et
- Multi-Paradigm Design for C++ de James O. Coplien
Lequel est-il le mieux adapté ?

Poser une question


J'ai et j'aime beaucoup.
J'ai apprécié de le lire, mais je pense qu'il faut plus prendre ce livre
pour une curiosité que comme un incontournable.
Je n'ai pas lu, mais c'est un grand classique.
Par contre, de tes trois choix, aucun ne me semble particulièrement
orienté design, mais plus utilisation des templates.
--
Loïc
Merci pour ta réponse. En fait je compte acquerir l'un des 3 de toutes
facons et maintenant je pense opter pour le 1er.
Mais ca ne resoud pas mon pb de conception. Je pensais, à tort, pouvoir
combiner la conception adaptée à C++ et qu'au moins le livre d'Andrei
Alexender pourrait m'aider mais je vais devoir m'orienter plutot vers un
bouquin d'UML.
Pour info j'ai lu "Design patterns par la pratique" de A.Shalloway qui est
interessant, mais j'ai un peu de mal mettre en pratique tout ça quand je
veux créer un programme.
Attention : UML est un langage, comme un autre, avec juste une
particularité d'être graphique et que les compilateurs sont en général
en partie humains. De très bons bouquins d'UML se contentent de décrire
ce langage, mais tu n'apprendra pas forcément mieux la conception avec
eux qu'avec un bon bouquin de C++.
Je n'ai par contre pas de bonne référence à proposer pour ton besoin.
J'ai un peu entendu parler de Object Oriented Software Construction
(http://archive.eiffel.com/doc/oosc/), mais sans avoir de jugement
personnel en la matière.
Je ne connais pas ce livre en particulier. Pour les designs patterns,
mon avis est que tant qu'on n'a pas l'expérience de 2/3 vrai codes, on a
probablement du mal à apprécier. J'ai vu des gens qui avaient découvert
ça trop tôt, et je trouve qu'ils avaient un peu tendance à croire que
parce que ça copiait un pattern, c'était un bon choix.
J'ai plus l'approche de dire que les patterns permettent de prendre du
recul par rapport à ce qu'on fait, à nous permettre de nous poser des
questions sur les différences entre notre solution et la solution
canonique, et éventuellement si la solution canonique est à égalité, à
la choisir car en tant que référence, elle aura plus de chance d'être
comprise.
--
Loïc
UML, c'est beaucoup de choses pour beaucoup de gens. C'est un
langage, parce qu'il sert à communiquer. Mais justement, à cause
de l'aspect graphique, on n'écrit que rarement directement en ce
langage (au moyen des outils purement graphique). Du coup, on se
trouve obligé à apprendre un langage supplémentaire (en général
intéractif) pour saisir les graphiques avec leurs sémantiques :
Rose et Together sont, je crois, les plus répandus.
Tout à fait. Seulement, plus que langages, je préfère les
qualifier d'« outils ». Ce n'est ni plus ni moins corrects, mais
on se place d'un point de vue différent. Ni le C++ ni l'UML ne
sont le but ; ils ne sont que des moyens (parmi d'autres) pour
arriver au but. Alors (mais c'est ce que tu es en train de
dire), il ne suffit pas de connaître l'« outil », tel qu'il
est@; il faut aussi savoir ce qu'on veut faire avec lui. Pour
rapporter aux outils « classiques » du bricoleur, il ne suffit
pas de savoir couper le bois avec une scie, il faut aussi savoir
où il faut couper, la taille et la forme des pièces dont on a
besoin.
Le seul livre que je connaissais dans le temps qui s'adressait
bien au problème, c'était celui de Robert Martin, mais je crains
qu'il soit assez périmé aujourd'hui : les templates sont on ne
peut plus primitifs, et les diagrammes ont encore des nuages.
Voir ci-dessus : les modèles de conception sont, eux aussi, des
outils. référence, elle aura plus de chance d'être comprise. Un
outil important, certes, mais qu'un outil.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34