Conception Orientée Objet Laurent Henocque Enseignant Chercheur ESIL/INFO France 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 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 dun é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 dun 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. Lorganisation 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 "CaillouBouge"). 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 dobjets 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 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.

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 lappelle 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 » nexpose 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 "getXy()" L'accesseur (Booléen) est "isXy()" Le modifieur est nommé "setXy(...) » 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 laspect correspondant de fa ç on invisible Faire référence à « a » en situation rvalue (lecture) peut appeler laspect 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 limplantation 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{ int integrity(){...}; }; class B : public A { int 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 dune future sous classe (inconnue au moment présent)

Ce principe doit être modul é Liskov rend très difficile dans certains cas dutiliser des classes concrètes ayant des sous classes Lorsquune 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. –Largument est que si un programmeur avait voulu utiliser le concept de cercle sans disposer de la classe, il laurait exclu des cas dutilisation 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 laccès à la fonction dorigine #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 nest pas fréquemment rencontrée, car la principale postcondition est linvariant 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 dune classe na que peu dimpact sur ses voisines

Principe de Cohésion Forte Les éléments associés au sein d'une classe ou dun package (groupe de classes) sont fortement liés Linté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 ninfluent pas ou peu sur létat du A qui est dans B

Principe dEtat 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 Liste Elem

La liste: Etat Physique Liste Elem Liste Elem

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 -> ListIterator 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. E1 = (p->value() + p->value()) sera différent de E2 = (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 Lorsquune fonction crée un objet, il est parfois utile de retourner celui ci, sinon this createSubState("saveOrPrint"). //{ createReq(ex, "bg", Color.RED). createSubRegion("Print"). //{ createRootState("default"). //{ createReqCallback(pr, …). createSubState("print"). //{ createReq(pr, "on", false). createReq(fr, "Visible", true). endSubState("print"). //} endRootState("default"). //} endSubRegion(). //} endSubState("saveOrPrint"). //}

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?