Conception Oriente Objet - PowerPoint PPT Presentation

Loading...

PPT – Conception Oriente Objet PowerPoint presentation | free to view - id: 2a87b0-ZDc1Z



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Conception Oriente Objet

Description:

Le concept de type abstrait est introduit pour la sp cification de syst mes. ... Le type abstrait est un mod le formel des objets qu'il d crit, et ... – PowerPoint PPT presentation

Number of Views:26
Avg rating:3.0/5.0
Slides: 87
Provided by: laurenth6
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Conception Oriente Objet


1
Conception Orientée Objet
  • Laurent Henocque
  • http//laurent.henocque.free.fr/
  • Enseignant Chercheur ESIL/INFO France
  • http//laurent.henocque.perso.esil.univmed.fr/
  • mis à jour en Octobre 2006

2
Licence Creative Commons
  • Cette création est mise à disposition selon le
    Contrat Paternité-Partage des Conditions
    Initiales à l'Identique 2.0 France disponible en
    ligne
  • http//creativecommons.org/licenses/by-sa/2.0/fr/
  • ou par courrier postal à Creative Commons, 559
    Nathan Abbott Way, Stanford, California 94305,
    USA.

3
Objectifs
  • Donner une compréhension des enjeux de la
    conception orientée objet, et des connaissances
    actuelles sur le sujet

4
Plan
  • Panorama du concept d'objet en Informatique
  • Principes généraux de détermination des classes
  • Principes de l'utilisation des objets
  • A propos de réutilisabilité
  • Conception des interfaces de programmation en C
  • Types de classes

5
Panorama du concept d'objet
6
Un modèle de la réalité
  • les mêmes réactions que la réalité représentée,
  • la même modularité que le monde réel.

7
Modèle de la réalité (2)
  • Chaque objet se comporte "comme" son homologue
    réel en termes de
  • persistance de son état
  • réactions aux perturbations externes
  • communication avec les autres objets

8
Persistance
  • La persistance dun l'état est obtenue de façon
    élémentaire par stockage de données pertinentes
    dans une structure (les types struct en C et
    record en Pascal).
  • La structure est donc l'élément fondamental dans
    la représentation informatique de l'objet un
    espace clos et contigu où figurent toutes les
    informations relatives à un objet.

9
Encapsulation des données
  • La démarche consistant à décrire un tel espace
    est nommée encapsulation des données.
  • Une structure est également décrite comme un
    agrégat de données hétérogènes.
  • Le type tableau au contraire constitue un agrégat
    de données dun même type (homogène).

10
Réactions
  • La réaction aux perturbations externes est
    simulée par des fonctions que l'on peut appliquer
    à l'objet.
  • L'existence chez différents objets de
    fonctionnalités sémantiquement voisines, et pour
    autant différentes dans leur réalisation, conduit
    à rejeter un modèle informatique de premier
    niveau dans lequel les fonctions sont distinguées
    par leur seul nom et sont globales comme c'est le
    cas dans les langages traditionnels non orientés
    objets

11
Difficultés
  • Le nommage des fonctions globales nécessite de
    donner des noms différents à des fonctions
    homologues, et donc à multiplier dans un
    programme le nombre des symboles.
  • Les fonctions globales ne permettent pas avec une
    grande finesse le contrôle d'éventuelles
    restrictions au graphe d'appel du programme.

12
Polymorphisme
  • On accepte de donner le même nom à des fonctions
    dont les arguments diffèrent.
  • Ainsi, un programmeur peut utiliser un nom unique
    pour l'associer à un concept d'opération unique,
    utilisable dans différents contextes

13
Avantages du polymorphisme
  • Les programmes gagnent en abstraction, car des
    concepts non pertinents en sont retirés,
  • Il n'est pas nécessaire de définir une règle de
    nommage des fonctions homologues (par exemple
    "bouge_caillou", ou bien "CaillouBouge").
  • L'écriture des programmes est facilitée.

14
Encapsulation de fonctions
  • Dans ce modèle, sont associées logiquement à la
    structure (de données) représentant un objet les
    seules fonctions qui simulent (ou implantent) des
    réactions de cet objet au monde extérieur.
  • Ces fonctions sont alors appelées des méthodes.
  • La déclaration d'une méthode omet la mention du
    paramètre désignant l'objet auquel elle
    s'applique, appelé Objet Support

15
Opérations et Méthodes
  • Par définition, toutes les méthodes de même nom
    constituent des implantations appropriées du même
    concept, qui porte le nom d' opération.
  • Chaque méthode d'une classe implante une
    opération donnée pour cette classe

16
Polymorphisme et méthodes
  • Aucun langage de programmation ne permet de
    distinguer deux fonctions par le seul type de
    leur valeur de retour.

17
Objets
  • Une structure qui encapsule à la fois des données
    et des méthodes est appelée un objet.
  • A ce titre, certaines bases de données dites
    "objet" n'en méritent pas le nom puisqu'elles ne
    sont qu'orientées "structure".
  • Notons que le terme d'objet est défini sans qu'il
    ne soit question d'héritage.

18
Communication
  • L'envoi d'un message d'un objet à un autre
    suppose qu'une méthode du premier appelle une
    méthode du deuxième.
  • Dans le cas "synchrone", la réponse est fournie
    par la valeur de retour de la fonction appelée
  • Dans le cas asynchrone, le réponse est fournie
    par un message en retour.

19
Messages / Méthodes
  • L'encapsulation permet de contrôler les
    possibilités de communications inter objets,
  • L'appel réciproque et récursif de méthodes entre
    deux (ou plus) objets dans le cas asynchrone peut
    conduire à des situations de bouclage

20
La classe (1)
  • La partie "structure" de l'objet, contenant ses
    données, doit être dupliquée pour chaque objet de
    même type.
  • Par contre, les méthodes de ces objets ne
    nécessitent pas d'être décrites plusieurs fois.

21
La Classe (2)
  • On distingue donc entre la réalisation
    particulière d'un objet, une instance, et
    l'ensemble des informations nécessaires pour
    construire et "animer" ces instances leur
    classe.
  • Le modèle utilisé pour générer pour chaque objet
    une structure physique de données est appelé le
    prototype.
  • On peut donc parler de classe sans qu'il ne
    soit question d'héritage.

22
Le type abstrait un point de vue formel sur la
classe
  • Le concept de type abstrait est introduit pour la
    spécification de systèmes.
  • Un type abstrait consiste en une description
    formelle (i.e. logique) des états accessibles aux
    objets de ce type, et des transitions qui
    peuvent survenir entre états.
  • Toutes les propriétés des instances dun type
    abstrait sont démontrables comme on démontre un
    théorème.
  • Une telle description spécifie donc sans
    ambiguïté la sémantique dun ensemble dobjets,
    indépendamment des perspectives de sa réalisation
    informatique.

23
des Types abstraits aux langages
  • Le type abstrait est un modèle formel des objets
    qu'il décrit, et peut être appelé une classe.
  • Cette classe comporte assez d'informations pour
    générer un prototype. Les transitions
    correspondent à des fonctions membres qui
    modifient les instances.
  • Mais elle ne possède pas de réalisation physique
    en soi. Elle n'est qu'un cadre général de
    réalisation.
  • C'est l'approche des langages comme C et Simula

24
Nécessité de réaliser le type abstrait
  • Une classe décrit essentiellement un prototype
    des objets de cette classe, et les méthodes
    applicables aux objets de cette classe.
  • Pour des raisons techniques l'implantation des
    langages orientés objet nécessite que certaines
    classes engendrent une structure de données
    permettant de stocker des pointeurs vers des
    méthodes de la classe. Ces méthodes sont alors
    appelées virtuelles.

25
Table de virtuelles
  • La table de virtuelles "concrétise" la classe

26
C/Java
  • C demande de déclarer les fonctions virtuelles
  • Toutes les méthodes sont virtuelles en Java.

27
Variations autour des classes
  • une classe est elle même un objet, instance d'une
    métaclasse, et ce à l'infini
  • tout objet peut servir de prototype à la
    construction d'un autre objet
  • tous les types de données sont des objets (en
    Smalltalk, même un caractère est un objet, qui
    communique par envoi de messages avec ses
    voisins)
  • l'objet classe peut contenir des informations
    partagées par toutes les instances de la classe
    (cela existe en Java, et partiellement en C)

28
Objets et Classification
  • Dans la pensée occidentale un modèle du monde par
    lequel les propriétés des objets découlent
    logiquement de la place qu'ils occupent dans une
    classification dont l'adéquation est mesurée au
    faible nombre d'exceptions qu'elle engendre.
  • Ce modèle s'intéresse avant tout aux propriétés
    des objets (appelées propositions en logique)
    plus qu'à leurs éventuelles relations.
  • Par exemple si on sait qu'un "objet" est un
    mammifère, on sait alors qu'il allaite ses petits
    et qu'il ne vole pas (en général). Une
    classification des concepts nous indique
    également que tous les mammifères, et tous les
    oiseaux, sont des animaux.

29
Vision logique de la classe
  • Les règles "A" sont descriptives de la classe
  • Les règles "B" sont des règles d'héritage

30
Exemple de hiérarchie
31
Principes d'utilisation de l'héritage
32
B hérite de, ou possède un A
33
Une difficulté
  • Lorsque B hérite de A, la structure de données
    décrite par A sera présente d'office dans toute
    structure de type B.
  • La relation d'héritage de classes présente donc
    un caractère incrémental qui peut être utilisé
    comme une facilité d'écriture.
  • (Définissant B comme héritant de A, on réalise
    l'économie de la description de A dans B, au prix
    peut être de quelques retouches permises par le
    langage).

34
Mauvais exemples
  • Faire en sorte que la classe "Cercle" hérite de
    "Point"
  • le cercle réutilise le point par héritage comme
    centre
  • Faire en sorte que la classe "Ellipse" hérite de
    "Cercle"
  • ellipse réutilise le diamètre comme un de ses
    demi-axes

35
Point et Cercle
  • Un point peut être vu comme un cercle dégénéré de
    diamètre nul. La seule relation logique qui peut
    unir ces deux classes est Point gt Cercle.
  • Dans ce cas, toutes les instances de Point, si
    elles héritent de Cercle, vont comporter un champ
    appelé "diamètre" qui leur est inutile.
  • La bonne approche est peut être de ne pas
    considérer d'héritage entre les deux classes.

36
Principe
  • S'il est possible de dire que "tout A est un B",
    alors
  • B ne doit pas hériter de A, et
  • A peut, le cas échéant, hériter de B.

37
Principe pour les données membres
  • S'il est possible de dire que tout A peut
    posséder un B, ou
  • S'il est vrai que tout A possède exactement un B,
    alors
  • B est une donnée de A

38
Deux situations pour l'héritage
  • Héritage pour extension
  • on ajoute des données membres. Cette situation
    est toujours présente quand on implante une
    interface
  • Héritage pour spécialisation
  • on restreint les domaines des attributs de la
    classes
  • on durcit les invariants de classe (intégrité)

39
Deux autres situations
  • Héritage pour surcharge on substitue le code
    d'une fonction par une autre, en application du
    polymorphisme
  • Héritage pour réutilisation pure (héritage
    privé) on réutilise le code de la classe mais
    pas son interface

40
Champs, accesseurs et aspects
41
Masquage de données
  • Un programme ne doit pas exposer les données
    membres de ses classes.
  • Cette information peut varier au cours des
    évolutions de la classe et ne doit pas être
    divulguée

42
Champs, accesseurs, modifieurs
  • Un champ (ou attribut, propriété, donnée membre)
    est PRIVE
  • Accesseur fonction permettant de lire la valeur
    d'un champ
  • Modifieur fonction permettant d'altérer l'état
    de l'objet

43
Conventions de nommage
  • Si une classe possède une propriété Xy
  • L'attribut (privé) est appelé "_xy"
  • L'accesseur (non Booleén) est "getXy()"
  • L'accesseur (Booléen) est "isXy()"
  • Le modifieur est nommé "setXy(...)"

44
Exemple
45
Aspects
  • D'autres langages plus évolués (plus anciens)
    règlent le problème du masquage de l'information
    d'une autre façon
  • Deux fonctions, les aspects de lecture et
    d'écriture, sont attachées potentiellement à
    chaque attribut.
  • Si elles sont présentes, elles sont appelées
    automatiquement de façon invisible à chaque
    lecture/écriture

46
Compatibilité ascendante
  • Toutes les versions futures d'une classe devront
    pouvoir être utilisées pour compiler des
    programmes clients anciens.

47
Exemple d'évolution
48
Exemple de divergence
49
Principes de Conception par Contrat
50
Conception par contrat
  • Ces idées ont été inspirées par Bertrand Meyer
  • La spécification des invariants de classe, et des
    pré et post conditions est préalable au codage
    proprement dit

51
Principe de substitution de Liskov
  • Une instance d'une classe peut être substituée
    par une instance d'une sous classe sans que
  • la compilation ne soit altérée
  • le programme ne soit altéré dans son
    comportement.
  • Toutes les clauses du contrat satisfaites par les
    superclasses sont satisfaites par les sous classes

52
Impact sur les invariants de classe
  • Les invariants de classe sont vérifiés par les
    sous classes
  • class A
  • int integrity()...
  • class B public A
  • int integrity()
  • Aintegrity()
  • ...

53
Impact sur les préconditions
  • Les préconditions des fonctions membres ne
    peuvent pas être durcies par les sous classes
  • Sinon, une fonction appelant la fonction
    abstraite pourrait provoquer un échec avec une
    nouvelle sous classe.

54
Exemple de Cercle et Ellipse
  • On a vu la possibilité de définir
    conceptuellement Cercle comme une sous classe de
    Ellipse.
  • La fonction resize(float x, float y) demande un
    traitement particulier.
  • Il n'est pas possible de durcir la précondition
    dans Cercle pour avoir "xy"
  • Que fait on?

55
Ellipse et Cercle (2)
  • Par exemple
  • void Cercleresize(float x, float y)
  • float auxmax(x,y)
  • Ellipseresize(aux,aux)
  • assert(integrity())//_x_y

56
Impact sur les post conditions
  • Les post conditions ne peuvent pas être
    assouplies par les sous classes
  • Sinon, les données retournées, ou l'état de
    l'objet, pourraient ne plus satisfaire les
    conditions du programme appelant après
    substitution

57
Le principe Open/Closed
  • La vision moderne de ce principe énoncé par Meyer
    est la suivante
  • L'interface de programmation d'une classe est
  • Open ouverte aux extensions
  • ajout de fonctions membres
  • Closed fermée aux modifications
  • pas de durcissement de l'invariant de classe ni
    des préconditions

58
Le couplage faible
  • Ce principe de conception demande que les
    composants logiciels (classes) soient le plus
    indépendant(e)s possibles.
  • en termes de connexions
  • en termes de création mutuelle
  • On vise ainsi à permettre une maintenance facile
    du code

59
Cohésion forte
  • Ce principe stipule que des éléments associés au
    sein d'une classe soient fortement dépendants
  • Si ce n'est pas le cas, il convient de les
    séparer (exemple des itérateurs)

60
Conception des interfaces de programmation
61
Le problème
  • Encore une fois, pour garantir une bonne
    compréhension collective des sources développés,
    il est préférable de renvoyer à des notions très
    communément partagées.
  • Le développement du logiciel open source a
    multiplié les besoins de normalisation des
    interfaces de programmation
  • Ex en Java notion de Bean

62
L'objet vu comme une machine.
  • Cette métaphore guide la définition des
    interfaces homme machine.
  • On voit une machine, et on observe son état sans
    agir sur elle
  • On agit sur une machine, sans nécessairement
    observer son état

63
Le capteur informatique
  • Une fonction dont la valeur de retour est une
    information sur l'état de l'objet ne doit sous
    aucun prétexte modifier l'état de l'objet.
  • Une telle fonction est appelée un accesseur.

64
Signature des accesseurs en C
  • data accesseur_i (args) const
  • Le mot clef "const" garantit que la fonction est
    sans effet sur l'objet support
  • Garantir qu'elle est sans effet sur des objets
    distants caractéristiques d'un état demande de la
    rigueur

65
Le bouton de commande
  • Lorsqu'on désire modifier l'état d'un objet, on
    le fait au travers d'une procédure.
  • La règle ici est qu'une telle procédure ne peut
    en aucun cas renvoyer une valeur décrivant l'état
    de l'objet après, ou pire encore, avant la
    modification.
  • On appelle une telle fonction un modifieur.

66
Signature des modifieurs en C
  • void modifieur _i (args)
  • "Void" garantit que la fonction ne renvoie pas
    d'information sur l'état de l'objet.

67
Identification des modifieurs
  • Une fonction est un modifieur s'il existe des
    situations où un accesseur change de valeur de
    retour après son appel.

68
Pourquoi être strict
  • Exemple de C (et C)
  • i i
  • n'est pas équivalent à
  • 2i

69
Un accesseur/modifieur présente le même défaut
  • Supposons qu'une fonction d'accès présente un
    effet de bord.
  • E1 (p-gtvalue() p-gtvalue())
  • sera différent de
  • E2 (2 p-gtvalue())

70
Avantages des modifieurs "void"
  • Absence des risques évoqués précédemment
  • Le calcul d'un état coûte potentiellement des
    ressources
  • Les appels de modifieurs sont fréquemment faits
    en ignorant la valeur de retour
  • Le calcul de cette valeur est alors fait
    inutilement
  • (exemple de char strcpy(char) en C)
  • Il doit exister un accesseur retournant l'état
  • On ne pourra pas retirer le calcul de la valeur
    de retour, et les interfaces sont "fermées".

71
Les modifieurs retournant "this"
  • Il est souvent utile toutefois de faire en sorte
    que les modifieurs retournent leur objet support
  • Cela permet d'enchainer des cascades d'appels, et
    justement de faire suivre le modifieur de
    l'accesseur voulu...
  • Container c
  • c.modif_f(params).modif_g(params).accesseur_h()

72
On veut quand même retourner un état
  • Exemple

73
Conversions implicites en C
  • En C, on peut avoir des modifieurs "this" et
    l'accès à l'état de l'objet

74
Cas particulier des opérateurs
  • Les opérateurs redéfinis en C sont souvent des
    modifieurs/accesseurs, dans la mesure où ils
    participent à des expressions complexes.
  • L'usage fait que leur "danger" d'utilisation est
    connu (ex. de "")

75
Fonctions d'usage
  • Les accesseurs "const" et modifieurs "void" ou
    "this" forment le squelette des interfaces de
    programmation. Doit en s'en contenter? NON.
  • Une API peut mettre à disposition une collection
    de fonctions d'usage qui combinent si besoin est
    modifieurs et accesseurs
  • Les opérateurs en font partie.

76
Interfaces de programmation
77
Etat logique / état physique
  • On doit veiller à ce que les modifieurs d'une
    classe soient de vrais modifieurs
  • leur appel modifie les données membre de l'objet
    d'une manière qui altère la sémantique attachée à
    l'objet.
  • Exemple insertion dans la liste

78
Que faire sinon?
  • Si un modifieur altère l'état physique (les
    données) sans agir sur l'état logique, c'est le
    signe que la classe doit être séparée.
  • C'est l'exemple des itérateurs

79
Principe
  • On définit les classes de manière à avoir
    identité entre état logique et état physique.

80
Masquage de données
  • Les conditions d'implantation d'une classe
    doivent être cachés aux utilisateurs
  • données membres, classes auxiliaires

81
Types de classes
82
Héritage
  • Classe abstraite
  • Classe concrète
  • Classe "nud"

83
Fonctionnalités
  • Classe de service
  • par exemple l'interface "displayable"
  • Classes de définition d'interfaces abstraites
  • l'abstraction Pile par exemple
  • Les classes poignée
  • Les classes "type de base" vérifié

84
Poignées
85
Interfaces abstraites
86
Fin du document
About PowerShow.com