Intérêt de la programmation objet [Résolu]

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.

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.

ben c.a.d que les classes, c'est parfois très utile.

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

Donc l'objet est quand même intéressant. :)

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?

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.