Concepts de la Programmation Oriente Objet (POO

Prsentation De plus en plus dans le cadre de la programmation en Flash, on entend parler de POO, soit la Programmation Oriente Objet. Pour beaucoup de dbutants ou de non programmeurs, ce terme est assez abstrait. Ce tutoriel se propose de vous dcrire le pourquoi de la programmation objet, ainsi que ses bases et rgles qui lui sont propres. Ce tutoriel comporte uniquement les bases thoriques de la POO, et ne contient pas de code. Des mises en pratiques seront faites dans d'autres tutoriaux, afin de clarifier chaque aspect distinct de la POO.

1. Principe de la POO
Le but de la programmation Objet est de se rapprocher le plus possible d'une reprsentation de la ralit en programmation, en considrant que tout objet peut tre class dans une catgorie qui a ses caractristiques et ses possibilits propres. En effet, tout objet qui nous entoure peut tre "class" dans une categorie qui fait elle-mme partie d'autres catgories. Dans l'exemple prcdent, votre mobile fait partie de la catgorie "Tlphone portable", qui elle-mme fait partie de la catgorie "Tlphone", faisant partie de la catgorie "Outil de communication tlphonique", faisant partie de la catgorie "Outils de communication", etc.... Tandis qu'un fax est "Outil de communication tlphonique", mais pas un "Tlphone" et encore moins un "Tlphone portable".

2. Vocabulaire
Classe : On appellera "classe" ce qui est nomm plus haut comme tant une "catgorie". Une classe est en fait la description des possibilits offertes par un objet qui va appartenir cette catgorie. Dans l'exemple prcdent, on pourra considrer qu'il existe une classe "Mobile". Instance : On appellera "instance" tout objet cr partir d'une "classe". Par exemple, mon tlphone portable est une instance de la classe "Mobile". Un objet est toujours l'instance d'une classe. Attribut : On appellera "attribut" toute valeur qui s'attache dcrire l'objet. Par exemple, si mon tlphone est bleu, on peut considr que son attribut 'couleur' a pour valeur 'bleu'.

Mthode : On appellera "mthode" toute srie d'instructions qui permettent d'agir sur l'objet, ou de faire agir l'objet lui mme. Par exemple, on peut considrer que pour allumer mon tlphone, je fais appel la mthode 'allumerTelephone'. Proprit : D'un point de vue purement smantique, les proprits d'un objet sont l'ensemble de ses attributs et mthodes. Un abus de langage quasi-systmatique consiste appeler "proprits" uniquements les attributs de l'objet. Pour plus de simplicit, nous utiliserons cet abus de langage dans le reste du tutoriel. Interface : Une interface est un peu comme une classe, sauf que l'on ne peut pas crer d'objet partir d'une interface, et qu'elle ne contient pas de code " executer". Elle sera utilise comme base pour crer des classes. Elle s'attache dcrire quelles vont tre les actions qu'une classe va effectuer, et l'on devra crire le code qui va permettre d'effectuer ces actions dans la classe. Crer une classe partir d'un interface est aussi appel "implmenter une interface".

3. Notions de bases
L'encapsulation L'encapsulation correspond appliquer le principe de la "bote noire" aux objets que l'on cre. Cela consiste demander un objet d'effectuer une action, sans se proccuper de comment il l'effectue. Elle permet galement de faire des contrles de scurit, et de ne pas effectuer les actions demandes si une condition particulire n'est pas respecte. Par exemple, pour allumer notre tlphone portable, on se contente d'appuyer sur la touche [Power] : peu nous importe ensuite de savoir quelle est la procdure interne suivie par le tlphone pour s'allumer... on dsire juste savoir quand le tlphone est prt tre utilis. Pour une action effectuer, il va falloir dterminer quels vont tre les paramtres en entre, quels vont tre les paramtres en sortie, et quels vont tre les actions effectues sur l'objet lui-mme, pour ensuite les mettre disposition de l'utilisateur. Pour notre mthode 'allumerTelephone' : [*]les actions que l'objet effectue sur lui-mme sont

Le polymorphisme De manire gnrale, il existe trois types de polymorphisme :[list]'). Sur mon tlphone portable (dans la plupart des portables d'ailleurs), si je tape un numro de tlphone complet, et que j'appelle la mthode 'appelerDestinataire', il va composer le numro. Si par contre, je rentre '1#' puis que j'appuie sur 'appelerDestinataire', il va chercher le premier numro dans mon rpertoire, puis le composer. Donc, la raction de la mthode 'appeler' est diffrente (bien que similaire) selon le paramtre qui lui est donn.

Le polymorphisme de "surcharge" (ou "ad hoc" ou "overloading" en anglais) : cela consiste avoir la mme mthode avec la mme signature pour des objets de type analogue, voire compltement diffrents. Si mon tlphone est de marque 'X', il possde une mthode 'appelerDestinataire' et un micro pour parler. Un interphone d'immeuble possde aussi la mthode 'appelerDestinataire' et un micro. Je ne me proccupe donc pas du type d'objet dont je me sers, il me suffit d'utiliser la mthode 'appelerDestinataire' et d'utiliser le micro pour parler. Le polymorphisme "d'hritage" (ou "overriding" en anglais). Ce polymorphisme est issu (comme son nom l'indique ) de l'hritage. Cela consiste faire hriter plusieurs classes d'une mme classe 'mre', et de redfinir une mthode pour chaque classe. Par exemple, les tlphones de diffrentes marques n'ont pas la mme structure interne. Un tlphone de la marque 'X' va par exemple afficher un petit logo quand on utilise 'appelerDestinataire', tandis qu'un autre va allumer l'cran. Chaque contructeur a donc cr sa propre classe "MobileX" ou "MobileY" hrite de la classe "Mobile", puis rcris par dessus la mthode 'appelerDestinataire' pour y integrer ses propres spcificits. NB : La notion d'hritage est aborde plus loin dans ce tutoriel.

4. Les relations entre objets

L'hritage L'hritage est une relation entre objets de type "est un". Elle reprsente le fait, pour une classe, d'tre une sous-partie d'une autre classe. C'est le mme principe que notre exemple : le tlphone portable "est un" tlphone, et le tlphone "est un" outil de communication tlphonique. Une "sous-classe" (galement appele "classe fille") hrite des possibilits et des proprits de sa "super-classe" (galement appele "classe mre"). Il peut arriver que la "classe fille" puisse effectuer des actions supplmentaires ou comporter des proprits supplmentaires. Il peut galement arriver que pour effectuer une mme action que sa "classe mre", une "classe fille" ait besoin d'excuter des instructions supplmentaires. On va alors redfinir une mthode de cette classe qui va executer ses instructions propres, plsu ventuellement les instructions de la "classe mre". Par exemple, la classe "Mobile" hrite de la classe "Telephone", et rcupre donc les porprits 'touche0', 'touche1', 'touche2', etc... mais possde galement en plus une touche 'on/off'. Dans d'autres langages, il existe la possibilit de faire de l'hritage multiple, mais pas dans Flash (du moins jusqu' la version MX). Cela consiste tout simplement hriter de plusieurs classes : une orange "est un" fruit, mais une orange "est une" sphre aussi. Elle a donc les proprits d'un fruit (couleur, prix au kilo ...) et celles d'un sphre (rayon). L'hritage multiple suscite un dbat important dans la communaut des dveloppeurs. Un language comme C++ permet de crer des classes partir de plusieurs classes (comme dcrit ci-dessus), mais les classes de nouveaux langages comme JAVA ou C# permettent uniquement de faire de

l'hritage multiple partir de plusieurs interfaces, mais ne peuvent hriter que d'une seule classe, cela vitant des conflits de "code" entre deux mthodes ayant le mme nom.

La dlgation La dlgation est une relation de type "a un" entre deux objets. Elle intervient lorsque deux objets collaborent entre eux. Ce type de relation se dcompose en trois parties : L'association : elle consiste une simple relation de collaboration entre deux objets. Chaque objet existe de manire totalement indpendante, et n'a pas forcment besoin de l'autre pour "vivre". La relation entre un tlphone portable et son kit main-libre est une relation d'association. L'agrgation : elle se distingue de l'association par le fait qu'un objet est une partie de l'autre. Ainsi, un bouton sur un tlphone portable a une relation d'agrgation avec le tlphone. Si une certaine touche n'est pas prsente, le tlphone peut nanmoins fonctionner, en paliant ce manque par des combinaisons d'autres touches. La composition : elle est une sous-partie de la relation d'agrgation. Elle reprsente une relation troite entre les deux objets : l'objet "pre" ne peut fonctionner sans l'objet "fils". L'objet "batterie" ou "micro" d'un tlphone portable ont une relation de composition avec le tlphone, car le tlphone ne peut pas fonctionner sans. NB : Dans le doute du type de relation utiliser, il vaut mieux utiliser l'association

5. Petite mise en pratique

Nous allons ici essayer de mettre en pratique ces quelques notions par un exemple simple, qui diffre de notre tlphone portable qui n'a plus beaucoup de batteries tellement nous l'avons utilis. Nous utiliserons un "pseudo-langage" priori possible comprendre par le plus grand nombre dont voici les quelques conventions : le terme "classe" signifie que l'on cre une classe. 'classe MaClasse { ... }' signifie "je cre une classe nomme MaClasse dont les instructions sont entre les accolades". Pour dire qu'un objet est d'une certaine classe, nous noterons 'monObjet : MaClasse', ce qui voudra dire "monObjet est une instance de MaClasse" Les mthodes sont declares sous la forme 'monObjet.maMethode( parametre1, parametre2)', ce qui veut dire "je cre la mthode maMethode de l'objet monObjet qui va prendre les paramtres parametre1 et parametre2". Des parenthses vides signifient que la mthode ne prend aucun paramtre. L'affectation d'une valeur une proprit se fait sous la forme 'maPropriete = maValeur'. Cela se traduit par "Je donne maPropriete la valeur maValeur".

L'appel une mthode se fait sous la forme 'monObjet.maMethode(param1, param2)', ce qui se traduit par "J'appelle la mthode maMethode de monObjet avec les paramtres param1 et param2". Les lignes commencant par '//' sont des lignes de commentaires, et n'interviennent pas dans l'excution du code. Le but est de crer un ensemble de classes destines dcrire une voiture de marque 'MediaBox'. Tout d'abord, commenons par crer une classe 'Vehicule'. Nous allons considrer qu'un vhicule comporte un moteur et des roues toutes identiques. Dans la classe vhicule, nous allons crer une proprit 'modeleDeRoue', qui constituera le modle des roues du vhicule. En effet, considrant que toutes les roues sont identiques, il ne sert rien de crer plusieurs roues qui seront exactement les mmes ... Vous me direz : "Pourquoi pas un volant ?". Tout simplement parce que le volant est quelque chose de spcifique aux voitures, camions etc... Alors qu'une moto est un vhicule, mais n'a pas de volant. Nous pourrions considrer qu'un bateau est un vhicule, mais par soucis de simplification, nous allons ne pas en tenir compte ... En fait, la question se poser lors de la cration d'une classe est : "Toutes les instances de cette classe ont-elles cette proprit ?", ou "Toutes les instances de cette classe peuvent-elles effectuer cette action ?". Voici donc une classe 'Vehicule' :

ActionScript classe Vehicule { // Proprietes moteurDuVehicule : Moteur modeleDeRoue : Roue // Methodes allumerMoteur ( clef ) eteindreMoteur ( ) }

Nous allons ensuite crer une classe 'Voiture', qui "est un" vhicule. Elle va donc hriter de la classe 'Vehicule'. En plus des possibilits d'un vhicule, la voiture possde un volant et un nombre de roues dfini. Nous allons donc rajouter ce volant la classe Voiture . Ce volant offrant la possibilit de tourner, nous allons donc crer une mthode 'tourner' qui va prendre en paramtre la direction dans laquelle on veut tourner. ActionScript classe Voiture herite de Vehicule { // Proprietes volant : Volant nombreDeRoues : Nombre //Initialisation des proprietes

nombreDeRoues = 4 // Methodes tourner( direction ) }

Vous remarquerez srement que l'on ne dclare pas de roue ni de moteur cette voiture. Elle n'en a pas besoin, car hritant de la classe 'Vehicule', elle hrite automatiquement des ses proprits et mthodes. Donc, sur une instance de la classe 'Voiture', nous allons pouvoir appeler les mthodes 'allumerMoteur' et 'eteindreMoteur'...

Voila enfin le moment de crer notre classe proprement dite : la Voiture MediaBox !!! 8) L'quipe de MediaBox n'tant pas avare de ses efforts, elle vous offre en exclusivit la possibilit de voler !!! (qui a dit Taxi 2 ?!? ....... J'ai les noms, je vous prviens !!!:twisted:). Il va donc falloir lui rajouter des ailes, et lui permettre de plier/dplier les ailes, et de dcoller (pour l'atterrissage, vous vous dbrouillerez) : ActionScript classe VoitureMediaBox herite de Voiture { // Proprietes ailesDeLaVoiture : Aile // Methodes deplierLesAiles () plierLesAiles () decoller () }

Vous noterez ici un des avantages normes de la POO, c'est que la mthode 'plierLesAiles' peut vrifier si l'on est en vol ou pas avant de les replier effectivement. Si c'est le cas, elle ne repliera pas les ailes et pourra retourner une notification sur le fait qu'elle ne l'ait pas fait, voire donner la raison pour laquelle elle ne l'a pas fait. A l'utilisation d'une VoitureMediaBox, vous ne vous poserez pas ce genre de question, tant donn que l'objet le gre tout seul ! De la mme manire que pour la classe 'Voiture', nous n'avons pas nous soucier des mthodes et proprits qui ne font pas partie des spcificits de notre 'VoitureMediaBox'.

Voici maintenant le moment d'acheter une voiture MediaBox. Pour cela, nous allons crer une instance de la classe'VoitureMediaBox', puis l'utiliser pour faire un petit tour du monde :

ActionScript // Mon objet 'maVoitureMB' devient une instance de 'VoitureMediaBox' maVoitureMB : VoitureMediaBox // Je demarre ma voiture, je dplie les ailes et je la fais dcoller maVoitureMB.demarrerMoteur( "123456")

maVoitureMB.deplierLesAiles() maVoitureMB.decoller()

Conclusion .6
Vous aurez certainement compris pourquoi la programmation Oriente Objet est utilise maintenant par la quasi-totalit des langages actuels. Elle offre une souplesse et surtout une possibilit de rutilisation trs importante. Elle permet de n'crire qu'une seule fois le mme code, et de rutiliser facilement son propre code ou un code provenant d'un autre programmeur. C'est donc un choix vident pour les quipes de dveloppement qui travaillent ensemble. De par sa forte relation avec la reprsentation de la ralit, la POO est aussi plus .naturelle l'utilisation Il ne reste donc plus qu' lui trouver des inconvnients, mais je n'en vois qu'un : les codes en POO sont plus lents, car les instructions unitaires sont appeles aprs un passage par de .multiples couches, qui prennent videmment plus de temps qu'un appel direct l'instruction Lors du travail en quipe sur une mme application, il faut faire une confiance aveugle la personne qui a dvelopp les classes que vous utilisez !!! En effet, si une erreur s'est glisse dans l'une de ces classes, elle peut arriver un dysfonctionnement complet de l'application. En Flash, les accs la mmoire de l'ordinateur tant correctement protgs, les gnes ... provoques sont relativement minimes Un autre "inconvnient" qui n'en est pas un, est que dvelopper en POO ncessite une phase d'analyse bien plus importante, car si elle est bcle, elle peut ncessiter une rcriture de tout votre code en plein milieu du dveloppement, ou pnaliser les dveloppeurs .qui vont utiliser vos classes