Intérêt de la programmation objet
Résolu/Fermé
Absot
Messages postés
777
Date d'inscription
mardi 28 octobre 2008
Statut
Membre
Dernière intervention
4 septembre 2020
-
24 nov. 2009 à 23:20
Klaude medhi - 2 janv. 2018 à 07:19
Klaude medhi - 2 janv. 2018 à 07:19
A voir également:
- Intérêt de la programmation objet
- Vente objet occasion entre particulier - Guide
- Application de programmation - Guide
- Programmation - Guide
- Logiciel programmation clé voiture gratuit - Forum Programmation
- Objet rare akinator ✓ - Forum Loisirs / Divertissements
7 réponses
Pacorabanix
Messages postés
3248
Date d'inscription
jeudi 23 août 2007
Statut
Membre
Dernière intervention
19 mai 2013
660
26 nov. 2009 à 00:35
26 nov. 2009 à 00:35
voici un exemple peut-être plus concret.
Tu as compris l'intérêt de décomposer ton programme en sous-programmes qu'on appelle fonctions et/ou procédures ?
C'est très bien car ça donne plus de clarté et surtout ça permet d'éviter de devoir recopier plusieurs fois la même chose.
Ensuite imagine que tu as toutes sortes de fonctions, certaines écrites par toi-même, certaines écrites par d'autres (des collègues ou prise sur internet, ou même achetées à des entreprises). Et imagine que tu conçois, à l'aide d'une équipe de programmeurs, un jeux vidéo.
Ton programme sera énorme. Avec toutes les nombreuses fonctions que tu utilises, créer correctement le programme devient un casse-tête.
Selon comment tes collègues programment, et selon ce que tu fais toi et de ce que tu as compris de leur programme, lorsqu'il faudra modifier une certaine fonction, il faudra toujours faire attention à toutes les autres qui les appellent. Pour un jeu, il y a du code pour l'affichage, du code pour la gestion du clavier et de la souris et des manettes, du code pour le scénario, du code pour sauvegarder dans un fichier, du code pour l'intelligence artificielle, etc...
La décomposition en objets permet d'encore plus séparer le programme que simplement en diverses fonctions. On décompose le programme en modules "autonomes" qui savent comment se comporter et qui sont très clair sur la façon de les utiliser.
Ainsi, ton programme sera décomposé en objets divers et variés. Des objets plutôt abstrait par exemple pour s'occuper de l'affichage du jeu ainsi que des menus, un autre pour l'intelligence artificielle... et aussi des objets plus concrets qui te servent par exemple à créer de nouveaux "types" de données plus faciles à manipuler : un type "Personnage". Ce type servira à représenter tout type de personnage dans ton jeu. Cet objet aura des méthodes et des propriétés. Une méthode comme "JouerSon()" qui fera jouer un certain son propre à chaque personnage. Ce sont peut-être un fichier que la méthode va ouvrir, un son préenregistré, de différent format selon l'humeur de votre équipe de programmation... Il y a plein de possibilités de changement. Mais vous aurez bien défini que de toute façon il faudra appeler cette méthode "JouerSon()" de l'objet : vous avez défini son interface publique.
Après, comment exactement est programmé le détail de cette méthode, quel algorithmes, quelles fonctions du système est utilisée, ça c'est à l'équipe qui travaille dessus de voir. Dans tous les cas ceux qui auront besoin de faire appel à cette méthode (par exemple ceux qui programment le scénario) savent très clairement comment l'appeler, et ainsi les choses deviennent beaucoup plus "propres", plus lisibles pour toute l'équipe.
Ensuite, la programmation objet utilise aussi le principe de l'héritage pour réutiliser le code déjà fait : certains personnages particuliers auront besoin de plus de méthodes que celle, basiques, du type "Personnage" de base. Pas de problème ! Au lieu de faire copié-collé le code et de refaire autre chose, on peut créer une classe spécialisée (Ex : Monstre, Marchand, Compagnon de jeu, Joueur) qui auront toutes en commun d'avoir certaines propriétés et méthodes (comme JouerSon() ), mais qui auront d'autres choses plus spécialisées propres à eux, qui n'auraient pas de sens pour les autres. Les "Monstres" par exemple auraient une méthode CalculerValeur() qui renvoie ce qu'on gagne si on les tue. Les "Marchands" auraient une méthode AfficherListeObjets() qui permet de voir ce qu'ils ont à vendre.
Je ne sais pas si mon exemple était parlant.
Tu as compris l'intérêt de décomposer ton programme en sous-programmes qu'on appelle fonctions et/ou procédures ?
C'est très bien car ça donne plus de clarté et surtout ça permet d'éviter de devoir recopier plusieurs fois la même chose.
Ensuite imagine que tu as toutes sortes de fonctions, certaines écrites par toi-même, certaines écrites par d'autres (des collègues ou prise sur internet, ou même achetées à des entreprises). Et imagine que tu conçois, à l'aide d'une équipe de programmeurs, un jeux vidéo.
Ton programme sera énorme. Avec toutes les nombreuses fonctions que tu utilises, créer correctement le programme devient un casse-tête.
Selon comment tes collègues programment, et selon ce que tu fais toi et de ce que tu as compris de leur programme, lorsqu'il faudra modifier une certaine fonction, il faudra toujours faire attention à toutes les autres qui les appellent. Pour un jeu, il y a du code pour l'affichage, du code pour la gestion du clavier et de la souris et des manettes, du code pour le scénario, du code pour sauvegarder dans un fichier, du code pour l'intelligence artificielle, etc...
La décomposition en objets permet d'encore plus séparer le programme que simplement en diverses fonctions. On décompose le programme en modules "autonomes" qui savent comment se comporter et qui sont très clair sur la façon de les utiliser.
Ainsi, ton programme sera décomposé en objets divers et variés. Des objets plutôt abstrait par exemple pour s'occuper de l'affichage du jeu ainsi que des menus, un autre pour l'intelligence artificielle... et aussi des objets plus concrets qui te servent par exemple à créer de nouveaux "types" de données plus faciles à manipuler : un type "Personnage". Ce type servira à représenter tout type de personnage dans ton jeu. Cet objet aura des méthodes et des propriétés. Une méthode comme "JouerSon()" qui fera jouer un certain son propre à chaque personnage. Ce sont peut-être un fichier que la méthode va ouvrir, un son préenregistré, de différent format selon l'humeur de votre équipe de programmation... Il y a plein de possibilités de changement. Mais vous aurez bien défini que de toute façon il faudra appeler cette méthode "JouerSon()" de l'objet : vous avez défini son interface publique.
Après, comment exactement est programmé le détail de cette méthode, quel algorithmes, quelles fonctions du système est utilisée, ça c'est à l'équipe qui travaille dessus de voir. Dans tous les cas ceux qui auront besoin de faire appel à cette méthode (par exemple ceux qui programment le scénario) savent très clairement comment l'appeler, et ainsi les choses deviennent beaucoup plus "propres", plus lisibles pour toute l'équipe.
Ensuite, la programmation objet utilise aussi le principe de l'héritage pour réutiliser le code déjà fait : certains personnages particuliers auront besoin de plus de méthodes que celle, basiques, du type "Personnage" de base. Pas de problème ! Au lieu de faire copié-collé le code et de refaire autre chose, on peut créer une classe spécialisée (Ex : Monstre, Marchand, Compagnon de jeu, Joueur) qui auront toutes en commun d'avoir certaines propriétés et méthodes (comme JouerSon() ), mais qui auront d'autres choses plus spécialisées propres à eux, qui n'auraient pas de sens pour les autres. Les "Monstres" par exemple auraient une méthode CalculerValeur() qui renvoie ce qu'on gagne si on les tue. Les "Marchands" auraient une méthode AfficherListeObjets() qui permet de voir ce qu'ils ont à vendre.
Je ne sais pas si mon exemple était parlant.
Pacorabanix
Messages postés
3248
Date d'inscription
jeudi 23 août 2007
Statut
Membre
Dernière intervention
19 mai 2013
660
24 nov. 2009 à 23:25
24 nov. 2009 à 23:25
un tableau ne sert qu'à stocker une liste de plusieurs éléments de type identique...
Tu peux faire un tableau d'objets par exemple.
Mais l'intérêt principal de la conception objet est juste de faciliter la conception d'un programme. Tu ne t'en rends peut-être pas compte, mais en pratique ce sont des équipes de plusieurs programmeurs qui travaillent sur un projet. Si tout est mélangé, c'est le bazar et assigner telle ou telle tache à certains groupes de codeurs devient difficile, car il ne savent pas ce que vont faire leur collègues qui travaillent sur un autre morceau du programme qu'ils auront besoin d'utiliser.
En permettant de décomposer bien distinctement en modules qui ont chacun leur utilité propre (les classes) et qu'on invoque via une interface de méthodes publiques claires, la POO permet de limiter les risques de bugs qui se cachent dans les codes. Elle améliore aussi la réutilisabilité du code, encore une fois grâce au fait que l'implémentation est normalement cachée en privé et qu'on utilise l'objet que via une interface de méthodes publiques.
Ainsi, si on trouve un meilleur algorithme pour je-ne-sais-quoi, l'interface de l'objet peut rester la même mais l'implémentation changer, et on peut donc donner aux anciens utlisateurs de l'objet le nouveau sans qu'ils ne doivent étudier en détail les changements : pour eux pas de changement, c'est toujours la même interface publique.
Tu peux faire un tableau d'objets par exemple.
Mais l'intérêt principal de la conception objet est juste de faciliter la conception d'un programme. Tu ne t'en rends peut-être pas compte, mais en pratique ce sont des équipes de plusieurs programmeurs qui travaillent sur un projet. Si tout est mélangé, c'est le bazar et assigner telle ou telle tache à certains groupes de codeurs devient difficile, car il ne savent pas ce que vont faire leur collègues qui travaillent sur un autre morceau du programme qu'ils auront besoin d'utiliser.
En permettant de décomposer bien distinctement en modules qui ont chacun leur utilité propre (les classes) et qu'on invoque via une interface de méthodes publiques claires, la POO permet de limiter les risques de bugs qui se cachent dans les codes. Elle améliore aussi la réutilisabilité du code, encore une fois grâce au fait que l'implémentation est normalement cachée en privé et qu'on utilise l'objet que via une interface de méthodes publiques.
Ainsi, si on trouve un meilleur algorithme pour je-ne-sais-quoi, l'interface de l'objet peut rester la même mais l'implémentation changer, et on peut donc donner aux anciens utlisateurs de l'objet le nouveau sans qu'ils ne doivent étudier en détail les changements : pour eux pas de changement, c'est toujours la même interface publique.
scaravenger
Messages postés
2685
Date d'inscription
mercredi 28 mai 2008
Statut
Membre
Dernière intervention
30 janvier 2015
616
24 nov. 2009 à 23:25
24 nov. 2009 à 23:25
ben c.a.d que les classes, c'est parfois très utile.
nobie-cs
Messages postés
155
Date d'inscription
samedi 21 novembre 2009
Statut
Membre
Dernière intervention
15 mai 2010
17
24 nov. 2009 à 23:26
24 nov. 2009 à 23:26
un objet "voiture, carré ...." à un certain comportement "la voiture roule ..." un état " carré rouge... " et plein d'autre chose... par contre le tableau c'est un ensemble de valeur de même type stocké dans la mémoire une après l'autre
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
Absot
Messages postés
777
Date d'inscription
mardi 28 octobre 2008
Statut
Membre
Dernière intervention
4 septembre 2020
44
25 nov. 2009 à 20:12
25 nov. 2009 à 20:12
Donc l'objet est quand même intéressant. :)
Absot
Messages postés
777
Date d'inscription
mardi 28 octobre 2008
Statut
Membre
Dernière intervention
4 septembre 2020
44
25 nov. 2009 à 22:34
25 nov. 2009 à 22:34
Donc c'est important l'objet :D
Concrètement, quand est-ce que l'on créé un objet dans notre code?
Quand on a besoin d'exécuter des méthodes?
Concrètement, quand est-ce que l'on créé un objet dans notre code?
Quand on a besoin d'exécuter des méthodes?
Absot
Messages postés
777
Date d'inscription
mardi 28 octobre 2008
Statut
Membre
Dernière intervention
4 septembre 2020
44
27 nov. 2009 à 20:31
27 nov. 2009 à 20:31
Désolé de répondre si tard mais si, ton exemple est parlant, en fait je commence surtout à comprendre son intérêt en programmant tout seul de mon côté. :)
Je mets le sujet en résolu, merci de votre aide.
Je mets le sujet en résolu, merci de votre aide.
Pacorabanix
Messages postés
3248
Date d'inscription
jeudi 23 août 2007
Statut
Membre
Dernière intervention
19 mai 2013
660
27 nov. 2009 à 20:46
27 nov. 2009 à 20:46
de rien ;)
En fait, c'est vrai : tout seul c'est aussi très utile car on se perd soi-même très facilement, surtout quand on laisse son projet de coté quelque jours, et qu'on y revient ensuite : c'est comme si c'étaient d'autres personnes qui avaient programmé jusque là et des fois on a du mal à comprendre ce qu'on avait fait ;) .
Bonne suite
En fait, c'est vrai : tout seul c'est aussi très utile car on se perd soi-même très facilement, surtout quand on laisse son projet de coté quelque jours, et qu'on y revient ensuite : c'est comme si c'étaient d'autres personnes qui avaient programmé jusque là et des fois on a du mal à comprendre ce qu'on avait fait ;) .
Bonne suite
2 janv. 2018 à 07:19