Une fabrique de création (ou factory) est une classe [...]
Non, justement. Une fabrique définit une interface pour la création
d'objets, pas une classe.
Singleton
Un singleton sert à contrôler le nombre d'instances d'une classe présent à
un moment donné. C'est souvent trés pratique pour les classes sans état et
effectuant toujours les mêmes traitements.
N'importe quoi. Un singleton garantit qu'une classe n'a qu'une seule
instance. Une classe sans état est une classe qu'on n'instancie pas
(modifiant static en java).
Le singleton limite le nombre d'instance en mémoire
Et comment, puisqu'il ne doit y en avoir qu'une.
Bon, je m'arrête là pour les erreurs.
D'autre part, l'article comme beaucoup d'autres présente une liste de modèles de
conception ; pour beaucoup d'entre eux, l'intention de ce modèle n'est pas
présentée et on est réduit à un exemple de code. Mais les modèles de conception
ne se réduisent pas à une recette de cuisine ! Il ne s'agit pas de dire qu'en
réfléchissant un peu on peut programmer proprement ! Il s'agit d'expliquer en
quoi un modèle peut répondre à une problématique, et en quoi la problématique et
le modèle sont universels. Si l'exemple de code est une aide indispensable, il
ne constitue pas à lui seul la description du modèle sous-jacent.
Voilà mon conseil, qui peut ressembler à une attaque directe de l'auteur de
l'article, mais qu'il faut simplement interpréter comme un cri du coeur.
Le gang des quatre présente dans leur livre les modèles de conception de façon
plus claire qu'aucun des articles que j'ai pu lire auparavant. Non seulement
parce qu'ils en sont les pères, mais parce que leur livre n'a pas vieilli depuis
1995. C'est toujours une référence, à tel point que je la considère comme une
des rares références indispensables pour un développeur, disons "orienté objet".
Je ne suis sûrement pas le seul, puisqu'il est par exemple une des deux lectures
imposées pour la certification Sun, avec les Java Blueprints.
Plutôt que d'écrire un article présentant mal --à mon avis-- les modèles de
conception (c'est ce genre d'articles qui m'a fait perdre 1 an et demi, d'où ma
réaction), Alexandre Brillant aurait été plus avisé de décrire leur importance
et d'indiquer en référence le livre du GoF. Dont acte.
eul'Bob
Références:
-----------
[1] Design Patterns - Elements of reusable object-oriented software
E. Gamma, R. Helm, R. Johnson, J. Vlissides
Addison-Wesley, 1995
[2] Traduction française, des mêmes auteurs:
Design Patterns - Catalogue de modèles de conception réutilisables
Vuibert, 1999
[^] # Hum... [seconde partie]
Posté par bobert . En réponse à la dépêche Comprendre les Design Patterns. Évalué à 10.
Une fabrique de création (ou factory) est une classe [...]
Non, justement. Une fabrique définit une interface pour la création
d'objets, pas une classe.
Singleton
Un singleton sert à contrôler le nombre d'instances d'une classe présent à
un moment donné. C'est souvent trés pratique pour les classes sans état et
effectuant toujours les mêmes traitements.
N'importe quoi. Un singleton garantit qu'une classe n'a qu'une seule
instance. Une classe sans état est une classe qu'on n'instancie pas
(modifiant static en java).
Le singleton limite le nombre d'instance en mémoire
Et comment, puisqu'il ne doit y en avoir qu'une.
Bon, je m'arrête là pour les erreurs.
D'autre part, l'article comme beaucoup d'autres présente une liste de modèles de
conception ; pour beaucoup d'entre eux, l'intention de ce modèle n'est pas
présentée et on est réduit à un exemple de code. Mais les modèles de conception
ne se réduisent pas à une recette de cuisine ! Il ne s'agit pas de dire qu'en
réfléchissant un peu on peut programmer proprement ! Il s'agit d'expliquer en
quoi un modèle peut répondre à une problématique, et en quoi la problématique et
le modèle sont universels. Si l'exemple de code est une aide indispensable, il
ne constitue pas à lui seul la description du modèle sous-jacent.
Voilà mon conseil, qui peut ressembler à une attaque directe de l'auteur de
l'article, mais qu'il faut simplement interpréter comme un cri du coeur.
Le gang des quatre présente dans leur livre les modèles de conception de façon
plus claire qu'aucun des articles que j'ai pu lire auparavant. Non seulement
parce qu'ils en sont les pères, mais parce que leur livre n'a pas vieilli depuis
1995. C'est toujours une référence, à tel point que je la considère comme une
des rares références indispensables pour un développeur, disons "orienté objet".
Je ne suis sûrement pas le seul, puisqu'il est par exemple une des deux lectures
imposées pour la certification Sun, avec les Java Blueprints.
Plutôt que d'écrire un article présentant mal --à mon avis-- les modèles de
conception (c'est ce genre d'articles qui m'a fait perdre 1 an et demi, d'où ma
réaction), Alexandre Brillant aurait été plus avisé de décrire leur importance
et d'indiquer en référence le livre du GoF. Dont acte.
eul'Bob
Références:
-----------
[1] Design Patterns - Elements of reusable object-oriented software
E. Gamma, R. Helm, R. Johnson, J. Vlissides
Addison-Wesley, 1995
[2] Traduction française, des mêmes auteurs:
Design Patterns - Catalogue de modèles de conception réutilisables
Vuibert, 1999