Je vais essayer de compléter un peu la réponse de
Cyrano vis à vis de
FredoMkb. En effet, l'objet n'a rien d'une obligation et que tout ce qu'on fera en objet pourra tout aussi bien être fait en procédural (on arrivait très bien à développer avant de voir débarquer les objets
), mais il apporte quand même quelques avantages : ils permettent de modéliser de façon simple et clair un élément de n'importe quel domaine, parce qu'ils sont réutilisables et parce qu'ils garantissent l'intégrité des données.
Oublions la calculette quelques instant. Elle permet de comprendre comment créer un objet, mais pas forcément de voir l'étendu de ce que l'on peut faire avec. Supposons une classe "Véhicule" avec ses attributs (immatriculation, compteur km, couleur, ...) et ses méthodes (démarrer, se garer, faire la vidange, faire le plein...). Chaque instance de cette classe correspond à un véhicule spécifique : une voiture bleue avec 20.000km, une moto rouge avec 50.000km, etc.
Ce qui fait le succès de la POO c'est principalement :
- L'encapsulation : c'est le fait de rassembler les attributs et les méthodes au sein d'un composant (mon Véhicule) en cachant l'implémentation de l'objet. Cela empêche l'accès aux données par un autre moyen que les services proposés, et permet donc de garantir l'intégrité des données contenues dans l'objet. Tu n'as pas besoin de savoir si la voiture instanciée fonctionne au super, au gazoil, ou au gpl, tu lui demandes juste de faire le plein, et moi je serais certain que tu ne te tromperas pas puisque tu n'auras pas directement accès au réservoir
(et mine de rien, pour un travail collaboratif, être sur que les autres ne pourront pas se tromper en manipulant tes objets est un plus non négligeable !)
- L'héritage : cela permet de créer une nouvelle classe à partir d'une classe existante, la classe dérivée contient alors les attributs et les méthodes de sa superclasse. L'intérêt est de pouvoir définir de nouveaux attributs et méthodes pour la classe dérivée, qui viennent s'ajouter à ceux et celles héritées. Une "Voiture" et une "Moto" peuvent ainsi hériter des propriétés propre à n'importe quel "Véhicule" (immatriculation, km, ..) et apporter leurs propriétés spécifiques (toit ouvrant pour la voiture, béquille pour la moto, etc.). Une fois encore, en cas de travail collaboratif, si quelqu'un dérive ta classe, tu es sur que ce que toi tu as implémenté sera disponible dans la sienne, a lui de gérer le fait que s'il fait une classe Vélo, elle devra trouver un moyen de faire le plein
(ou alors peut être revoir s'il n'est pas plus judicieux de définir cette méthode dans une classe "Véhicule Motorisé" héritant de "Véhicule"
)
- Le polymorphisme : c'est le fait de pouvoir surcharger ou redéfinir une méthode. En java un objet peut avoir plusieurs méthodes portant le même nom, mais dont les paramètres diffèrent. Chacune peut alors avoir un fonctionnement différent selon que tu lui passes un entier en paramètre, ou une chaine, etc. sans nécessiter de tests ou de contrôles supplémentaires. En php, le polymorphisme se traduit surtout par la surcharge dans une classe dérivée. Ma "Voiture a essence" qui hérite de "Véhicule" réagira à la commande "faire la plein" en allant à la pompe et en remplissant le réservoir, tandis que ma "Voiture Electrique" ira recharger la batterie en la branchant a une prise electrique. L'intérêt c'est que pour toi, tout cela est entièrement transparent, tout ce que tu as à faire, c'est appeller la méthode "faire le plein" de ton Véhicule quand tu auras détecté qu'il est sur la réserve
Tes objets sont ensuite réutilisable par n'importe qui sur le projet, voire pour d'autre projet (et sans risque d'altérer l'intégrité des données), ils peuvent être appliqués à n'importe quel domaine (pourquoi pas une calculette scientifique qui hériterait des fonctions de base de notre calculette et proposerait également des log ou des exponentielles, surchargeant la fonction addition pour que le calcul se fasse en binaire ou en héxa, etc.
)
