« Vous pratiquez un langage dit "orienté objet" et vous avez l'impression que votre développement ne tient pas toujours la route, est difficile à maintenir, s'enlise progressivement à chaque version, alors cet article est fait pour vous éclairer. Nous allons ici réapprendre la conception objet et trouver les moyens pour simplifier votre codage grâce aux "design patterns" »
Aller plus loin
- Article complet (433 clics)
# Trobjet
Posté par gndl (site web personnel) . Évalué à -10.
[^] # Re: Trobjet
Posté par Anonyme . Évalué à -6.
[^] # Re: Trobjet
Posté par gndl (site web personnel) . Évalué à -5.
# Hep
Posté par Damien Raude-Morvan (site web personnel) . Évalué à -7.
Arf...
[^] # Re: Hep IUT
Posté par Baptiste SIMON (site web personnel) . Évalué à -3.
[^] # Re: Hep IUT
Posté par pas_moi . Évalué à 9.
[^] # Re: Hep IUT
Posté par Pierre Tramo (site web personnel) . Évalué à 10.
Par contre, le prix est vraiment élevé (surtout comparé à la grosseur du bouquin), même pour un livre d'info (qui sont TOUJOURS très cher) : entre 300/6,55957 et 350/6,55957 .
J'ai survolé l'article, et je pense qu'il a une mauvaise approche : il ne traite que du code java, alors que (par définition) on utilise les design patterns à la conception et non à l'implémentation. Il aurait donc été plus intéressant de commencer par des diagrammes UML. Il est beaucoup plus facile de comprendre un design pattern quand on a des diagrammes de classes et de séquence sous les yeux (et d'autres si besoin est), avant de l'utiliser ou de l'adapter au problème qu'on a à traiter.
# Une lecture intéressante
Posté par Jar Jar Binks (site web personnel) . Évalué à 6.
Certaines d'entre elles (je pense en particulier à celles qui sont appellées modèles de structure) sont quand même clairement des bidouilles pour contourner des limitations du langage, C++ en l'occurrence. Personnellement, j'utilise plutôt Python, et le typage dynamique autorise tout ça sans avoir à s'emmerder à taper des trucs en plus.
[^] # Re: Une lecture intéressante
Posté par Sebastien (site web personnel) . Évalué à 10.
> Certaines d'entre elles (je pense en particulier à
> celles qui sont appellées modèles de structure) sont
> quand même clairement des bidouilles pour contourner
> des limitations du langage, C++ en l'occurrence.
Erm. À vrai dire, le monsieur qui a écrit l'article est un développeur Java, et tous les exemples sont en Java (avec des interfaces et du Javadoc).
Et puis, il n'est pas question de faire des bidouillages pour taper moins de trucs, mais de faire quelque chose de propre pour imposer certaines conditions ou bypasser certains élements de codes non-modifiables.
seb.
[^] # Re: Une lecture intéressante
Posté par Jar Jar Binks (site web personnel) . Évalué à 5.
Oups... Ça y ressemblait pas mal, pourtant (j'ai jamais vu de Java et je connais mal C++).
Et puis, il n'est pas question de faire des bidouillages pour taper moins de trucs, mais de faire quelque chose de propre pour imposer certaines conditions ou bypasser certains élements de codes non-modifiables.
Je n'ai jamais dit ça ! J'explique juste que certains langages permettent de faire strictement la même chose avec une syntaxe bien plus légère.
[^] # Re: Une lecture intéressante
Posté par VACHOR (site web personnel) . Évalué à 5.
Si il fallait soutenir tous ceux qui gueulent sur les toits "je fais du python et vous êtes tous des cons" ça en ferait des impots en plus !
Et avant de critiquer faut se renseigner, par exemple Java supporte la détermination dynamique de type, et bien plus... Et en C++ les templates c'est pas fait pour les chiens.
[^] # Re: Une lecture intéressante
Posté par Jar Jar Binks (site web personnel) . Évalué à -9.
(-1, on s'en tape)
[^] # Re: Une lecture intéressante
Posté par bleh . Évalué à 10.
De toute façon les design patterns sont sensés être indépendants du langage.
A titre informatif, il n'y a pas que des design pattern d'ailleurs. A mon avis, les architectural patterns sont au moins aussi important pour le design d'une application.
L'architecture MVC (modèle, vue, controleur), par exemple, a fait ses preuves pour des applications web. Franchement, je ne suis pas étonné que l'auteur de l'article developpe en java, puisque ce langage se prète bien aux patterns.
Par exemple, réaliser une architecture MVC pour une application web est assez facile avec l'utilisation des Servlets pour le controleur, les JavaBeans pour les données et les JSP pour tout ce qui est vue, on peut pas vraiment en dire autant avec d'autre langage (en tout cas mes faibles connaissances en PHP ne m'ont pas permis de retrouver la même chose avec ce langage). Même si il faut bien avouer que les beans sont assez "chiants" à manipuler et que java a une conception assez curieuse de la durée d'une session.
[^] # Re: Une lecture intéressante
Posté par boubou (site web personnel) . Évalué à 2.
[^] # Re: Une lecture intéressante
Posté par Alexandre Brillant . Évalué à -1.
vlissides sont en C++ (et un tout petit peu
de smalltalk histoire de).
Donc :
Erm. À vrai dire, les monsieurs qui ont écrits le bouquin sont des développeurs C++, et tous les exemples sont en C++.
[^] # Re: Une lecture intéressante
Posté par Pierre Tramo (site web personnel) . Évalué à 2.
Gamma participe aussi à JUnit ( http://junit.org/(...) ), framework de test unitaire en... Java.
[^] # Re: Une lecture intéressante
Posté par Dugland Bob . Évalué à 4.
Donc pas besion d'en faire des tonnes.
Un truc marrant : VisualWorks utilise le MVC alors que Dolphin utilise le MVP, les patterne c'est aussi un sujet de troll
[^] # Re: Une lecture intéressante
Posté par Guillaume Laurent (site web personnel) . Évalué à 3.
Je ne suis pas sur de comprendre. Peux-tu donner un exemple concret ?
[^] # Re: Une lecture intéressante
Posté par Jar Jar Binks (site web personnel) . Évalué à 3.
Mais avec un typage dynamique, peu importe que tu sois en présence de la classe toto ou de la classe titi, car si tu fais machin.méthode(truc) il se débrouillera dans les deux cas.
Cela dit, le typage dynamique c'est aussi plein d'inconvénients à côté.
[^] # Re: Une lecture intéressante
Posté par Pierre Tramo (site web personnel) . Évalué à 1.
De quel pattern parles-tu ?
[^] # Re: Une lecture intéressante
Posté par Guillaume Laurent (site web personnel) . Évalué à 3.
Je ne comprends toujours pas. Je présume que "machin" est un nom d'objet d'un certain type (class toto ou titi).
Partant de là, en Python ou n'importe quel autre langage objet, soit les classes toto et titi définissent la méthode 'méthode' prenant un 'truc' comme argument et ça passe, soit non et tu te prends une erreur à la compil dans le cas d'un langage fortement typé comme C++, ou une exception au runtime dans le cas d'un langage comme Python ou Ruby. Que tu ais un typage dynamique ou pas ne change rien au fond du problème, il faut que toto et titi aient la même interface.
Ou alors tu veux peut-être dire qu'avec un typage dynamique, toto et titi peuvent définir deux méthodes avec le même nom et les mêmes arguments, mais sans hériter d'une classe commune, et qu'un truc comme
def appelle_la_methode_foo (obj, arg)
obj.foo(arg)
end
va passer, qu'on lui passe un objet toto ou titi. Là oui, c'est vrai. Mais le but de ce type de pattern est un peu plus complexe que ce cas là :-).
[^] # Re: Une lecture intéressante
Posté par Jar Jar Binks (site web personnel) . Évalué à 1.
def appelle_la_methode_foo (obj, arg)
obj.foo(arg)
end
va passer, qu'on lui passe un objet toto ou titi. Là oui, c'est vrai. Mais le but de ce type de pattern est un peu plus complexe que ce cas là :-).
Oui, c'est ce que je voulais dire.
Auquel cas, quel est l'intérêt d'une interface comme décrit dans l'article sur des choses plus simples comme celles-ci ?
[^] # Re: Une lecture intéressante
Posté par Guillaume Laurent (site web personnel) . Évalué à 4.
En pratique, il y a plus d'une méthode commune aux deux classes, et tu veux qu'elles dérivent de la même classe, pas seulement pour des question de typage mais aussi parce que ça explicite bien ce que tu veux faire, et c'est beaucoup plus maintenable. Par ailleurs tu peux plus facilement tester les paramètres qu'on te passe avec un truc du genre
if (machin.implements(telle_interface))
... ok
else
throw
end
Entre
class Foo
open()
close()
end
class Bar
open()
close()
end
et
Interface Stream
open()
close()
end
class Foo implements Stream
...
end
class Bar implements Stream
...
end
le 2nd cas est quand même plus clair, non ? Plus tu en dis au langage sur comment s'organisent tes classes, mieux c'est.
Je crois que tu devrais lire le Design Patterns :-).
[^] # Re: Une lecture intéressante
Posté par Vivi (site web personnel) . Évalué à 4.
Ou alors tu veux peut-être dire qu'avec un typage dynamique, toto et titi peuvent définir deux méthodes avec le même nom et les mêmes arguments, mais sans hériter d'une classe commune, et qu'un truc comme ...
c'est possible avec du typage statique : on peut faire ça en Objective Caml.
# Intéressant
Posté par Anonyme . Évalué à 10.
Les designs patterns peuvent paraitre anodins, mais comme le souligne l'auteur on fini à force d'entasser des lignes par se retrouver à coder plus ou moins comme un goret ;-) C'est là l'intéret des motifs objets. Meme si on ne les maitrise pas tous, les plus utilisés (Factory, Singleton) rendent bien des services.
# Hum... [première partie]
Posté par bobert . É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.
[^] # Hum... [seconde partie]
Posté par bobert . É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
[^] # Re: Hum... [seconde partie]
Posté par Matafan . Évalué à -2.
Et bien si, une fabrique est bien une classe, pas une interface. Une classe qui permet de construire des instances d'une interface donnée (ou de plusieurs interfaces d'ailleurs, comme dans son exemple).
[^] # Re: Hum... [seconde partie]
Posté par shbrol . Évalué à 2.
Dans ce cas, create_toto est une fonction, pas une classe, et si je ne m'abuse il s'agit bien d'une factory. Cette fonction pourrait aussi etre une méthode statique de la classe Toto.
[^] # Re: Hum... [seconde partie]
Posté par Epsos . Évalué à 6.
J'allais envoyer un commentaire de la meme veine ... et j'ai vu ton commentaire.
Sinon, un truc qui m'a etonne c'est de ne pas voir le visiteur. Il me semble pourtant qu'avec le Singleton et l'Iterateur c'est le design le plus connu et le plus utilise ...
Comme le dit bobert, une seule reference : Design Patterns par Gamma, Helm, Johnson et Vlissides ...
[^] # Re: Hum... [seconde partie]
Posté par Alexandre Brillant . Évalué à -1.
interface, cela n'à pour moi aucun sens puisqu'une
interface désigne une abstraction afin
d'interchanger l'implémentation sans rompre
le cohérence de l'ensemble. L'interface couvre
donc n'importe quel code Java y compris les
fabriques si cela est utile.
Un fabrique n'a selon toi aucun sens en dehors
de l'interface mais puisque l'implémentation n'est
pas délimitée comment pourrais - tu donné un
sens à la fabrique ? La classe est ici à des
fins pratiques, je ne veux pas embrouiller tout
le monde au risque de choquer les
pusillanimes de la programmation.
[^] # Re: Hum... [première partie]
Posté par Alexandre Brillant . Évalué à -1.
remis dans un contexte saint.
C'est une introduction donc je n'aborde pas
tous les sujets.
Concernant les interfaces et les classes abstraites,
elles appartiennent à la même famille décrivant
des squelettes de classes plus ou moins
complet. La distinction n'est pas clairement faite
ici car l'article tente (et je dis bien tente)
d'être généraliste, or le concept d'interface
se traduit par une classe abstraite en C++.
D'autre part, l'héritage entre interface existe
même avec une classe (hé oui, cela n'a
à priori aucun sens), donc je te laisse conclure:
// Ce code était présent dans l'outil WebObject
public interface Toto extends java.lang.Object {
}
Donc l'interface Java est traitée comme une
classe abstraite particulière. Je reconnais que
extends et remplaçé par implements à l'usage mais
c'est pour forcer l'usage de l'interface pas
pour renforçé la différence de l'interface
et de la classe abstraite.
Concernant l'héritage de classe et l'héritage
d'interface. Il faudrait peut être que tu
lises l'article en entier et notamment la ligne
suivante sur l'implémentation.
Un standard est avant tout défini par un
organisme indépendant, gamma et compagnie
ne forme en aucun cas un organisme de contrôle
et d'évolution des design patterns.
Par exemple :
Je viens de me définir une nouvelle norme pour
les fabriques.
public class ObjectBuilder {
public ObjectBuilder( ClassLoader loader )...
public Point getPoint( int x, int y )...
public void setDelegate( ObjectBuilder ob )...
}
Encore une avec une hierarchie
public class ObjectCreator {
public Object getObjectForName( String name );
public ObjectCreator getParent();
}
Encore une
public class NewObject {
public Instance getNewObject();
}
public interface Instance {
public Object getObject();
}
Bref on peut faire tout et n'importe quoi autour
des designs patterns alors pour moi il n'y a
ni norme ni standard.
Concernant ta dernière remarque toujours aussi
grave, commence déjà par lire sérieusement
l'article avant d'écrire au hasard.
[^] # Re: Hum... [première partie]
Posté par shbrol . Évalué à 3.
Maintenant, il faut bien comprendre que les DP essayent de présenter des _concepts_ reutilisables, qui peuvent (doivent) être modifiés dans le programme en construction. Il ne s'agit pas d'une recette de cuisine qui s'applique à la lettre (et c'est bien ce que tu montres avec des différentes façons de voir les fabriques).
[^] # Re: Hum... [première partie]
Posté par Spadone Pascal . Évalué à 3.
des designs patterns alors pour moi il n'y a
ni norme ni standard.»
Non ! comme te l'a fait remarquer Bobert, «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». Le bouquin du gof décrit les problématiques qui reviennent régulièrement pour les programmeurs ainsi que les modèles qui leur répondent; tes factories sont très jolies mais je doute qu'elle soit souvent utiles, et tu n'as pas expliqué à quels problèmes elle répondent.
[^] # Re: Hum... [première partie]
Posté par Alexandre Brillant . Évalué à -1.
bien éclairer le sens de ma phrase, un protocole
HTTP est normalisé, l'usage en fait un standard.
Les DP ne peuvent entrer dans cette catégorie.
Quant aux factory c'est vrai que je n'ai pas trés
appronfondi mais il suffit de regarder
l'introduction aux modèles de création une ligne
au-dessus pour avoir l'explication. RTFM
[^] # Re: Hum... [première partie]
Posté par boubou (site web personnel) . Évalué à 8.
Sur les interfaces et les classes abstraites :
J'irais plus loin que toi. Je pense que l'interface est le terme "objet" pour désigner un type abstrait, quelque chose qui est au moins aussi vieux que l'objet. Un type abstrait, c'est une catégorie de "machins" qu'on peut manipuler pour construire un algorithme. Pour définir un type abstrait, on fait en gros la liste des opérations disponibles sur les "machins" en question. Bien sûr, actuellement on parle objet, donc on ne dit pas "machin", mais objet. Mais bon, sur le fond c'est la même chose. Effectivement, comme C++ ne possède pas la notion d'interface, on l'implante en ce langage par une classe abstraite. A ce niveau, d'ailleurs tu fais une erreur. De fait en C++, une classe abstraire permet justement de représenter la notion d'interface et permet donc plus de chose que le partage de code.
Pour distinction entre récupération de code (héritage au sens classique des langages objets) et celle de type, je pense que la meilleure chose est tout simplement de ne pas appeler la deuxième héritage. Effectivement en Java une interface peut hériter d'une autre, mais c'est de l'implantation. Au niveau de la conception, il s'agit d'une relation sur les types abstraits : on définit un type abstrait dérivé à partir d'un autre type (c'est la notion de sous-typage de Sather). Ce genre de construction dépasse largement le cadre de la programmation objet. C'est utilisé par exemple dans les schémas XML.
sur la définition de DP
Là, je ne suis pas d'accord avec toi. Certains DP sont justement écrits pour faciliter la réutilisation de code (sans parler d'héritage). C'est le cas par exemple de la plupart des DPs de structure qui permettent d'adapter un code existant pour l'utiliser à partir d'un autre code existant. Bien entendu, il n'y a pas de magie : utiliser du code C++ dans une appli Java c'est lourdingue.
sur le Singleton
Alors là, non ! Un Singleton pur, c'est une seule instance, mais tout le monde comprend quand on parle de Singleton pour désigner une classe qui contrôle son nombre d'instances, même si ce n'est pas exactement un (je pense aux pools de Thread, par exemple).
D'autre part ta phrase "Une classe sans état est une classe qu'on n'instancie pas (modifiant static en java)." ne veut pas dire grand chose. Il existe effectivement (en Java) des classes qu'on n'instancie pas. Ce sont de "fausses" classes, c'est-à-dire des groupes de méthodes de classe (celles qui ont le modifieur static), c'est-à-dire une sorte de petite bibliothèque (je pense en particulier à la classe Math qui joue le rôle en Java de math.h en C). Je pense que l'auteur voulait parler dans son article d'objet sans état, c'est-à-dire d'objet sans variable. Par exemple quand on construit un Comparator en Java (un ordre), il est très classique que celui ni ne contienne pas de variable. L'objet joue alors le rôle d'un pointeur sur fonction orienté objet (et d'ailleurs, on utilise souvent une classe anonyme pour programmer ça en Java). L'objet est bien entendu instancié !
# Des excellents livres
Posté par RB . Évalué à 10.
http://www.bruceeckel.com/(...)
Certains de ces livres comme "Thinking in Java" sont traduit en françait sur le net (cherchez sur google).
Pour en revenir aux design pattern, ç'est vraiment qqc de fontamental, certains sont assez triviaux, mais d'autres peuvent être des révélation dans votre vie de programmeur. Un de mes préféré et que j'utilise relativement souvent: les visiteurs
[^] # Re: Des excellents livres
Posté par Gnurou (site web personnel) . Évalué à 10.
Il est bon aussi de rappeler que les livres de Bruce Eckel sont disponibles, gratuitement et en intégralité, sur le net (voir son site, http://www.bruceeckel.com(...)). Cela pendant leur écriture (pour récupérer des commentaires) et même après leur parution. Bruce part du principe que diffuser librement sur le net ne change rien a ses ventes (voire même les améliore) car pour un gros pavé de 500 pages, rien de mieux que le papier!
D'ailleurs, si j'ai acheté "Thinking in C++", c'est parce que la version HTML m'a dépanné une ou deux fois et que j'ai été impressionné par la qualité de l'ouvrage.
Bref, un auteur génial à tous les points de vue. Ses libres (en Anglais seulement hélas) peuvent être commandés facilement à partir des libraries en lignes (genre amazon)
[^] # Re: Des excellents livres
Posté par Nicolas Roard (site web personnel) . Évalué à 4.
Sinon j'ai trouvé un autre bouquin, dans un style plus pédagogique je trouve, "The Joy of Patterns, Using Patterns for Enterprise Development", de Goldfedder, toujours chez Addison-Wesley, ISBN 0-201-65759-7 . Un peu moins dense que "Design Patterns", mais plus agrèable à lire, bref ... :)
L'intérêt des Designs Patterns est qu'il s'agit de design; les concepts expliqués peuvent s'implémenter dans n'importe quel langage (bien que les langages OO facilitent grandement les choses :) ObjectiveC, Java, C++ ...)
Et franchement, un bon design facilite énormément le codage et la maintenance du code. Ce qui m'étonne, c'est de ne pas avoir eu des cours sur les DP en fait, tellement ça me paraît une lecture indispensable ...
[^] # Re: Des excellents livres
Posté par RB . Évalué à 1.
# A propos des pattern
Posté par lucio . Évalué à 7.
Cela a été très bien formulé par Robert Martin.
On peut trouver une adaptation française à l'adresse suivante:
http://www.design-up.com/design/principesoo/index.html(...)
# Les patterns en exemple
Posté par MagicNinja . Évalué à 5.
http://www.agcs.com/supportv2/techpapers/patterns/papers/tutnotes/(...)
# Complément à l'introduction
Posté par Alexandre Brillant . Évalué à 1.
http://www.djefer.com/articles/design/index.htm(...)
Bonne lecture
# Encore plus de de Design Patterns
Posté par Romain Guy . Évalué à 2.
# conception, vous avez dit conception ?
Posté par javp . Évalué à 0.
A ce sujet, il vaut mieux se plonger dans le livre du gof qui outre le catalogue de modèles propose une introduction d'une trentaine de pages très abordables et enrichissantes. On y apprend entre autre que les design patterns ont vu le jour dans les années 70 grâce à un architecte nommé Alexanders et qu'ils adressaient des problèmes de construction de bâtiments.
Mon sentiment sur « les rappels de conception objet » :
Contrairement aux langages de type procéduraux comme le C ou le Pascal, la conception objet ne divise pas l'espace de données (attributs) et l'espace de traitements (méthodes). Cet espace commun s'applique à une partie du problème à gérer sous la forme d'une classe.
Donc en gros, la différence entre le paradigme objet et procédural se réduit à :
- en procédural, on a, d'un coté les données et de l'autre les traitements
- en objet, données et traitements sont fusionnés au sein d'un concept appelé classe
Une classe est une représentation abstraite décrivant comment faire fonctionner des objets.
Drôle de façon de voir les choses. Si "Alexandre" est une instance de la classe "Homme", la classe "Homme" décrirait donc comment faire fonctionner "Alexandre". Une classe définit une unité sémantique basée sur la statique (attributs et méthodes) et la dynamique (états) et c'est ce complexe statique-dynamique que l'on appelle le comportement.
Les objets sont construits à partir de cette classe lors de l'exécution par un processus d'instanciation (en Java l'opérateur new). Chacune des déclarations dans une classe peut être limitée dans sa portée (portée locale ou privée, portée de groupe ou package, portée de descendance ou protégée, portée globale ou publique).
Hors sujet par rapport à "Quelques rappels sur la conception objet"
Une classe peut être associée à d'autre classes pour faciliter la réutilisation.
Pas d'accord. Une classe doit être associée à d'autres classes de même niveau de granularité et même niveau d'abstraction sous peine de souffrir de manque de cohésion (l'un des facteurs de non-réutilisation)
L'association la plus commune est l'héritage.
Je ne pense pas : une relation d'association simple est beaucoup plus commune que l'héritage. Il suffit de s'interroger sur la nature des relations que l'on entretient avec notre environnement (réseaux de connaissances, possessions personnelles, etc.) pour s'apercevoir qu'il y a très peu de relations d'héritage.
L'héritage sert à spécialiser une classe existante (lien de généralisation/spécialisation) par la modification/l'ajout de nouvelles méthodes et de nouvelles données. Cette spécialisation conduit à la construction de nouvelles classes (appelées aussi sous-classes). Le concept d'héritage peut être vu comme la conception d'un élément "est une sorte de".
L'héritage doit être vu comme une relation "est une sorte de". Lorsque ce n'est pas le cas, il faut être capable d’expliquer pourquoi sinon, on va au devant de problèmes de conception et de non-réutilisabilité (que ce soit des modèles ou des implémentations).
Lorsqu'une méthode d'une classe est redéfinie par une sous-classe, on dit qu'il y a surcharge. Comme nous le verrons dans la suite cette possibilité donne une grande souplesse à l'introduction de classes génériques déléguant certains comportements aux sous-classes.
Je ne pense pas que le terme "classe générique" soit approprié. Une classe générique s'appelle, dans le méta model d'UML, « Parameterised Class » (les adeptes de C++ auront reconnu les templates).
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.
Encore une fois, c'est une drôle de façon de voir les choses. Si je décide que la classe "Mammifère" est abstraite, ce n'est pas pour obliger les sous classes à implémenter certaines méthodes mais plutôt parce l'on ne peut pas trouver d'individus de cette espèce qui ne soient que des mammifères.
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++.
Bof. L'interface n'est un outil qui permet de "simuler" le multi héritage. La notion d'interface permet de donner à une classe une "empreinte" supplémentaire, cela relève plus du polymorphisme que du simple moyen de compensation. Il est a noter que même si le C++ autorise le multi héritage, il n'est pas préconisé d'en abuser (risque d'héritage en diamant,...) et en général, on fait en sorte d'hériter simplement d'une classe concrète et de multi hériter de classes abstraites. C'est ce genre de principe qu'ont appliqué les personnes qui ont créé Java.
Une interface est associée à une ou plusieurs classes d'implémentation.
Non, c'est plutôt le contraire : ce sont les classes concrètes qui sont en relation avec les interfaces (relire les specs d'UML à ce sujet). Une interface peut être en relation avec autre chose à partir du moment où le autre chose est une autre interface et que la relation est une relation d'héritage.
Une classe d'implémentation contient donc le code de réalisation de l'interface.
Je préfère dire que la classe qui dispose d'une nouvelle « empreinte » doit être équipée des méthodes qui lui permettent d'assumer sa nouvelle forme.
Dans la suite de l'article, nous proposerons des exemples en Java. Ces exemples sont facilement transposables en C++ ou dans tout autre langage objet.
Je ne vois pas ce que le reste de l'article apporte de plus par rapport au gof.
[^] # Re: conception, vous avez dit conception ?
Posté par Alexandre Brillant . Évalué à 0.
pas de rétablir toute l'étendu du paradigme objet
en 10 lignes. Cet article s'adresse avant tout à
des gens qui ne connaissent pas l'objet, me faire
le reproche de ne pas être à la hauteur de gamma
est ridicule, aucun débutant ne commencera par
gamma, c'est comme de commençer le piano avec
les préludes de Bach, irréaliste et sans intérêt.
- Concernant la première remarque :
Enlève le terme "se réduit" s.t.p. sinon la
connotation est négative
- 2° remarque : Le comportement n'est
pas le résultat d'une exécution de la description
d'une classe ? J'aimerai bien voir un objet
qui ne serait pas "décrit" par une classe.
- 3° remarque : Hors sujet aussi
- 4° remarque : D'accord avec toi,
cela porte à confusion
- 5° remarque : Commune était à prendre
au sens de "dans tous les languages Objets"
- 6° remarque : "est une sorte de"
appartient à un niveau sémantique, il ne s'agit
pas d'une obligation. Par exemple regarde le
dernier exemple et le DP "Template", cette
relation n'existe pas
- 7° remarque : C'est vrai que cela peut porter
à confusion lorsque l'on connaît l'objet
- 8° remarque : Théoriquement tu as raison, mais
je me réfère avant tout à la pratique et à la
pratique seulement. L'objet comme les réseaux
de neurone n'ont pas grand chose à voir avec la
réalité sinon comment classes-tu
l'ornithorynque ? :)
- 9° remarque : Tu as parfaitement raison, mais
voir la remarque 3°
- 10° remarque : Le contraire ne donnes pas
une vision trés subtil du polymorphisme, mais
il est vrai que les interfaces peuvent avoir des
associations entre elles par héritage.
- 11° remarque : Pourquoi pas, mais chacun
sa manière.
- 12° remarque : Mais tu t'attends à quoi ?
J'ai pourtant bien écrit "Introduction", tu
reconnais toi même qu'il s'agit d'une
vulgarisation qui n'est pas à ton goût. Quant
tu achètes un bouquin sur l'objet/UML tu ne
prends pas les bouquins pour débutant et tu
ne dénigres par les auteurs associés puisque
ces mêmes auteurs t'ont permis de progresser ??
Bonne continuation
[^] # Design Patterns GoF and GRASP
Posté par thetaz . Évalué à 1.
Les patterns GoF (Gang Of Four): http://smeric.developpez.com/java/uml/(...)
Les patterns GRASP : http://www.developpez.be/downloads/java/grasp.pdf(...)
Les tests Unitaires: http://smeric.developpez.com/java/astuces/tests/(...)
La conception de SI: http://uml.developpez.com/(...)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.