c'est pas une histoire de meilleur concept. Ce sont juste des conceptions différentes.
À partir de là, je ne crois qu'il y ait besoin de te vendre quoi que ce soit. Et oui bien sûr, on peut se débrouiller sans et oui tout ce qu'on fait dans un concept, on peut le faire dans un autre. Il suffit de voir tout ce qu'ont fait des millions de développeurs dans le monde, qu'ils utilisent une logique impérative, fonctionnelle, objet, déclaratif, etc. en-veux-tu-en-voilà (et avant ça y a des dizaines d'années, des programmes étaient entièrement écrit en assembleur, c'est dire si on peut tout faire quel que soit la "famille" du langage).
Par contre c'est simplement que certains concepts s'adaptent plus aisément à certains problèmes que d'autres.
Par exemple, si je développe un programme où les données rentre, sont traitées, sortent constamment, je vois tout de suite du fonctionnel: t'as une entrée, une sortie et une boîte noire au milieu.
L'objet est vraiment très agréable et permet des designs très "évident" (donc agréable à utiliser) pour tous les problèmes avec des "entités", que l'on peut conceptualiser, qui ont des caractéristiques et qui peuvent effectuer certaines actions.
Etc.
En fait il faut juste voir des classes de problématiques et ce qui permettra de faire la plus jolie et évidente API (soit parce que c'est le but final, ou soit parce qu'on va l'utiliser soi-même). Ça n'empêche pas qu'il y a en fait 1000 autres designs possibles pour la même fonctionnalité et qu'un autre design dans une tout autre logique peut également être très agréable.
C'est juste une question de choix.
Enfin y a la question du langage à utiliser. Personnellement je m'adapte. Quand j'écris en OCaml par exemple, je pense essentiellement soit classe soit fonctionnel. Mes programmes n'auront (presque) jamais la moindre boucle, je préfère les retours de fonctions aux références, et je m'arrange pour que mes fonctions récursives soient toujours terminales (sauf si la complication apportées ne vaut pas le gain. Ça arrive parfois, par exemple pour les fonctions qui auront des appels récursifs peu profond par design).
Si par contre j'écris en C, je fais des boucles, des paramètres par références et du massivement impératif comme tout le monde.
Il faut savoir profiter des forces d'un outil.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Quelqu'un dans l'assemblée saurait "vendre" le concept de POO ?
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Le problème de la POO pratiquée par des étudiants. Évalué à 4.
Salut,
c'est pas une histoire de meilleur concept. Ce sont juste des conceptions différentes.
À partir de là, je ne crois qu'il y ait besoin de te vendre quoi que ce soit. Et oui bien sûr, on peut se débrouiller sans et oui tout ce qu'on fait dans un concept, on peut le faire dans un autre. Il suffit de voir tout ce qu'ont fait des millions de développeurs dans le monde, qu'ils utilisent une logique impérative, fonctionnelle, objet, déclaratif, etc. en-veux-tu-en-voilà (et avant ça y a des dizaines d'années, des programmes étaient entièrement écrit en assembleur, c'est dire si on peut tout faire quel que soit la "famille" du langage).
Par contre c'est simplement que certains concepts s'adaptent plus aisément à certains problèmes que d'autres.
Par exemple, si je développe un programme où les données rentre, sont traitées, sortent constamment, je vois tout de suite du fonctionnel: t'as une entrée, une sortie et une boîte noire au milieu.
L'objet est vraiment très agréable et permet des designs très "évident" (donc agréable à utiliser) pour tous les problèmes avec des "entités", que l'on peut conceptualiser, qui ont des caractéristiques et qui peuvent effectuer certaines actions.
Etc.
En fait il faut juste voir des classes de problématiques et ce qui permettra de faire la plus jolie et évidente API (soit parce que c'est le but final, ou soit parce qu'on va l'utiliser soi-même). Ça n'empêche pas qu'il y a en fait 1000 autres designs possibles pour la même fonctionnalité et qu'un autre design dans une tout autre logique peut également être très agréable.
C'est juste une question de choix.
Enfin y a la question du langage à utiliser. Personnellement je m'adapte. Quand j'écris en OCaml par exemple, je pense essentiellement soit classe soit fonctionnel. Mes programmes n'auront (presque) jamais la moindre boucle, je préfère les retours de fonctions aux références, et je m'arrange pour que mes fonctions récursives soient toujours terminales (sauf si la complication apportées ne vaut pas le gain. Ça arrive parfois, par exemple pour les fonctions qui auront des appels récursifs peu profond par design).
Si par contre j'écris en C, je fais des boucles, des paramètres par références et du massivement impératif comme tout le monde.
Il faut savoir profiter des forces d'un outil.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]