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