Analyse et Conception orientée objet
description
Transcript of Analyse et Conception orientée objet
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
Rectanglecoinlargeurlongueur
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
objet2 setValeur( )
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
objet2 setValeur( )
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) { }
};
Rectanglecoinlargeurlongueur
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.
FormepointAncrage : Pointcouleurtrait
affiche()setValeurs()setCouleur()setTrait()efface()
Rectanglelargeurlongueur
setValeurs()affiche()
TriangleautresPoints
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
objet2operation1( )
operatio
n2( )
32