Bien que, en définitive, on en reviendra toujours à plus ou moins brève échéance à une programmation purement séquentielle, le fait de lier les données et leur utilisation dans la programmation orientée objet va engendrer pour le programmeur de nouveaux concepts qu'il est important qu'il garde en tête, s'il souhaite utiliser cette technique pour créer des applications de qualité.
Tous ces concepts seront pleinement expliqués au fil des pages de ce chapitre, mais il me semble intéressant d'en dresser la liste ici.
Jutiliserai dans cette section exactement le même pseudo code que celui que j'ai utilisé dans la section principes de programmation, et ce, d'autant plus que l'ensemble des concepts qui y sont indiqués restent d'application
Bien que le nom puisse varier en fonction du langage utlisé, quand on regroupe les données et les fonctions et procédures qui servent à les utiliser, nous créeons un objet tout à fait indépendant que nous nommons "classe".
Cet "objet" pourra alors être utilisé tout seul, et il suffira d'appeler les fonctions et procédures qu'il contient pour manipuler, de manière plus ou moins sécurisante, les données qui nous intéressent.
Il s'agira, le plus souvent, d'une structure telle que l'on en trouve en programmation séquentielle, mais à laquelle sont attachées les fonctions et procédures qui sont propre à l'utilisation des données.
Comme je l'ai indiqué plus haut, un objet n'est jamais qu'une structure de données améliorée.
Le terme utilisé pour représenter les données en elles-mêmes est "membre".
Comme il ne s'agit ni plus ni moins que de variables, les membres seront déclarés exactement comme tel.
Leur déclaration fournira donc un type de données, qui peut être un type de base, une structure ou même une autre classe, un nom pour la désignation et l'indication qui permet de savoir s'il s'agit de la variable elle-même ou d'un pointeur sur cette variable.
Le deuxième élément que l'on trouve dans un objet n'est rien d'autre que les fonctions et procédures qui permettent de manipuler les informations contenues par l'objet.
Comme ces fonctions et procédures servent, théoriquement du moins, qu'à travailler sur les membres de l'objet, on utilise le therme méthode pour les désigner.
L'héritage est sans doute l'un des concepts primordiaux, tant dans la vie de tous les jours (et pas rien que pour "récupérer la fortune de l'oncle d'amérique") qu'en programmation orientée objet.
En effet, une porte en fer hérite (récupère des valeurs, des capacités) à vrai dire de deux "choses" distinctes:
C'est d'abord une porte, et à ce titre, elle dispose des mêmes états que n'importe quelle porte (ouverte/fermée, verrouillée ou non) et des mêmes possiblités d'utilisation (ouverture, fermeture, verouillage ou déverrouillage).
Mais c'est aussi un objet en fer, et à ce titre, elle reçoit les caractéristiques propres au fer, qui sont différentes du bois, du carton ou de la pierre.
En programmation orientée objet, un objet de type "client" pourrait très bien hériter des caractéristiques d'un autre objet de type "personne" (nom, prénom, adresse etc), et un troisième objet de type "fournisseur" pourrait également récupérer les caractérisitque du type "personne".
Simplement, on assiste alors à une «spécialisation» du type personne:
Aucun objet n'apparaît jamais de manière spontanée, par la simple volonté de la personne qui en a besoin…
Si vous avez une boîte de soda en main, c'est grâce au fait qu'une usine a fabriqué le soda en mélangeant différents ingrédients, et en a mis une certaine quantité dans la boîte.
De même, quand vous allez avoir besoin d'un objet en programmation, de nombreux langages ont besoin de "l'usine" qui permet d'assembler les différentes données nécessaires au bon fonctionnement. Cette "usine" s'appelle tout simplement le constructeur.
Il n'y a pas plus de chances de voir la boîte de soda que vous venez de boire disparaître que de la voir apparaître, comme cela "par enchantement"…
En cette période où le recyclage devient monnaie courrante, il y a de fortes chances pour qu'au moins certains d'entre vous la mettent avec pleins de ses petites soeurs dans un sac prévu à cet effet, et qu'au final, elle se retrouve dans une usine spécialisée dans la destructions des boîtes en fer blanc, afin de servir à autre chose…
En informatique, je vous ai déjà dis plus haut que tout se trouve dans la mémoire de l'ordinateur.
Or, même si la mémoire disponible augmente sans cesse, il est bon de prévoir la libération de celle-ci de manière à la rendre disponible pour une utilisation suivante.
Le travail de libération de la mémoire de tous les composant d'un objet sera pris en charge par une fonction particulière: le destructeur.
Avez-vous déjà remarqué pour combien d'objets de la vie courrante il existe des actions qui portent le même nom, et qui, pourtant donnent un résultat différent?
L'action allumer, par exemple, est disponible pour le four (à gaz), la radio ou la lumière et pour un simple feu de bois (ou un barbecue, en saison)
Ceci dit, même si le résultat semble différent, le résultat final sera bel et bien identique: le barbecue et la radio seront utilisables (le barbecue pour cuire de la viande et la radio pour entendre les dernières nouvelles du monde)
Et pourtant, la manière meme d'allumer ces différentes choses sera tout à fait différente, selon la chose que vous voulez allumer, et donnera, fatalement, un résultat différent si vous allumez la radio que si vous allumez votre barbecue. Je n'ai personnellement jamais vu un barbecue permettre d'écouter les informations, et, si j'ai vu une radio commencer à chauffer, ce n'était généralement pas le but recherché
Mais, même en restant dans des ensembles d'objets de même famille, par exemple celle des des motos et cyclomoteurs, certaines actions, pourtant identiques par leur nom, peuvent être effectuées différemment selon la spécialisation de la chose:
Ainsi, tout véhicule à moteur dispose d'une action "démarrer".
Pour les voitures et certains camions, il s'agira généralement de tourner la clé un peu plus loin que sa position "on".
Par contre, pour certaines motos et pour certains camions, le démarrage s'obtiendra en poussant sur un bouton particulier.
Enfin, sur d'autres motos, le démarrage sera obtenu grâce au "coup de kick".
Le polymorphisme, bien que ce soit l'un des concepts les plus crains par les programmateurs débutants, ce n'est rien d'autre que cela: Le fait qu'une même action provoque les mêmes effets, tout en étant effectuée de manière différente en fonction de l'objet sur lequel l'action a lieu.
Quand vous avez une porte en fer, nous avons vu plus haut que la porte hérite aussi bien des caractéristiques propres d'une porte que de celles du fer.
Cependant, lorsque l'on utilise une porte en fer, on utilisera beaucoup plus les caractéristiques venant de la porte que celle venant du fer, sans pour autant les perdre.
Par contre, les caractéristiques du fer deviendront importantes pour la personne qui sera en charge de construire la porte, alors que les actions comme "ouvrir" , "fermer" ou "(dé)verouiller" seront beaucoup moins importantes à ces yeux.
Dans les langages de programmation orientés objet, on trouve le même système de possiblité d'acces aux différents membres et méthodes.
Le plus souvent, on distingue trois niveaux d'accessiblité:
De cette manière, on pourrait très bien considrérer que la température de fusion du fer, vu qu'elle fait partie intégrante de notre porte en fer, mais que nous n'y avons pas acces, est en réalité un membre privé de l'objet "fer"
Bien souvent, les langages orientés objet acceptent l'idée de ce que l'on appelle «la surcharge des fonction», c'est à dire le fait que plusiseurs fonctions aient le même nom au sein d'un même objet.
En effet, il est parfois utile de pouvoir obentir un résultat donné en fournissant des données difféntes.
De la même manière, on peut vouloir utiliser un opérateur d'addition, de soustraction, ou de vérification d'égalité sur une structure bien plus complexe qu'un simple caractère ou un numérique quelconque (entier ou réel)
Néanmoins, pour que l'on puisse créer plusieurs fonctions qui ont le même nom dans une seule et même classe, il est primordial que le langage soit en mesure de déterminer quelle fonction il doit appeler.
Le seul moyen de faire savoir quelle fonction il doit appeler, c'est que la liste des arguments fournis soit clairement différente (un argument de plus suffit)
En mettant correctement en oeuvre les concepts d'héritage, de polymorphisme et d'accessibilité, et bien sûr, en programmant des méthodes de manière correcte, il devient tout à fait possible de créer des objets réutilisables très robustes, c'est à dire, dont l'utilisateur ne risquera pas de modifier par erreur une valeur qu'il ne devrait pas.
En effet, la personne qui a une porte en fer à l'entrée de sa maison est dans l'impossiblité de modifier la température de fusion du fer qui compose la porte 
Copyright (©) 2005 (Philippe Dunski)
Ce cours est libre, vous pouvez le redistribuer et/ou le modifier selon les termes de la Licence Publique Générale GNU publiée par la Free Software Foundation (version 2 ou bien toute autre version ultérieure choisie par vous).
Ce cours est distribué car potentiellement utile, mais SANS AUCUNE GARANTIE, ni explicite ni implicite, y compris les garanties de commercialisation ou d'adaptation dans un but spécifique. Reportez-vous à la Licence Publique Générale GNU pour plus de détails.
Cependant, l'auteur apprécierait grandement que vous lui fassiez part de toute modification apportée à son contnu
Vous pouvez le contacter par mail à l'adresse koala01@free.fr
Vous pouvez trouver une adaptation française de la licence GNU/GPL à l'URL http://www.linux-france.org/article/these/gpl.html
