Alexandre a eu l'excellente idée d'aborder un sujet extrèmement important. Avant
de me remettre à la physique, j'ai fait 2 ans d'informatique en SSII, et
j'estime que les design patterns sont les connaissances en informatique les
plus utiles que j'aie pu acquérir durant cette période.
Mais j'aurais tellement aimé les découvrir plus tôt ! Personne autour de moi ne
semblait les mettre en pratique, et les quelques sites ou articles que j'ai pu
trouver à l'époque ne m'ont jamais convaincu. L'univers de l'informatique est
rempli de gens qui vous proposent d'adopter leurs méthodes de conception et de
développement parce qu'elles ont fonctionné pour eux. Il n'y a pas si longtemps
par exemple, on ne parlait que de RAD (développement rapide d'applications). Ca
marchait dans certains cas, ca devait donc être la solution universelle !
Aujourd'hui, un vrai programmeur ne jure que par l'eXtreme Programming...peu
importe. La grande difficulté dans cette jungle est de savoir distinguer parmi
les expériences vécues, celles qui nous paraissent adaptées à nos besoins de
celles qui sont trop particulières. Et à l'époque, j'ai cru que les design
patterns n'étaient qu'une énième recette de cuisine, sûrement intéressante,
mais pas plus ni moins que les autres.
C'était une erreur. Et j'ai peur que beaucoup d'autres la commettent également.
Alors, même si je crains de ne pas faire plaisir à Alexandre, je ne vous
recommande pas la lecture de son article pour vous familiariser avec les
modèles de conception. Justement parce que c'est ce genre d'articles qui
m'a caché l'importance inestimable des modèles de conception.
Il contient d'abord de grosses erreurs:
Quelques rappels sur la conception objet
Certaines classes ne sont pas complètement construites afin d'obliger les
sous-classes à effectuer une surcharge. On parle alors de classes abstraites ou
d'interfaces.L'interface est employée en Java pour compenser
l'interdication d'utiliser l'héritage multiple (héritage de plusieurs classes),
interdication qui n'apparaît pas en C++.
Ici deux erreurs extrêmement graves. D'abord, le concept d'interface est tout à
fait distinct de celui de classe abstraite. Une classe abstraite permet la
factorisation de code, ni plus, ni moins. Une interface, c'est l'ensemble des
requêtes auxquelles un objet peut fournir une réponse.
Ensuite, l'auteur confond malheureusement héritage de classe et héritage
d'interface. Une interface est une notion de programmation objet, à ce niveau de
la discussion, on n'a pas à parler de java ou de c++. L'héritage de classes
permet le partage de code. L'héritage d'interface décrit comment un objet peut
être utilisé à la place d'un autre.
Je ne saurais trop vous conseiller d'oublier ces "rappels" et de préférer des
lectures plus sérieuses à ce sujet.
Définition des design patterns
Les designs patterns ne sont pas rééllement normalisés
Au contraire. Les modèles de conception sont justement l'expression
du bon sens de la conception sous forme de modèles standard. Quel standard ?
celui du livre "Design Patterns" écrit par un groupe d'auteurs mondialement
connu comme le "Gang des quatre" (Gang of Four, ou GoF)[1][2]. Ce sont les
pères des modèles de conception. Leur livre, paru en 1995, présente les 23
modèles de conception qui sont devenus un standard de fait. Le JDK a
ainsi été construit en réutilisant fidèlement ces modèles. Ce sont bien
évidemment les mêmes que vous retrouvez dans l'article d'Alexandre Brillant qui
malheureusement ne cite pas cette référence.
Les design patterns ou modèles de conception décrivent des organisations
pratiques de classes objets. Ces organisations résultent souvent d'une
conception empirique, le concepteur objet tente de faciliter la réutilisation et
la maintenance du code
Outre la première phrase, dont je ne comprends absolument pas le sens, on trouve
encore une erreur grave. Les modèles de conception ne concernent pas du tout le
réutilisation de code. La réutilisation de code est très difficile et n'est
possible que dans des occasions bien précises. Par exemple, quelle bout de code
d'une application web écrite en java pourrait-on réutiliser dans une application
client écrite en c++ ?
Les modèles de conception concernent la réutilisation de méthodes de
conception ; ca n'a rien à voir.
# Hum... [première partie]
Posté par bobert . En réponse à la dépêche Comprendre les Design Patterns. Évalué à 10.
de me remettre à la physique, j'ai fait 2 ans d'informatique en SSII, et
j'estime que les design patterns sont les connaissances en informatique les
plus utiles que j'aie pu acquérir durant cette période.
Mais j'aurais tellement aimé les découvrir plus tôt ! Personne autour de moi ne
semblait les mettre en pratique, et les quelques sites ou articles que j'ai pu
trouver à l'époque ne m'ont jamais convaincu. L'univers de l'informatique est
rempli de gens qui vous proposent d'adopter leurs méthodes de conception et de
développement parce qu'elles ont fonctionné pour eux. Il n'y a pas si longtemps
par exemple, on ne parlait que de RAD (développement rapide d'applications). Ca
marchait dans certains cas, ca devait donc être la solution universelle !
Aujourd'hui, un vrai programmeur ne jure que par l'eXtreme Programming...peu
importe. La grande difficulté dans cette jungle est de savoir distinguer parmi
les expériences vécues, celles qui nous paraissent adaptées à nos besoins de
celles qui sont trop particulières. Et à l'époque, j'ai cru que les design
patterns n'étaient qu'une énième recette de cuisine, sûrement intéressante,
mais pas plus ni moins que les autres.
C'était une erreur. Et j'ai peur que beaucoup d'autres la commettent également.
Alors, même si je crains de ne pas faire plaisir à Alexandre, je ne vous
recommande pas la lecture de son article pour vous familiariser avec les
modèles de conception. Justement parce que c'est ce genre d'articles qui
m'a caché l'importance inestimable des modèles de conception.
Il contient d'abord de grosses erreurs:
Quelques rappels sur la conception objet
Certaines classes ne sont pas complètement construites afin d'obliger les
sous-classes à effectuer une surcharge. On parle alors de classes abstraites ou
d'interfaces.L'interface est employée en Java pour compenser
l'interdication d'utiliser l'héritage multiple (héritage de plusieurs classes),
interdication qui n'apparaît pas en C++.
Ici deux erreurs extrêmement graves. D'abord, le concept d'interface est tout à
fait distinct de celui de classe abstraite. Une classe abstraite permet la
factorisation de code, ni plus, ni moins. Une interface, c'est l'ensemble des
requêtes auxquelles un objet peut fournir une réponse.
Ensuite, l'auteur confond malheureusement héritage de classe et héritage
d'interface. Une interface est une notion de programmation objet, à ce niveau de
la discussion, on n'a pas à parler de java ou de c++. L'héritage de classes
permet le partage de code. L'héritage d'interface décrit comment un objet peut
être utilisé à la place d'un autre.
Je ne saurais trop vous conseiller d'oublier ces "rappels" et de préférer des
lectures plus sérieuses à ce sujet.
Définition des design patterns
Les designs patterns ne sont pas rééllement normalisés
Au contraire. Les modèles de conception sont justement l'expression
du bon sens de la conception sous forme de modèles standard. Quel standard ?
celui du livre "Design Patterns" écrit par un groupe d'auteurs mondialement
connu comme le "Gang des quatre" (Gang of Four, ou GoF)[1][2]. Ce sont les
pères des modèles de conception. Leur livre, paru en 1995, présente les 23
modèles de conception qui sont devenus un standard de fait. Le JDK a
ainsi été construit en réutilisant fidèlement ces modèles. Ce sont bien
évidemment les mêmes que vous retrouvez dans l'article d'Alexandre Brillant qui
malheureusement ne cite pas cette référence.
Les design patterns ou modèles de conception décrivent des organisations
pratiques de classes objets. Ces organisations résultent souvent d'une
conception empirique, le concepteur objet tente de faciliter la réutilisation et
la maintenance du code
Outre la première phrase, dont je ne comprends absolument pas le sens, on trouve
encore une erreur grave. Les modèles de conception ne concernent pas du tout le
réutilisation de code. La réutilisation de code est très difficile et n'est
possible que dans des occasions bien précises. Par exemple, quelle bout de code
d'une application web écrite en java pourrait-on réutiliser dans une application
client écrite en c++ ?
Les modèles de conception concernent la réutilisation de méthodes de
conception ; ca n'a rien à voir.