Poo
cELINE
-
Pacorabanix Messages postés 4122 Date d'inscription Statut Membre Dernière intervention -
Pacorabanix Messages postés 4122 Date d'inscription Statut Membre Dernière intervention -
Bonjour, hier ou plus tot, j'ai lu un message d'un membre qui demandait si la programmation orientée objet était devenue incontournable ou un terme du genre.
Moi qui débute en programmation et qui suis encore à la recherche du bon langage, j'ai trouvé ce message intéressant.
Bizarrement, personne ne lui a répondu... C'est dommage, car j'aurais aussi aimé avoir l'avis de spécialistes.
Je me suis un peu documentée et j'avoue ne pas tres bien saisir l'utilité incontournable de la chose.
En 'C' classique, on fait un peu la même chose en mettant ses fonctions ou autres dans des fichiers headers.
Enfin, si quelqu'un a le temps et la bonne idée de m'expliquer, je suis preneuse.
merci
Moi qui débute en programmation et qui suis encore à la recherche du bon langage, j'ai trouvé ce message intéressant.
Bizarrement, personne ne lui a répondu... C'est dommage, car j'aurais aussi aimé avoir l'avis de spécialistes.
Je me suis un peu documentée et j'avoue ne pas tres bien saisir l'utilité incontournable de la chose.
En 'C' classique, on fait un peu la même chose en mettant ses fonctions ou autres dans des fichiers headers.
Enfin, si quelqu'un a le temps et la bonne idée de m'expliquer, je suis preneuse.
merci
A voir également:
- Poo
- Happy poo - Télécharger - Arcade
4 réponses
Bonjour!
Les intérêts de la POO :
-Les classes qui composeront le programme peuvent être réutilisables.
-Les notions d'héritage, d'abstraction et d'interface permettent de mieux structurer le code et, surtout, de ne pas coder plusieurs fois la même chose.
-Le code, réparti en classes, permet une maintenance plus aisée et plus d'évolutivité.
J'en oublie sûrement mais le plus important est là.
J'espère avoir été clair.
Les intérêts de la POO :
-Les classes qui composeront le programme peuvent être réutilisables.
-Les notions d'héritage, d'abstraction et d'interface permettent de mieux structurer le code et, surtout, de ne pas coder plusieurs fois la même chose.
-Le code, réparti en classes, permet une maintenance plus aisée et plus d'évolutivité.
J'en oublie sûrement mais le plus important est là.
J'espère avoir été clair.
premièrement il permet au code d'être plus proche de notre logique de départ, les "objet" informatique représentent des objets réels. Si tu programme un jeu de rôle, tu va créer la classe "personnage" puis la classe "objet"...
en plus ce qui est bien c'est qu'un objet peut en hériter d'un autre.
une arme est un objet qui a comme particularité qu'elle peut attaquer un personnage.
un joueur est un personnage qui a la particularité d'être commendé par un humain.
Ca permet de surcharger le code, tu n'écris qu'une seule fois les fonctions communes et ensuite tu créer des classes enfants, ainsi tu n'appelles pas 100 fois la même fonction, tu ne fias pas 100 fois la même ligne de code...
Il y a aussi certaines particularité quant à la rapidité d'exécution mais là je connais pas plus.
De plus si c'est incontournable c'est aussi parce que de plus en plus de programme et de langages sont orientés objet : C++, Java, PHP sont les plus connus, chacun ayant son utilisation.
en plus ce qui est bien c'est qu'un objet peut en hériter d'un autre.
une arme est un objet qui a comme particularité qu'elle peut attaquer un personnage.
un joueur est un personnage qui a la particularité d'être commendé par un humain.
Ca permet de surcharger le code, tu n'écris qu'une seule fois les fonctions communes et ensuite tu créer des classes enfants, ainsi tu n'appelles pas 100 fois la même fonction, tu ne fias pas 100 fois la même ligne de code...
Il y a aussi certaines particularité quant à la rapidité d'exécution mais là je connais pas plus.
De plus si c'est incontournable c'est aussi parce que de plus en plus de programme et de langages sont orientés objet : C++, Java, PHP sont les plus connus, chacun ayant son utilisation.
Moi je trouve la POO horriblement tortueuse.
c'est grâce à l'héritage, que si tu ne fais pas gaffe, un poisson parlera ou une voiture nagera, etc... etc...
c'est grâce à l'héritage, que si tu ne fais pas gaffe, un poisson parlera ou une voiture nagera, etc... etc...
il se trouve que les avantages directs de la poo (qu'a décrit artragis) sont là pour prolonger les avantages que donne la programmation par fonction habituelle.
En fait en C on voit déjà l'"embryon" de la POO dans les "struct".
Il faut vraiment retenir que l'avantage se situe vraiment au niveau de la conception de programme (l' "ingénierie logicielle" ). En effet, de nos jours les logiciels sont programmés en général avec des équipes, qui incluent souvent au moins une dizaine d'intervenants, ou plus. Les programmeurs réutilisent des morceaux de code fait aussi par des programmeurs qu'ils ne connaissent pas.
Tout cela est une énorme, gigantesque, source de bugs possibles. Comment être sûr de bien utiliser un groupe de fonctions que tu n'as pas programmé toi-même ? Lorsque les choses deviennent très techniques, qu'il y a des centaines de fonctions à droite à gauche, une simple petite modification peut devenir longue (et donc coûteuse !!!). Il faut comprendre le code, le modifier, tester, et si quelques semaines ou mois plus tard on trouve un bug, il se peut très bien que ce soit à cause de cette petite modification qu'on a fait, perdue au fin fond du programme.
La POO essaye d'améliorer les choses en proposant une conception par modules (qui sont les classes). L'idée est de se forcer à proposer et à utiliser une "interface" (c-à-d quelques méthodes et fonctions publiques bien documentées, et qui s'occupent de fonctionner comme il se doit et de surveiller les erreurs ou les mauvaises utilisations). ainsi, si pour ton programme de comptabilité tu as besoin d'accéder à des bases de données : tu utilises des objets qui font office de client pour la base de donnée. Si dans la fenêtre de ton programme tu as besoin d'un composant style tableur, tu l'inclus tout simplement, en tant qu'objet, dans ta fenêtre, que tu peux voir aussi comme un objet. etc....
Tout ce que tu fais avec la POO, tu peux tout à fait en théorie avoir le même résultat sans POO. Mais c'est dans les gros programmes que la différence d'efficacité (coût de production et traitement des bugs, temps utilisé...) est nette.
En séparant encore plus les tâches de tes sous--programmes en classes (ou en groupes de classes), tu permets à toute l'équipe de mieux voir et agir pour la création du logiciel. L'équipe (ou l'"architecte") se met d'accord pour concevoir ensemble comment les divers objets doivent être utilisés, et ensuite chaque programmeur ou petite équipe peut travailler indépendamment et programmer l'implémentation à sa manière (la partie private), sans risque qu'une de ses idées viennent "foutre en l'air" tout le programme, du moment qu'il respecte ce que doivent faire les méthodes publiques de sa classe.
Il faut vraiment se rendre compte qu'un bug difficile à trouver coûte énormément à la société qui utilise le programme (les clients des programmeurs ! ) et donc perte d'argent pour les développeurs, et surtout perte de réputation si le bug perdure, etc...
En fait en C on voit déjà l'"embryon" de la POO dans les "struct".
Il faut vraiment retenir que l'avantage se situe vraiment au niveau de la conception de programme (l' "ingénierie logicielle" ). En effet, de nos jours les logiciels sont programmés en général avec des équipes, qui incluent souvent au moins une dizaine d'intervenants, ou plus. Les programmeurs réutilisent des morceaux de code fait aussi par des programmeurs qu'ils ne connaissent pas.
Tout cela est une énorme, gigantesque, source de bugs possibles. Comment être sûr de bien utiliser un groupe de fonctions que tu n'as pas programmé toi-même ? Lorsque les choses deviennent très techniques, qu'il y a des centaines de fonctions à droite à gauche, une simple petite modification peut devenir longue (et donc coûteuse !!!). Il faut comprendre le code, le modifier, tester, et si quelques semaines ou mois plus tard on trouve un bug, il se peut très bien que ce soit à cause de cette petite modification qu'on a fait, perdue au fin fond du programme.
La POO essaye d'améliorer les choses en proposant une conception par modules (qui sont les classes). L'idée est de se forcer à proposer et à utiliser une "interface" (c-à-d quelques méthodes et fonctions publiques bien documentées, et qui s'occupent de fonctionner comme il se doit et de surveiller les erreurs ou les mauvaises utilisations). ainsi, si pour ton programme de comptabilité tu as besoin d'accéder à des bases de données : tu utilises des objets qui font office de client pour la base de donnée. Si dans la fenêtre de ton programme tu as besoin d'un composant style tableur, tu l'inclus tout simplement, en tant qu'objet, dans ta fenêtre, que tu peux voir aussi comme un objet. etc....
Tout ce que tu fais avec la POO, tu peux tout à fait en théorie avoir le même résultat sans POO. Mais c'est dans les gros programmes que la différence d'efficacité (coût de production et traitement des bugs, temps utilisé...) est nette.
En séparant encore plus les tâches de tes sous--programmes en classes (ou en groupes de classes), tu permets à toute l'équipe de mieux voir et agir pour la création du logiciel. L'équipe (ou l'"architecte") se met d'accord pour concevoir ensemble comment les divers objets doivent être utilisés, et ensuite chaque programmeur ou petite équipe peut travailler indépendamment et programmer l'implémentation à sa manière (la partie private), sans risque qu'une de ses idées viennent "foutre en l'air" tout le programme, du moment qu'il respecte ce que doivent faire les méthodes publiques de sa classe.
Il faut vraiment se rendre compte qu'un bug difficile à trouver coûte énormément à la société qui utilise le programme (les clients des programmeurs ! ) et donc perte d'argent pour les développeurs, et surtout perte de réputation si le bug perdure, etc...
