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

Analyse et Conception orientée objet

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

1

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

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

forme : Rectangle : Application

: ConsoleTexte

setValeurs( )

affiche( )

affiche( )

3

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

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

Rectangle

coinlargeurlongueur

setValeurs()affiche()

Les données propres de l’objet

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

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

7

Nous pourrions ainsi déjà écrire le code qui demande l'affichage des formes de notre dessin, dans l'application.

Il ressemblerait à ceci :

// Affichagefor(int i =0; i< 3; i++){

forme[i].affiche();}

8

Topologie des applications « classiques ».

Programmeprincipal

Sous-progr1

Sous-progr5Sous-progr4

Sous-progr2

Sous-progr3

Données1

Données2

Données3

9

Topologie des applications en P.O.O.

objet1

objet3

objet2operation1( )

operatio

n2( )

10

Topologie des applications en P.O.O.

objet1

objet3

operation1( )

operatio

n2( )

objet2operation1

11

Topologie des applications en P.O.O.

operatio

n2( )

Code deoperation1

Ce qui se passe dans objet2…

operation1 utilise une opération d’un objet « partie » de objet2 (une variable membre), par exemple point,

point

setCouleur( )

objet2

12

Topologie des applications en P.O.O.

operatio

n2( )

Code deoperation1

Ce qui se passe dans objet2…

operation1 utilise une opération d’un objet « partie » de objet2 (une variable membre), par exemple point,

point

setCouleur( )

code de setCouleur

objet2

13

Topologie des applications en P.O.O.

operatio

n2( )

Code deoperation1

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, …

point

couleur

setCouleur( )

code de setCouleur

objet2setValeur( )

14

Topologie des applications en P.O.O.

operatio

n2( )

Code deoperation1

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, …

point

couleur

setCouleur( )

code de setCouleur

objet2setValeur( )

code de setValeur

15

Topologie des applications en P.O.O.

• 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…

objet1 objet2operation1( )

16

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) { }

};

Rectangle

coinlargeurlongueur

setValeurs()affiche()

17

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 ?

forme : Rectangle

forme : Triangle

: ConsoleTexte

: Application

setValeurs( )affiche( )

setValeurs( )affiche( )

affiche( )

affiche( )

18

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

Forme

pointAncrage : Pointcouleurtrait

affiche()setValeurs()setCouleur()setTrait()efface()

Rectangle

largeurlongueur

setValeurs()affiche()

Triangle

autresPoints

setValeurs()affiche()

19

forme : Forme : Application

: ConsoleTexte

affiche( )

setValeurs( )affiche( )

Le diagramme de fonctionnement redevient plus « simple » :

L ’application voit des formes, indépendamment de

leur spécificités.

20

Première difficulté : construire une classe ou une hiérarchie de classes

GrosseClasse

var1var2var3var4var5var6var7var8var9

op1()op2()op3()op4()op5()op6()op7()op8()op9()op10()opname()

NewClass

NewClass2

NewClass3

NewClass4

NewClass5

NewClass6

NewClass7

NewClass8

Trop générale Trop spécialisée

21

Première difficulté : construire une classe ou une hiérarchie de classes

Une partie des classes de Borland C++ Object Window Library

22

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

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.

24

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

25

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

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

27

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

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

Le résultat donne :

On dessine le dessinJe dessine un rectangleJe dessine un cercleJe dessine un triangleJe dessine un rectangleJe dessine un cercleJe dessine un triangleOn sauve le dessinOn relit le dessinOn redessine le dessinJe dessine un rectangleJe dessine un cercleJe dessine un triangleJe dessine un rectangleJe dessine un cercleJe dessine un triangle

30

Epilogue : Programmation Orientée Objets et architecture d’applications

Programmeprincipal

Sous-progr1

Sous-progr5Sous-progr4

Sous-progr2

Sous-progr3

Données1

Données2

Données3

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

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.

Architecture basée sur les objets

objet1

objet3

objet2

operation1( )

operatio

n2( )

32