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
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Loïc Joly
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
J'ai et j'aime beaucoup.
- Modern C++ Design: Generic Programming and Design Patterns Applied de Andrei Alexander
J'ai apprécié de le lire, mais je pense qu'il faut plus prendre ce livre pour une curiosité que comme un incontournable.
et - Multi-Paradigm Design for C++ de James O. Coplien
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
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
J'ai et j'aime beaucoup.
- Modern C++ Design: Generic Programming and Design Patterns Applied
de Andrei Alexander
J'ai apprécié de le lire, mais je pense qu'il faut plus prendre ce livre
pour une curiosité que comme un incontournable.
et
- Multi-Paradigm Design for C++ de James O. Coplien
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.
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
J'ai et j'aime beaucoup.
- Modern C++ Design: Generic Programming and Design Patterns Applied de Andrei Alexander
J'ai apprécié de le lire, mais je pense qu'il faut plus prendre ce livre pour une curiosité que comme un incontournable.
et - Multi-Paradigm Design for C++ de James O. Coplien
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
dug
Loïc Joly wrote in news:422ccb82$0$25051 $:
Par contre, de tes trois choix, aucun ne me semble particulièrement orienté design, mais plus utilisation des templates.
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.
Loïc Joly <loic.actarus.joly@wanadoo.fr> wrote in news:422ccb82$0$25051
$8fcfb975@news.wanadoo.fr:
Par contre, de tes trois choix, aucun ne me semble particulièrement
orienté design, mais plus utilisation des templates.
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.
Par contre, de tes trois choix, aucun ne me semble particulièrement orienté design, mais plus utilisation des templates.
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.
Loïc Joly
Loïc Joly wrote in news:422ccb82$0$25051 $:
Par contre, de tes trois choix, aucun ne me semble particulièrement orienté design, mais plus utilisation des templates.
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.
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.
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.
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
Loïc Joly <loic.actarus.joly@wanadoo.fr> wrote in news:422ccb82$0$25051
$8fcfb975@news.wanadoo.fr:
Par contre, de tes trois choix, aucun ne me semble particulièrement
orienté design, mais plus utilisation des templates.
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.
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.
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.
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.
Par contre, de tes trois choix, aucun ne me semble particulièrement orienté design, mais plus utilisation des templates.
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.
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.
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.
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
kanze
Loïc Joly wrote:
Loïc Joly wrote in news:422ccb82$0$25051 $:
Par contre, de tes trois choix, aucun ne me semble particulièrement orienté design, mais plus utilisation des templates.
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.
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.
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.
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++.
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.
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.
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.
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.
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
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
Loïc Joly wrote:
Loïc Joly <loic.actarus.joly@wanadoo.fr> wrote in
news:422ccb82$0$25051 $8fcfb975@news.wanadoo.fr:
Par contre, de tes trois choix, aucun ne me semble
particulièrement orienté design, mais plus utilisation des
templates.
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.
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.
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.
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++.
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.
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.
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.
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.
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
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
Par contre, de tes trois choix, aucun ne me semble particulièrement orienté design, mais plus utilisation des templates.
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.
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.
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.
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++.
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.
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.
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.
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.
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
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
