Analyse et Conception orientée objet 03 – Concepts de base de la pensée orientée-objet

Approche intuitive, par un exemple simple Les mots clés et concepts de bases sont : manipulation d'objets, envoi de messages, encapsulation, abstraction, classes, héritage, polymorphisme Approche intuitive, par un exemple simple

Outil graphique élémentaire En synthèse, le fonctionnement est le suivant ...

OBSERVATION Ce que nous définissons à travers ce modèle simple de fonctionnement, ce sont les interfaces de la forme et de la console, telles qu'elles sont nécessaires pour que l'application puisse fonctionner comme l'attend l'utilisateur. L'interface est donc, dans notre cas, un ensemble de fonctions que ces objets devront être capables d'exécuter. Le modèle se limite donc pour l'instant à définir ces interactions.

ENCAPSULATION, ABSTRACTION Qu'est-ce qu'un objet ? Comment modéliser les caractéristiques d'une forme afin qu'elle puisse rendre les "services" attendus ? Grâce à notre modèle, nous avons défini les comportements attendus; Ensuite nous en déduiront les caractéristiques importantes. Celles-ci matérialiseront l’état de la forme et permettront aux fonctions de réaliser leur travail. Celles-ci seront implémentées plus tard... ENCAPSULATION, ABSTRACTION

(les services disponibles) Un objet est donc une espèce de structure, avec des fonctions « attachées » en plus. On peut représenter les caractéristiques de ce « type » d ’objet comme suit : Les données propres de l’objet Son interface (les services disponibles)

Les méthodes, ou fonctions membres, appartiennent bien à l’objet, au même titre que ses variables (comme les champs d’une structure). Elles seront invoquées, par exemple comme suit : forme. affiche(); // en C++ ou en Java Les variables membres seront déterminées en fonction du problème, donc des services à rendre. On procèdera donc à un travail d’abstraction, qui vise à ne garder de l ’élément que les données pertinentes pour le domaine concerné.

Il ressemblerait à ceci : Nous pourrions ainsi déjà écrire le code qui demande l'affichage des formes de notre dessin, dans l'application. Il ressemblerait à ceci : // Affichage for(int i =0; i< 3; i++) { forme[i].affiche(); }

Topologie des applications « classiques ».

Topologie des applications en P.O.O. objet1 operation1( ) objet2 operation2( ) objet3

Topologie des applications en P.O.O. objet1 operation1( ) objet2 operation1 operation2( ) objet3

Topologie des applications en P.O.O. Ce qui se passe dans objet2… operation1 utilise une opération d’un objet « partie » de objet2 (une variable membre), par exemple point, Code de operation1 point setCouleur( ) objet2 operation2( )

Topologie des applications en P.O.O. Ce qui se passe dans objet2… operation1 utilise une opération d’un objet « partie » de objet2 (une variable membre), par exemple point, Code de operation1 point setCouleur( ) code de setCouleur objet2 operation2( )

Topologie des applications en P.O.O. Ce qui se passe dans objet2… operation1 utilise une opération d’un objet « partie » de objet2 (une variable membre), par exemple point, qui elle-même utilise une opération d’une autre variable membre couleur, … Code de operation1 point setCouleur( ) code de setCouleur objet2 setValeur( ) operation2( ) couleur

Topologie des applications en P.O.O. Ce qui se passe dans objet2… operation1 utilise une opération d’un objet « partie » de objet2 (une variable membre), par exemple point, qui elle-même utilise une opération d’une autre variable membre couleur, … Code de operation1 point setCouleur( ) code de setCouleur objet2 setValeur( ) operation2( ) couleur code de setValeur

Topologie des applications en P.O.O. objet1 operation1( ) objet2 objet1 utilise operation1(), sans se soucier de tous les détails d’implémentation qui précèdent -> il est client d’un service défini par une interface objet2 est décomposé selon le même modèle. Quelle que soit l’échelle d’observation, des objets communiquent par messages sans se soucier de la façon dont les fonctions correspondantes sont mises en œuvre. Ce modèle, et en particulier l’utilisation de l’encapsulation garantit que objet1 continue à fonctionner, même si le code de operation1, ou la représentation des variables utilisées dans objet2, changent…

La description générique des objets : l'extension de la notion de type class Rectangle { private : Point coin; int longueur, largeur; Console console; public: void setValeurs(Point, int, int); void affiche(void); Rectangle(void) { } virtual ~Rectangle(void) { } }; UNE CLASSE !

Et si on ajoute encore une nouvelle « forme » ? La généralisation via les classes : Comment faire si nous souhaitons manipuler des triangles dans notre application, en plus de nos rectangles ? 1ère approche : Et si on ajoute encore une nouvelle « forme » ?

2ème approche : on crée une classe qui définit les caractéristiques d’une forme « en général ». On la spécialise ensuite, grâce à d’autres classes, qui bénéficieront du travail déjà fait. Dérivation de classe, héritage, généralisation/spécialisation...

L ’application voit des formes, Le diagramme de fonctionnement redevient plus « simple » : L ’application voit des formes, indépendamment de leur spécificités.

Première difficulté : construire une classe ou une hiérarchie de classes Trop générale Trop spécialisée

Première difficulté : construire une classe ou une hiérarchie de classes Une partie des classes de Borland C++ Object Window Library

Importance de la définition des interfaces Première difficulté : construire une classe ou une hiérarchie de classes : quelques qualités à surveiller Grady Booch, ainsi que de nombreux auteurs, relèvent cinq qualités essentielles : Couplage faible, de manière à obtenir des classes qui ne dépendent que de leur hiérarchie pour être mise en œuvre. Cohésion forte, où une classe ne contient que des choses ayant un lien entre elles (formant ainsi une abstraction cohérente). Complétude, donnant des classes couvrant tous les aspects à modéliser. Suffisance de caractéristiques et primitivité, telles que toutes les valeurs/opérations strictement nécessaires sont disponibles. Les notions de suffisance et de primitivité vont de pair. Importance de la définition des interfaces

Un concept important : le principe de substitution de Liskov Le lien d’héritage traduit le type de lien bien connus IS_A, utilisés dans d’autres contextes. Ceci veut dire qu’on pourra utiliser, dans notre application, une forme d’un ou l’autre type indifféremment, en se basant sur l’interface définie pour la super-classe (Forme). Cette approche se réfère au principe de substitution de Liskov (voir [MARTIN]). =>Dans notre exemple: Les objets clients de ces ‘pièces’ seront délivrés des détails et ne seront concernés que par l’abstraction “ Forme ”. Les détails d’implémentation seront donc bien isolés.

Exemple : lImprimante.init(); leScanner.init(); Cela veut-il dire que, généralement, des méthodes définies dans des classes différentes peuvent porter le même nom (de façon à utiliser le "vocabulaire" le plus adéquat) ? Cette possibilité existe et constitue une des bases de la puissance de la programmation orientée objets. Elle porte le nom de polymorphisme. Exemple : lImprimante.init(); leScanner.init(); Elle est étroitement associée au principe de substitution de Liskov. Associé à ce principe, l ’utilisation de classes abstraites permet une conception d’une grande souplesse et introduit la notion de réutilisation. Le polymorphisme jouera sur la technique de « late binding » pour offrir une souplesse remarquable de la programmation...

Comment la bonne méthode est-elle choisie au moment de l'exécution ? Reprenons l ’exemple de notre vecteur de « Formes » : Formes lesFormes[4];  Au moment de l ’exécution, on y instancie des classes Rectangle, Cercle, …dérivées de Formes. Ces classes sont schématisées comme suit : Formes affiche( ) Cercle Rectangle Triangle

On peut alors écrire, quelque part dans le code de notre application : for(int i =0; i < 4; i++) {forme[i]->affiche();} La classe Formes définit une fonction affiche et les sous-classes l’implémentent correctement, chacune à leur façon. Si on change la nature d ’un élément du vecteur en cours d’exécution, la boucle reste valide. C’est le miracle du principe de substitution et du late binding… En C++, la vTable joue le rôle important dans la résolution « tardive » des références LaClasse Fonct1 1011000110011111010110

Le même principe est applicable en Java, en voici l ’illustration : import java.io.*; class Formes implements Serializable { void dessine() {} // super classe = abstraite ??? } class Rectangle extends Formes { void dessine() { System.out.println("Je dessine un rectangle"); } class Cercle extends Formes { void dessine() { System.out.println("Je dessine un cercle"); } class Triangle extends Formes { void dessine() {System.out.println("Je dessine un triangle"); } public class Liskov { // polymorphisme, principe de Liskov etc public Liskov () { } public static void main(String args[]) { Formes[] leDessin = new Formes[6]; for(int i=0; i<6; i+=3) { leDessin[i] = new Rectangle(); leDessin[i+1] = new Cercle(); leDessin[i+2] = new Triangle();

System.out.println("On dessine le dessin"); for(int i=0; i<6; i++) { leDessin[i].dessine(); } System.out.println("On sauve le dessin"); try { FileOutputStream fos = new FileOutputStream("d:\\dessin.dat"); ObjectOutputStream oos = new ObjectOutputStream(fos); for(int i=0; i<6; i++) oos.writeObject(leDessin[i]); oos.flush(); } catch (IOException exc) { } leDessin = new Formes[6]; // on réinitialise le dessin System.out.println("On relit le dessin"); FileInputStream fis = new FileInputStream("d:\\dessin.dat"); ObjectInputStream iis = new ObjectInputStream(fis); for(int i=0; i<6; i++) { leDessin[i] = (Formes) iis.readObject(); } catch (ClassNotFoundException exc) { } System.out.println("On redessine le dessin"); for(int i=0; i<6; i++) { leDessin[i].dessine(); }

Je dessine un rectangle Je dessine un cercle Je dessine un triangle Le résultat donne : On dessine le dessin Je dessine un rectangle Je dessine un cercle Je dessine un triangle On sauve le dessin On relit le dessin On redessine le dessin

Approche algorithmique classique Epilogue : Programmation Orientée Objets et architecture d’applications Approche algorithmique classique Inconvénient : si on change la représentation des données, on doit changer les différents sous-programmes qui y accèdent et, éventuellement, les programmes qui appellent ces sous-programmes etc…

Architecture basée sur les objets Dans une application conçue correctement sur le paradigme “ objets ”, on considère un ensemble d’objets qui interragissent, tantôt comme client tantôt comme serveurs d’un certain nombres de fonctionnalités (on sait maintenant que l’on peut dire méthodes ou fonctions). Les fonctionnalités d’un objet “ serveur ” sont exposées dans son interface. L’objet “ client ” ne dépend que de cette dernière. L’interface du serveur ne dépend pas de son implémentation. Au contraire, c’est l’objet “ serveur ” qui dépend de son interface. Il n’y a donc aucune dépendance transitive entre client et implémentation du serveur ! Mise en évidence par Robert C. Martin, la notion d’inversion de dépendance qualifie ces propriétés. objet1 objet2 operation1( ) operation2( ) objet3