La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

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

Présentations similaires


Présentation au sujet: "Analyse et Conception orientée objet 03 – Concepts de base de la pensée orientée-objet 1."— Transcription de la présentation:

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

2 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 2

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

4 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. 4

5 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 5

6 Les données propres de lobjet Son interface (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 : 6

7 Les méthodes, ou fonctions membres, appartiennent bien à lobjet, au même titre que ses variables (comme les champs dune 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 dabstraction, qui vise à ne garder de l élément que les données pertinentes pour le domaine concerné. 7

8 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(); } 8

9 Topologie des applications « classiques ». 9

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

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

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

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

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

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

16 Topologie des applications en P.O.O. objet1 utilise operation1(), sans se soucier de tous les détails dimplémentation qui précèdent -> il est client dun service défini par une interface objet2 est décomposé selon le même modèle. Quelle que soit léchelle dobservation, 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 lutilisation de lencapsulation garantit que objet1 continue à fonctionner, même si le code de operation1, ou la représentation des variables utilisées dans objet2, changent… objet1objet2 operation1( ) 16

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

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

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

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

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

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

23 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 23

24 Un concept important : le principe de substitution de Liskov Le lien dhéritage traduit le type de lien bien connus IS_A, utilisés dans dautres contextes. Ceci veut dire quon pourra utiliser, dans notre application, une forme dun ou lautre type indifféremment, en se basant sur linterface 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 labstraction Forme. Les détails dimplémentation seront donc bien isolés. 24

25 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 dune 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... 25

26 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 26

27 On peut alors écrire, quelque part dans le code de notre application : for(int i =0; i affiche();} La classe Formes définit une fonction affiche et les sous-classes limplémentent correctement, chacune à leur façon. Si on change la nature d un élément du vecteur en cours dexécution, la boucle reste valide. Cest 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 LaClasseFonct

28 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(); } Le même principe est applicable en Java, en voici l illustration : 28

29 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"); try { 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 (IOException exc) { } catch (ClassNotFoundException exc) { } System.out.println("On redessine le dessin"); for(int i=0; i<6; i++) { leDessin[i].dessine(); } } 29

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

31 Epilogue : Programmation Orientée Objets et architecture dapplications 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… 31

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


Télécharger ppt "Analyse et Conception orientée objet 03 – Concepts de base de la pensée orientée-objet 1."

Présentations similaires


Annonces Google