Conception Oriente Objet Laurent Henocque http laurent henocque

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 Décembre 2008

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.

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

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

Panorama du concept d'objet

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.

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

Persistance • • La persistance d’un é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.

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 d’un même type (homogène).

Réactions • La réaction aux perturbations externes est simulée par des fonctions que l'on peut appliquer à l'objet. – – Message -> fonction Evénement -> fonction

Difficultés • • L'existence chez différents objets de fonctionnalités sémantiquement voisines, et pour autant différentes dans leur réalisation justifie le polymorphisme 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.

Difficultés • Les fonctions globales ne permettent pas avec une grande finesse le contrôle d'éventuelles restrictions au graphe d'appel du programme. • L’organisation en classe permet de finement définir les autorisations (public/protected/private)

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

Avantages du polymorphisme • • • Les programmes gagnent en abstraction Il n'est pas nécessaire de définir une règle de nommage des fonctions homologues (par exemple "bouge_caillou", ou bien "Caillou. Bouge"). L'écriture des programmes est facilitée.

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é « support »

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

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

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.

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: la méthode appelante peut terminer avant que la réponse ne parvienne

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, qui ne seraient pas apparues dans le cas synchrone

Classes et Types

La Classe (1) • On veut créer un nombre arbitraire d’objets • 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.

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.

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

Types abstraits • 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.

Types Abstraits et Preuve • Toutes les propriétés des instances d’un 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 d’un ensemble d’objets, indépendamment des perspectives de sa réalisation informatique.

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

Type = Classe + Invariant ? • Une classe décrit ses transitions de manière implicite : les fonctions membres qui provoquent des changements d’état. • Les états admissibles peuvent être spécifiés de manière semi-formelle par un invariant de classe • Cet invariant réalise par un test les axiomes applicables aux objets de cette classe

Types et Virtuelles • Les langages orientés objet modernes permettent de spécifier des fonctions virtuelles. • Une classe déclarant des méthodes virtuelles est communément appelée un type. • En effet, la présence de ces virtuelles oblige à réaliser partiellement le type abstrait

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 fonctions virtuelles par les 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.

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

C++/Java • C++ demande de déclarer les fonctions virtuelles • Toutes les méthodes sont virtuelles en Java. • En Java, le type est réalisé de telle sorte que chaque objet comporte un pointeur vers une représentation « consultable » de sa classe.

Variations autour des classes • • tout objet peut servir de prototype à la construction d'un autre objet (Javascript) 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++) une classe est elle même un objet, instance d'une métaclasse, …

Objets et Classification • La pensée occidentale développe 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. • La pertinence de la classification est mesurée par le 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.

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

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

Exemple de hiérarchie

Principes d'utilisation de l'héritage

B hérite de, ou possède un A

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

Mauvais exemples « NON PAS ENCORE EUX » • Faire en sorte que la classe "Cercle" hérite de "Point" – le cercle réutilise le point par héritage, en tant que centre • Faire en sorte que la classe "Ellipse" hérite de "Cercle" – ellipse réutilise le diamètre comme un de ses demi-axes

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

Principe Général • 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.

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 un B, alors • B est une donnée de A

Héritage pour extension • On ajoute des données membres. • Cette situation est toujours présente quand on implante une interface ou une classe abstraite

Héritage pour spécialisation • On restreint les domaines des attributs de la classes • On durcit les invariants de classe (intégrité)

Héritage pour surcharge • On substitue le code d'une fonction par une autre, en application du polymorphisme

Héritage pour réutilisation pure • On l’appelle aussi héritage privé • On réutilise le code de la classe mais pas son interface de programmation

Champs, accesseurs et aspects

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 • Exemple, une classe « Liste » n’expose pas les détails de son implantation ( « Elem » )

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

Conventions de nommage • Si une classe possède une propriété Xy • • L'attribut (privé) est nommé "_xy" L'accesseur (non Booleén) est "get. Xy()" L'accesseur (Booléen) est "is. Xy()" Le modifieur est nommé "set. Xy(. . . ) » • Ces conventions sont celles des Java Beans

Exemple

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

Aspects, lvalue, rvalue • Ainsi , faire référence à « a » en situation lvalue (écriture) peut appeler l’aspect correspondant de façon invisible • Faire référence à « a » en situation rvalue (lecture) peut appeler l’aspect de lecture de façon invisible

Compatibilité ascendante • Un argument fort pour le masquage: • Toutes les versions futures d'une classe devront pouvoir être utilisées pour compiler des programmes clients anciens. • Les structure de données techniques supportant les algorithmes doivent donc être cachés

Exemple d'évolution

Exemple de divergence

Principes de Conception par Contrat

Conception par contrat • Principe fondamental de conception par contrat (Bertrand Meyer) • La spécification des invariants de classe et des pré et post conditions est préalable au codage proprement dit.

Conception par contrat et Tests • La conception des interfaces de programmation doit se faire dans son ensemble avant de programmer. • L’écriture des programmes de tests doit se faire avant l’implantation concrète des méthodes • Les programmes de tests peuvent être compilés, même s’ils ne s’exécutent pas

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 relâchement de l'invariant de classe ni durcissement des préconditions, respect du principe de substitution de Liskov Ce principe est subsumé par les considérations précédentes

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

Impact sur les invariants de classe Les invariants de classe sont vérifiés par toutes leurs sous classes class A{ integrity(){. . . }; }; class B : public A { integrity(){ assert(A: : integrity()); . . . }

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 instance d’une future sous classe (inconnue au moment présent)

Ce principe doit être modulé • Liskov rend très difficile dans certains cas d’utiliser des classes concrètes ayant des sous classes • Lorsqu’une sous classe réalise un sous ensemble clairement identifié de la classe, et que son implantation offre pour services de contrôler l’appartenance à cet ensemble, on peut contredire le principe de substitution

Exemple de Cercle et Ellipse • On a vu la possibilité de définir conceptuellement Cercle comme une sous classe de Ellipse. Dans une interface graphique se pose la question du re-dimensionnement: • La fonction resize(float x, float y) demande un traitement particulier. • Il ne devrait pas être possible en vertu du principe de substitution de durcir la précondition dans Cercle pour avoir "x==y" • Que fait on?

Ellipse et Cercle (2) • Choix A/ on respecte le principe de substitution, éventuellement en dégradant arbitrairement la fonctionnalité void Cercle: : resize(float x, float y){ assert(integrity()); // demi-axes égaux float aux = min(x, y); // on pourra dessiner le cercle dans la boite Ellipse: : resize(aux, aux); assert(integrity()); //_x==_y }

Ellipse et Cercle (3) • Choix B/ on ne respecte pas le principe de substitution. – L’argument est que si un programmeur avait voulu utiliser le concept de cercle sans disposer de la classe, il l’aurait exclu des cas d’utilisation de la fonction « resize » générale.

Ellipse et Cercle (4) void Cercle: : resize(float x, float y){ assert(integrity()); // demi-axes égaux assert(x==y); // contredit Liskov Ellipse: : resize(aux, aux); assert(integrity()); //_x==_y }

Ellipse et Cercle (5) • Choix B/ on ne respecte pas le principe de substitution et on interdit l’accès à la fonction d’origine #define NOT_CALLABLE false void Cercle: : resize(float x, float y){ assert(NOT_CALLABLE ); // appel impossible } void Cercle: : resize(float x){ assert(integrity()); // demi-axes égaux Ellipse: : resize(x, x); assert(integrity()); }

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 • Cette situation n’est pas fréquemment rencontrée, car la principale postcondition est l’invariant de classe, qui est nécessairement satisfait

Principe de Couplage Faible • Les composants logiciels (classes) distincts sont 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. L’évolution d’une classe n’a que peu d’impact sur ses voisines

Principe de Cohésion Forte • Les éléments associés au sein d'une classe ou d’un package (groupe de classes) sont fortement liés • L’intérêt de les avoir groupés est justifié • Toutes les données membres sont toujours (ou presque) utilisées • Si ce n'est pas le cas, il convient de les séparer dans des classes distinctes (exemple des itérateurs)

Couplage/Cohésion vs. Héritage • Dans une classe B qui étend A par héritage, les attributs introduits par B sont – toujours utilisés (cohésion forte) mais ils sont – le plus possible indépendants de ceux qui sont hérités (couplage faible): • leurs états n’influent pas ou peu sur l’état du A qui est dans B

Principe d’Etat logique/physique • Tout modifieur d'une classe altère son état physique ET son état logique • Les modifieurs sont 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

La liste: Etat Logique Liste Elem Elem Liste Elem

La liste: Etat Physique Liste Elem Elem Liste

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 divisée. • Exemple des itérateurs

List -> List. Iterator Class List { Elem* first; Elem* current; … }; Class List { Elem* first; … }; Class Iterator{ Elem* current; };

Masquage de données Les détails d'implantation d'une classe doivent être cachés aux utilisateurs • données membres, classes auxiliaires, fonctions privées • On vise ainsi à empêcher que des programmes accèdent à des éléments non pérennes (compatibilité ascendante) et également risquent de compromettre les données

Conception des interfaces de programmation

Le problème • 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

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

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.

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 • Le cas échéant, garantir qu'elle soit également sans effet sur des objets connectés caractéristiques d'un état demande de la rigueur de programmation

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.

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.

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.

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

Un accesseur/modifieur présente le même défaut • Supposons qu'une fonction d'accès présente un effet de bord. E 1 = (p->value() + p->value()) • sera différent de E 2 = (2 * p->value())

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

Les modifieurs retournant "this" • Il est souvent utile toutefois de faire en sorte que les modifieurs retournent leur objet support • Cela permet d'enchaîner 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();

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

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

La variante create/end • Lorsqu’une fonction crée un objet, il est parfois utile de retourner celui ci, sinon this create. Sub. State("save. Or. Print"). //{ create. Req(ex, "bg", Color. RED). create. Sub. Region("Print"). //{ create. Root. State("default"). //{ create. Req. Callback(pr, …). create. Sub. State("print"). //{ create. Req(pr, "on", false). create. Req(fr, "Visible", true). end. Sub. State("print"). //} end. Root. State("default"). //} end. Sub. Region(). //} end. Sub. State("save. Or. Print"). //}

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 "++")

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.

Interfaces de programmation

Types de classes

Héritage • Classe abstraite • Classe concrète • Classe "nœud"

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é

Poignées

Interfaces abstraites

Fin du document • Des questions?