Version imprimable
J'ai eu lors d'un entretien d'embauche le droit à comme question :
Quel sont les 3 notions fondamentales en objet ?
- l'héritage
- le polymorphisme
- le design pattern
Je ne connaissais pas du tout la 3ème. Qu'est ce que c'est le design pattern ?
Est ce si important ?
j'ai essayer de regarder dans la FAQ mais j'ai rien trouvé ni dans mon petit bouquin eyrolles alors que je peux trouver polymorphisme et héritage oui ...
En gros les design patterns sont une sorte de "bonne pratiques de la programmation". Ce sont en fait un ensemble de solution connues pour des problèmes classiques de programmation.
Mais j'avoue que j'ai un peu de mal à saisir le lien avec la programmation orientée objet, dans la mesure ou le fait d'avoir des bonnes pratiques est plus ou moins indépendants du langage utilisé (même si une bone pratique aka un design pattern particulier peut lui être lié à un langage particulier, tu me suis?:mrgreen: )
Maintenant est-ce important?
Je dirai qu'à partir du moment ou l'on essaie d'attacher un tant soi peu d'importance à la qualité du code que l'on écrit, alors cela devient utile, voir essentiel.
Mais c'est aussi typiquement le genre de chose qui s'acquiert avec le temps. Néanmoins, il exite des bouquins sur ce genre de chose, aussi le fait d'en lire l'un ou l'autre peut être utile si tu veux faire carrière dans la prog.
Les design patterns, c'est un ensemble de design typiques qu'on retrouve fréquemment et qui permettent de répondre à certaines question fréquentes - pattern stratégie, state, la factory, le singleton, composite, sont sans doute les plus connus. La référence des DP : http://uml.developpez.com/livres/#L0201634988
:mouarf: ^^ j'ai comme l'impression qu'on a les mêmes lectures. j'ai opté pour la VF
oki. Cela me tente pas trop de payer un bouquin juste pour le design pattern ...
J'ai trouvé 2 tutoriels :
http://abrillant.developpez.com/tuto...oduction/#L3.2
http://smeric.developpez.com/java/uml/singleton/
je regarderai ca demain ...
merci
Fait gaffe de ne pas abuser du singleton ;) C'est largement pas le plus important. Et si, ça vaut la peine de le lire, ce livre, c'est LA référence, les tutos ne sont pas aussi complets.
J'aurai mis :Citation:
Envoyé par weed
- l'encapsulation
- l'héritage
- le polymorphisme
C'est vrai que les design patterns ne sont pas fondamentaux à l'orienté objet.
et bien c'est à dire que lors de mon entretien c'etait ca. C'etait une SSI qui était assez tourné vers la finance ....
De plus, j'ai envoyé un CV à une annonce proposant formation + emploi et on peut trouver sur cette annonce :
apparrement ils ont l'air de trouver cela important pour en avoir entendu parler 2 fois (entretien + annonce)Code:
2
3
4
5
6
les design patterns sont importants à connaître si on veut programmer efficacement et sans réinventer la roue. mais ça n'est pas fondamental à l'objet, on peut avoir des patrons de conception ailleurs qu'en programmation orientée objet. aujourd'hui beaucoup d'offres d'emploi en informatique objet demandent de connaître les (des) patrons. (on en utilise sans le savoir. mais c'est mieux de les connaître pour pouvoir réutiliser les méthodes de conception).
par contre l'héritage, le polymorphisme et l'encapsulation sont intrinsèquement liés à la programmation objet. c'est en ça qu'on dit qu'ils sont fondamentaux.
C'est Pourtant si pratique ;-)Citation:
Envoyé par Miles
Plus sérieusement, un bon développeur doit connaitre les design pattern.
Je t'assure que lorsque tu as commencé tu arrete plus.
DESIGN PATTERN par la pratique de A. Shalloway et J.R. Trott chez Eyrolles
est ce que j'ai trouvé de mieux.
250 pages pour connaitre le principal, aprés libre a toi de découvrir les autres.
Le plus important étant d'acquérir une démarche te permettant de concevoir ton programme le mieux possible et c'est la que ce bouquin est GENIAL.
Il y a des design patterns pour chaque domaine ou presque. Il y a les généraux qui sont dans le livre DP, après selon le domaine, on en trouve dans des livres sur le domaine.
- Abstraction (l'encapsulation n'est que le moyen d'y parvenir)Citation:
Envoyé par CGi
- Polymorphisme d'inclusion (qui sous entend un peu l'aspect le plus important de l'héritage, AMHG)
Comme quoi, on a tous des visions différentes :mrgreen:
Les design patterns ou modèles de conception en francais sont en quelque sorte des algorithmes orientés conception.
Ils proposent un modèle d'organisation de classes en vue de résoudre un problème récurrent et générique.
Ils sont le fruits de l'experience de nombreux programmeurs qui se sont heurté aux mêmes difficultées et ayant eu le même probleme de conception à résoudre.
La POO permet la réutilisabilité des classes, les design patterns permettent la réutilisabilité des idées.;)
Ils sont très utiles dans la mesure où ils définissent de bonnes règles de programmation orientée objet.
Voici à titre d'exemple l'une de ces règles:
Un programme doit être ouvert à l'extension mais fermé aux changements.8-)
Si l'on respecte ce precepte de conception poo, on s'assure la possibilité de pouvoir faire évoluer son code tout en ayant une maintenance efficace sur celui ci en évitant à avoir à retoucher et modifier son code en de multiples endroits.
On en déduit qu'il faut encapsuler ce qui varie dans des classes séparées.
Il ya tellement de choses à dire sur les design patterns que je renvoie à la litterature existante notamment le book du GOF à l'origine des patterns.
En ce qui me concerne j'ai tendance à penser "Pattern" pour coder "Hello world".:mrgreen:
Il ne faut pas trop en abuser car ça alourdit le prog en nombre de classes.
PS/ Méconnus et pourtant tout aussi utiles, j'ai l'honneur de vous présenter les anti patterns! (exemple le marteau d'or)8O
Pour les antipatterns, une première approche:
http://fr.wikipedia.org/wiki/Antipattern
C'est de plus en plus connus, ça ;)
Un livre est sorti sur un antipattern pour certains : l'eXtreme Programming.
J'aurais classer l'Abstraction comme un "modèle de conception"Citation:
Envoyé par Luc Hermitte
utilisant plutôt le polymorphisme ?
Abstraction déjà avant le polymorphisme pour le concept des classes, je pense. On abstrait la notion d'un système en le considérant comme un objet et non pas comme une somme de structures sur lesquelles des fonctions agissent.