Programmation Objet

"Les êtres humains ne vivent pas uniquement dans le monde objectif ; ils ne peuvent être isolés du monde d'activité sociale tel que nous le comprenons ; ils sont à la merci du langage particulier qui est devenu le moyen d'expression de leur société. Il est illusoire d'imaginer que l'on puisse s'adapter à la réalité sans l'usage d'un langage et que la langue est simplement un moyen secondaire pour résoudre les problèmes de communication ou de réflexion. En fait , le "monde réel" est, en grande partie, inconsciemment construit sur les habitudes linguistiques du groupe&. Nous voyons, nous entendons et vivons les expériences qui sont les nôtres parce que les habitudes linguistiques de notre communauté nous prédisposent à des choix d'interprétation."
Edward Sapir

But d'un programme

Un programmeur écrit un programme pour exprimer la solution d'un problème. Ce problème peut avoir pour origine un calcul à effectuer, mais il peut aussi s'agir d'un traitement numérique sur une image ou bien d'un programme bancaire de gestion de transactions. Ce qu'il faut comprendre c'est qu'un programme ne va pas nous chercher la solution de ce problème, il est la solution. Cette dernière nous est transmise dans la plupart des cas de manière graphique (dans une fenêtre dos, dans une fenêtre Windows avec des graphiques, etc.).
Suivant les langages utilisés pour la rédaction du code source, seul changera la manière d'écrire le programme. Si le langage choisi est le C, alors le programme sera une suite d'instructions structurées exécutées généralement les uns à la suite des autres jusqu'à la dernière instruction qui donne un résultat. Pour d'autres langages comme le Lisp c'est aux listes de donner la solution. Enfin, certains langages ont plus de facilités à résoudre des problèmes que d'autres ; le Fortran par exemple permet de résoudre facilement des problèmes de calcul numérique.
Les langages objet eux ont pour but de permettre de répondre facilement à n'importe quel type de problème.

Le tout objet

En objet il faut répondre à un problème avec les éléments de ce problème. Si l'on a un programme de gestion de personnes, nous devrons alors avoir des objets représentant ces personnes. Ces objets contiendront une case nom, une case prénom, une case date de naissance, etc. Tout ce qui définit une personne. Dans l'univers du problème nous devons conceptualiser un monde ou tout élément est un objet.
Les objets peuvent être regroupés en catégories appelées classes. Si notre problème concernait "la vie" nous pourrions alors créer la classe Animal et la classe Végétal. Il nous serait alors possible de gérer les classes Chien, Chat et Lapin en les faisant dériver de la classe Animal. De même nous pourrions créer les classes Buissons, Arbre et Légume de Végétal

le commencement de la conceptualisation de notre univers

Cette dérivation de classes vers des "sous-classes" ou "classes filles" peut se faire sans limites. Il est ainsi possible de créer les classes Caniche, Bas-Rouge et Labrador à partir de la classe Chien. Si cette façon de voir l'univers n'est somme toute pas très pertinente dans la vie réelle, l'important comme nous l'avons dit, c'est que ce soit le juste reflet de notre problème informatique.

les classes Caniche Labrador ou Bas-Rouge sont dérivées de chien

Notre modèle objet (ou arbre) est pourtant incomplet ; quelle que soit la ou les classes que nous y créons, il y aura toujours une classe mère dont toutes nos classes hériteront (à un degré différent) que l'on nomme classe Objet

l'univers de notre problème quasiment terminé

Une classe fille est une classe qui a repris certaines particularités de la classe dont elle est dérivée (qu'on nommera pour l'occasion classe mère) . Ce lien qui lie la fille à sa mère se nomme héritage. On a aussi pour habitude de dire qu'une classe fille étend sa classe mère.


A ce stade d'avancement, il faut regarder la pertinence de notre modèle avec le problème informatique que nous avons à résoudre. Si celui-ci porte sur la vie sur terre, notre modèle est assez bon (des améliorations sont possibles certes&). Mais si nous avions à traiter les herbivores et les carnivores nous aurions tout intérêt à changer notre arbre ainsi :

l'important est de ne pas essayer de rapprocher notre arbre le plus possible du monde réel, mais bien d'essayer d'avoir la représentation la plus efficace de notre problème

Les instances de classe

Une classe (avec un peu d'imagination) peut être vue comme un moule. A partir de la classe Caniche ils nous est possible de créer autant d'objets Caniches que nous le désirons et de les insérer dans l'univers de notre problème. Ceci s'applique pour toutes les classes que nous venons de créer.

A partir des classes de notre modèle nous créons autant d'acteurs objets que nous le désirons

Dans le modèle ci-dessus, Pepette est une instance de la classe Caniche. Le lien entre Chien et Animal , n'est évidemment pas le même que le lien entre Pepette et Chien. Toute classe peut ainsi avoir un ou plusieurs "représentants" qui possèdent toutes les caractéristiques de la classe dont ils sont issus.

Les membres d'instances

Nous pouvons certes créer un grand nombre d'objets mais ceux-ci n'ont pas grand intérêt. Mis à part leur type (soit caniche soit labrador, soit pommier etc.), nous ne savons pas grand chose sur eux et ils ne peuvent rien faire. Nous allons donc rajouter des caractéristiques à notre classe. Ces caractéristiques se nomment les membres de classes.


Un accesseur est une méthode qui renvoie la valeur d'une des variables d'un objet. Nous pourrions ajouter aux classes filles de Chien un accesseur GetAge() qui renverrait l'age d'un Animal permettant à un objet extérieur d'accéder à cette valeur. Les accesseurs prennent comme nom généralement celui de la variable auquel on associe le préfixe "Set" .Un mutateur est une méthode qui permet de changer la variable d'un objet. De nouveau pour l'âge nous pourrions créer la méthode SetAge() qui permettrait à un objet extérieur de modifier l'âge d'un Animal. Les mutateurs prennent comme nom généralement celui de la variable auquel on associe le préfixe "Set"


Pour rendre nos objets un peu plus utiles, nous pourrions améliorer très simplement notre modèle comme ceci (nous avons ici centré notre étude sur la partie "canine" de notre univers):

nos classes disposent maintenant de membres qui rendent nos objets plus intelligents

nombreDePattes, couleurPelage, taille, age ou nom sont les membres des classes Labrador, Caniche et Bas-rouge. Ces membres sont des variables qui nous permettent d'associer des valeurs à chacun de nos objets. Si nous voulons en plus faire en sorte que nos objets puissent faire des actions nous allons adjoindre aux classes des méthodes. Les méthodes ont pour but de renvoyer des valeurs ou bien de modifier l'environnement. Nous pourrions ainsi adjoindre à chaque classe héritant de la classe Chien une méthode Manger().
Nous pourrions de même créer des méthodes Vieillir(), se Déplacer() ou Dormir().

notre modèle commence maintenant à prendre forme

Les méthodes sont faciles à différencier des variables car elles sont terminées par des parenthèses ouvrantes et fermantes.



Si notre arbre devient de plus en plus complet, il souffre ici de graves défauts.

L'héritage

Notre modèle est ici mal conçu. Un trop grand nombre de redondances y sont perceptibles. En effet, si l'on reste dans la partie Animal de notre modèle, la classe Labrador, Caniche et Bas-Rouge dispose d'un grand nombre de membres en commun qu'ils soient variables ou méthodes. Ces membres sont aussi identiques à ceux des classes Lapin et Chat
Il serait donc plus intelligent de les faire hériter de la classe mère Animal .
Celle-ci contiendra tous les membres qui sont en commun à ses trois classes filles.
Lorsqu'une classe héritera d'Animal elle possédera donc tous ses membres automatiquement. Nous pourrons lui adjoindre des membres propres afin de la différencier.
Nous donnerons par exemple les membres Aboyer(), Grogner() ou MonterLaGarde() à Chien qui s'ajouterons aux membres hérités de la classe Animal.


Usage typographique :Pour le reste de nos cours nous respecterons l'usage typographique du langage Java : Tous les noms de classes commencent par une majuscule (Chien, Chat, Tulipe etc.). Les noms de variables commencent par une lettre minuscule et les noms de méthodes par une majuscule (Manger(), age &). Si ce nom est composé de plusieurs mots alors chacun d' eux, hormis le premier, commencera pas une majuscule (SetAge(). couleurPelage etc.)

l'héritage rend notre modèle particulièrement efficace

la classe Chat toujours dans ce souci de différenciation aura les méthodes DetecterChien() et SEnfuir().
Lorsque toutes nos classes seront faites sur le même principe, notre modèle sera alors enfin prêt à être lancé.
Nous aurons alors à créer dans le programme qui utilisera ce modèle plusieurs instances de la classe Chien, plusieurs objets de type Chat et d'autres de type Lapin. Nous mettrons dans l'univers des arbres, des buissons des fleurs et nous lancerons le programme.
Il ne reste qu'à regarder notre monde évoluer (objets Chien aboyant, objets Chat s'enfuyant, objets Lapin se nourrissant, etc.). Ce modèle est facilement améliorable pour de nouvelles versions (ajout de classe, améliorations des possibilités des objets, etc&).

Les membres statiques ou membres de classes

Contrairement aux membres d'instances d'une classe qui donnent des caractéristiques à leurs objets, les membres statiques appartiennent aux classes elles-mêmes. Etant stocké dans la classe, leur valeur s'applique à la classe et à l'ensemble de ses instances.
Avec les membres d'instance, chaque instance d'une classe reçoit une nouvelle copie des membres d'instance que la classe définie. Toutes les instances peuvent modifier ces membres dans affecter les autres. Avec les membres de classes il n'existe qu'un seul membre commun à tous les objets. Si la valeur de ce membre est modifiée, toutes les instances de la classe seront affectés par la modification.

Si nous créons une classe ElementFamille pour référencer les membres de notre famille nous pourrons créer des membres d'instances age, prenom, couleurCheveux qui seront propres à chaque objets de la classe ElementFamille. En revanche il est inutile pour un hypothétique membre nomDeFamille d'en faire une copie pour chaque objet car tous en auront la même valeur. Il serait plus intelligent d'en faire un membre statique auquel tous les objet auraient accès.

[ Suivant (C#) ]