Facultés Universitaires Notre-Dame de la Paix. Conception et Programmation Orientées- Object

Transcription

1 Facultés Universitaires Notre-Dame de la Paix Conception et Programmation Orientées- Object

2 RÉSUMÉ PRATIQUE... 4 CLASSE OBJET... 4 NOTION D HÉRITAGE... 4 LE POLYMORPHISME... 5 LES CLASSES ABSTRAITES... 6 LES INTERFACES... 6 LES EXCEPTIONS... 7 LES EXCEPTIONS PERSONNALISÉES... 7 GESTION DE PLUSIEURS EXCEPTIONS... 8 LES COLLECTIONS D OBJET... 8 RÉSUMÉ DU COURS THÉORIQUE CHAPITRE LA MODULARITÉ L ABSTRACTION CHAPITRE 2 : OBJETS ET JAVA LES OBJETS LES CLASSES LES DIAGRAMMES DE CLASSE L ENCAPSULATION VISIBILITÉ PACKAGES ET VISIBILITÉ OBJETS ET VARIABLES STACK ET HEAP PARTAGE DE RÉFÉRENCE LE GARBAGE COLLECTOR LA MUTABILITÉ L APPEL DE MÉTHODES LE TYPE CHECKING HIÉRARCHIE DES TYPES PRINCIPE DE SUBSTITUTION VALIDITÉ DES ASSIGNATIONS TYPE DÉCLARÉ VS TYPE EFFECTIF LE CASTING CONVERSION DE TYPE L OVERLOADING LE DISPATCHING LES TYPES D OBJETS PRIMITIFS VECTOR CHAPITRE 3 : ABSTRACTION PROCÉDURALE RAPPEL : ABSTRACTION PAR SPÉCIFICATION LES SPÉCIFICATIONS

3 MÉTHODE EN JAVA CONCEPTION D ABSTRACTIONS PROCÉDURALES CHAPITRE 4 : LES EXCEPTIONS RETOUR D UNE VALEUR PARTICULIÈRE DU TYPE DE RETOUR PRINCIPE DES EXCEPTIONS DANS LA SPÉCIFICATION LES TYPES D EXCEPTIONS DÉFINITION D EXCEPTIONS CRÉATION D EXCEPTIONS RENVOI D EXCEPTIONS GESTIONS D EXCEPTIONS : TRY{} ET CATCH{} LA PROPAGATION PROGRAMMER AVEC LES EXCEPTIONS CHAPITRE 5 : ABSTRACTION DE DONNÉES PRINCIPE LA SPÉCIFICATION L IMPLÉMENTATION LES MÉTHODES EQUALS, SIMILAR, CLONE ET TOSTRING AIDES À LA COMPRÉHENSION ET À LA VÉRIFICATION DE L IMPLÉMENTATION LA FONCTION D ABSTRACTION (FA) L INVARIANT DE REPRÉSENTATION (IR) L IMPLÉMENTATION DE LA FA ET DE L IR REMARQUES SUR LA FA ET L IR NE PAS EXPOSER LA REP TYPES MUTABLES VS TYPES IMMUTABLES LES 4 TYPES D OPÉRATIONS ADÉQUATION DE TYPES RAISONNEMENT RÉSUMÉ DU CHAPITRE 5 (TEL QUE DANS LE COURS) CHAPITRE 6 : ABSTRACTION DE L ITÉRATION OBJECTIF LES ITÉRATEURS EN JAVA LA SPÉCIFICATION D UN ITÉRATEUR IMPLÉMENTATION D ITÉRATEUR CHAPITRE 7 : HIÉRARCHIES DE TYPES DÉFINITION D UNE HIÉRARCHIE DE TYPES CLASSE ABSTRAITE INTERFACES SÉMANTIQUE DU SOUS-TYPAGE RÈGLE DES SIGNATURES RÈGLE DES MÉTHODES RÈGLE DES PROPRIÉTÉS RÉSUMÉ DE CE CHAPITRE

4 Note : Les «A retenir» ont été copiés du site du zéro. Classe objet RÉSUMÉ PRATIQUE Les 3 types de variables dans une classe objet : - Les variables d'instances : ce sont elles qui définiront les caractéristiques de notre objet. Elles sont de préférences privates, ainsi on ne peut pas y accéder ou les modifier sans passer par des accesseurs ou des mutateurs. - Les variables de classes : celles-ci sont communes à toutes les instances de notre classe. Exemple: pour le nombre d'instances d'une classe. Déclarations public ou private, toujours static. Attention! Les méthodes de classes n'utilisant que des variables de classes doivent toujours être déclarées static. On les appelle méthodes de classes. (Ce n'est plus vrai si elle utilise aussi d'autres types de variables). Ne pas oublier de préciser dans quelle classe elle se trouve (par ex: ville.getnombreinstance()). - Les variables locales : ce sont des variables que nous utiliserons pour travailler dans notre objet. Notes : Les constructeurs d'une classe doivent porter le même nom que la classe. This fait référence à l'objet courant. A retenir : Une classe permet de définir des objets. Ceux-ci ont des attributs (variables d instances) et des méthodes (méthodes de classes + accesseurs (le terme accesseurs comprend aussi les mutateurs en fait)). Les objets permettent d'encapsuler du code et des données. Une classe est par défaut déclarée public. Le ou les constructeurs d'une classe doivent porter le même nom que la classe, et pas de type de retour! Il est recommandé de déclarer ses variables d'instance private. Dans une classe, on accède aux variables de celle-ci grâce au mot clé this. Une variable de classe est une variable devant être déclarée static. Les méthodes n'utilisant que des variables de classes doivent elles aussi être déclarées static. On instancie un nouvel objet grâce au mot clé new. L'ordre des paramètres passé dans le constructeur doit être respecté. Eclipse nous aide à développer vos applications (javadoc, création de getters et setters automatique). Notion d héritage Apprendre à créer des Classes héritées (classes dérivées) de nos classes mères (classes de base). (Une classe héritée peut aussi être une classe mère pour d autres classes). Mot-clé : extends (classe héritée extends classe mère). Les objets d une classe héritée possèdent tous les attributs et méthodes associée des objets de la classe mère. Les objets hérités peuvent accéder à toutes les méthodes public de leur classe mère. Pour accéder aux variables et méthodes de la classe mère il faut donc que ceux-ci aient la visibilité public. Si elles sont private, il y a un moyen pour qu elles restent protégée des autres classes mais qu elles soient accessibles par les classes filles : les mettre en visibilité protected. Attention : java ne gère pas les héritages multiples (<> au C++) : une classe fille ne peut hériter que d une seule classe mère!!! Pour récupérer les éléments de l objet de base et les envoyer à notre objet hérité : utilise super. 4

5 Pour le constructeur de la classe fille, nous pouvons faire appel au constructeur de la classe mère juste en écrivant super(), et ajouter ensuite des instructions d initialisation spécifiques à la classe fille. (Pareil pour les méthodes de classes). A retenir : Une classe hérite d une autre classe par le biais du mot clé extends. Une classe ne peut hériter que d une seule et unique classe. Si nous ne définissons pas de constructeur dans nos classes, la JVM se charge d en créer un à l interprétation. Si aucun constructeur n est défini dans une classe fille, la JVM en créera un et appellera automatiquement le constructeur de la classe mère. La classe fille hérite de toutes les propriétés et méthodes public et protected de la classe mère. Les méthodes et propriétés private d une classe mère ne sont pas accessibles dans la classe fille. On peut redéfinir (changer tout le code) d une méthode héritée. Le polymorphisme Il permet de manipuler des objets sans vraiment connaître leur type. Covariance des variables : une variable objet peut contenir un objet qui hérite du type de cette variable. La covariance est efficace dans le cas où la classe héritante redéfinit certaines des méthodes de sa super classe. Attention : surcharge de méthode différent de méthode polymorphe : - Une méthode surchargée a des paramètres que la méthode de base n a pas, ou a le même nombre de paramètres, mais de types différents. - Une méthode polymorphe a un squelette identique à celle de base, mais un traitement différent. Celle-ci fait référence à une autre classe et donc, par extension, à une autre instance de cette classe. On peut dire que les méthodes polymorphes sont typiques des classes héritées. Par défaut, lorsque l on crée une classe, celle-ci est héritée de la classe Object présente dans Java. On hérite donc des méthodes protected et public d Object. On peut polymorpher des méthodes d Object, (on les redéfinit) et lorsqu on les appelle, c est par ex : obj de type Object et : obj.methodepolymorphée() qu il faut écrire, et cela va quand même appeler la méthode que l on a redéfinie. Si on met obj.methodeinventéeparnous() ca va planter car une méthode est invoquable par un autre objet que si celui-ci définit la dite méthode! Donc dans ce cas, il faut préciser que la référence de type Object est en fait une référence de type «machincréé» : ((machincréé)obj).methodeinventéeparnous(). Donc, intérêt des méthodes polymorphes : plus besoin de se soucier du type de variable appelante, mais il faut utiliser le type Object avec parcimonie. Les méthodes finales : («final»), elles sont figées et on ne pourra JAMAIS redéfinir une méthode déclarée final. Il existe aussi des classes final. A retenir : On peut utiliser le polymorphisme sur une méthode par le biais du mot clé super. Le polymorphisme permet, entre autres, d ajouter des traitements spécifiques à une méthode en continuant d utiliser les traitements déjà définis (utilisation de super). Grâce à l héritage et au polymorphisme, nous pouvons utiliser la covariance des variables! 5

6 Si une méthode d une classe mère n est pas redéfinie ou polymorphée, à l appel de cette méthode par le biais d un objet enfant, c est la méthode de la classe mère qui sera appelée! Vous ne pouvez pas hériter d une classe déclarée final. Une méthode déclarée final est non redéfinissable. Les classes abstraites Il existe des classes que l on ne veut pas instancier. Cette classe va alors être déclarée abstraite, et servira de super classe. On définit une classe abstraite à l aide du mot clé abstract. Une classe abstraite peut avoir des méthodes normales, et des méthodes abstraites, pour pouvoir faire des méthodes abstraites, il faut que la classe soit abstraite! Mais ce n est pas parce qu une classe est abstraite qu elle à forcément des méthodes abstraites. Une méthode abstract n a pas de corps! Ex : abstract void nawak(); est une méthode abstraite. Etant donné qu une méthode abstraite n a pas de corps, c est aux classes filles de la classe abstract de redéfinir ces méthodes. Pour instancier, n oublions pas qu il faut faire un new, donc si nous avons une classe nommée «Class1», nous avons le droit de faire : Class1 machin = new machin(); car ce qu on instanciera c est un machin, et non une Class1 (machin étant une classe héritée de Class1). Il ne faut pas oublier qu il faut que les sous-classes d une classe abstraite doivent implémenter le corps des méthodes abstraites de cette classe. (Pas forcément les classes filles directes, une classe fille d une classe fille d une classe mère peut l implémenter à la place de la première classe fille tant que la méthode abstraite soit implémentée avant son utilisation ) A retenir : Une classe est définie comme abstraite avec le mot clé abstract. Une classe abstraite ne peut pas être instanciée. Une classe abstraite n est pas obligée de contenir de méthode abstraite. Si une classe contient une méthode abstraite, cette classe doit alors être déclarée abstraite. Une méthode abstraite n a pas de corps. Les classes abstraites sont à utiliser lorsqu une classe mère ne doit pas être instanciée. Les interfaces Une interface permet de définir un super type, composé uniquement de méthodes abstraites. En fait, une interface est une classe 100% abstraite. Déclarer une interface qui est un super type permet d utiliser le polymorphisme. Une classe peut utiliser plusieurs interfaces, alors qu elle ne peut hériter que d une classe mère. Déclaration d une interface : public interface A{ } Les méthodes d une interface sont automatiquement (et uniquement) abstraites, pas besoin d ajouter abstract dans leur déclaration. Pour qu une classe utilise une (ou plusieurs) interface(s) il faut utiliser le mot clé implements. Lorsque l on implémente une ou plusieurs interfaces, on doit obligatoirement redéfinir leurs méthodes (dans la classe même où on a mis l implements, sinon java pas ). La motivation de base pour la création d interface est que lorsqu on a notre implémentation avec nos jolies classes abstraites, nos superbes classes normales, etc et que l on doit ajouter brusquement de façon infâme des fonctionnalités pour adapter le programme à une nouvelle utilisation, on ne veut pas tout changer, et 6

7 surtout continuer à pouvoir profiter du polymorphisme, tout cela en laissant notre code marcher comme avant, mais en disposant aussi des nouvelles fonctionnalités. Le polymorphisme est menacé sans l utilisation d interface, dans le cas où l on ajoute les nouvelles fonctionnalités dans la classe où elles sont nécessaire, ce qui fait que, pour accéder à ces méthodes (les nouvelles fonctionnalités) il faudra passer par une référence à un objet de la classe, au lieu d appeler les objets par le biais d un super type ce qui serait plus élégant A retenir : Une interface est une classe 100% abstraite. Toutes les méthodes d une interface n ont pas de corps. Une interface sert à définir un super type et à utiliser le polymorphisme. Une interface s implémente dans une classe en utilisant le mot clé implements. On peut implémenter autant d interfaces que l on veut dans nos classes. On doit redéfinir toutes les méthodes de l interface (ou les interfaces) dans notre classe. Les exceptions Quand on a une exception qui surgit dans l exécution d un programme, celui ci se bloque et renvoie le nom de l exception, et s arrête. Pour éviter qu il s arrête, il faut traiter l exception, et ceci grâce au try{} catch{}. Dans les {} du try, on met le code susceptible de générer une exception, et dans les {} du catch, on met ce que le programme doit faire si une exception est capturée. Pour être plus précis : try{ code pouvant être foireux } catch(exception possible d être renvoyée + var stockant le type d exception){ si cette exception est capturée, je la traite } On stocke le type de l exception survenue dans une variable car on peut ainsi l afficher dans un message par exemple, grâce au getmessage : System.out.println(var.getMessage()); Grâce à cela, le programme continue son exécution après l interruption. Les exceptions personnalisées On peut créer nos propres exceptions pour cela il faut deux nouveaux mots clé : - throws qui permet de dire qu une classe, une instruction, une méthode peut renvoyer une exception. throws est suivi du nom de la classe qui va gérer l exception. (définit le type d exception qui peut être générée par l instruction, ou la classe précédant le mot clé throws). - throw, qui permet d instancier un objet dans la classe suivant l instruction throws. throw est suivi d un new ainsi que d un objet cité avec throws. Il lance une exception. En gros, on prévient s il y a risque d exception en ajoutant throws nomexception derrière l en-tête, et on fait throw new nomexception à l endroit où l on veut la lancer. Pour créer une exception, on crée une classe, avec le nom de l exception, qui extends Exception. A l intérieur de cette classe, on fait la même démarche que pour un constructeur. Par ex : class nawakexception extends Exception{ public nawakexception(){system.out.println(mais tu fais n importe quoi!) ;} } Il faut ensuite ajouter un bloc try{} catch{} là où la méthode est appelée. Attention, une variable déclarée dans un bloc d instructions n existe que dans ce bloc d instructions! Solution pour un objet étant instancié dans un try et réutilisé ensuite : le déclarer en dehors du bloc (par ex en l initialisant à null). 7

8 Attention cependant à la NullPointerException qui survient si une exception est levée, car si l objet est initialisé à Null, que l éxécution dans le try{} renvoie une exception, et que c était dans cette exécution que l objet était instancié, si on utilise l objet après ça plante, solution : dans le catch, instancier l objet grâce à un constructeur par défaut (qui initialise l objet à 0, ou autre valeur par défaut, en quelque sorte). On peut obtenir plus d information sur l exception, notamment en renvoyant la valeur de la variable posant problème Méthode printstacktrace() : permet de situer l exception dans le code (l objet passé en paramètre de la clause catch à des méthodes héritées de Exception). Gestion de plusieurs exceptions Derrière le throws, on peut mettre plusieurs exceptions, séparées par «,». On peut faire plusieurs catch{} à la suite d un try{}, il faut organiser les catch selon la pertinence de l exception (le premier catch est traité en premier, et les catch suivant ne sont pas traités si le premier est exécuté). Note : en faisant un super dans le constructeur d une exception, on hérite des méthodes d Exception, comme le getmessage() par exemple. A retenir : La super classe qui gère les exceptions s appelle : Exception. Lorsqu un événement que la JVM ne sait pas gérer apparaît, une exception est levée. On peut créer une classe d exception personnalisée en créant une classe héritant de la classe Exception. L instruction qui permet de capturer des exceptions est le bloc try{} catch{}. Si une exception est levée dans le bloc try, les instructions figurant dans le bloc catch seront exécutées si celui-ci capture l exception levée. On peut ajouter autant de blocs catch que l on veut à la suite d un bloc try. Mais il faut respecter l ordre de pertinence. Du plus pertinent au moins pertinent. Dans une classe objet, on peut prévenir la JVM qu une méthode est dite «à risque», grâce au mot clé throws. On peut définir plusieurs risques d exceptions sur une même méthode, il suffit de les séparer par une «,». Dans cette méthode, on peut définir les conditions d instanciation d une exception et lancer cette dernière grâce au mot clé throw suivit de l instanciation. Une instanciation lancée par le biais de l instruction throw doit être déclarée avec throws au préalable. Un exemple vaut mieux qu un long discourt, c est vrai, donc si vous avez eu du mal avec cette partie, les exemples du site du zéro sont vraiment simple et font très vite comprendre. Les collections d objet Tous ces objets nécessitent l importation de java.util. L objet LinkedList Liste chainée liste d élément dont chacun est relié au suivant par une référence à ce dernier. La taille d une LinkedList n est pas fixe (on peut ajouter et retirer). Accepte tout type d objet. Le dernier élément pointe vers null. Déclaration normale : List elt = new LinkedList) Pour ajouter : elt.add(truc à ajouter) Pour l itération utiliser elt.size() Pour accéder à l élément en cours : elt.get(var de stockage) 8

9 On peut aussi utiliser un Iterator pour parcourir la liste. ListIterator eltiterator = elt.listiterator() Pour parcourir utiliser eltiterator.hasnext() et pour afficher utiliser eltiterator.next() L objet ArrayList Objet de taille illimitée (conceptuellement parlant) qui accepte n importe quel type de données (y compris null). Donc on peut mettre des String, des int, etc dans le même objet. Méthodes : - add() - get(int index) - remove(int index) - isempty() renvoie true si c est vide - removeall() - contains(object élément) renvoie true si l élément appartient à l ArrayList - L objet Hashtable Une Hashtable (table de hachage) est un objet entrant dans la catégorie Map, c est à dire qu il range ses éléments avec un système clé-valeur, la clé étant unique, mais la valeur pouvant être la même pour plusieurs clés. On parcourt l objet grâce aux clés, mais on peut utiliser la classe Enumeration. Tout fonctionne comme pour le LinkedList (l Iterator ressemblant à l Enumeration dans sa déclaration et son utilisation) à part le nom des méthodes : put(clé, valeur) Et pour l Enumeration (Enumeration machin = hash1.elements()) - hasmoreelements() - nextelement() Autres méthodes : - isempty() - contains(object value) = containsvalue(object value) renvoie true si la valeur existe - containskey(int key) renvoie true si la clé existe - elements() retourne une énumération des elts de l objet - keys() retourne la liste des clés sous forme d énumération - L objet HashSet Un objet Set est une collection qui n accepte pas les doublons (null ne peut être présent qu une fois). Certain Set sont plus restrictif que d autres. On peut le parcourir à l aide d Iterator ou d un tableau d Object. Pour le tableau d Object : Object[] obj = monhashset.toarray(). Méthodes : - Add() - contains(object value) - isempty() - iterator() 9

10 - remove(object o) - toarray() - 10

11 Chapitre 1 RÉSUMÉ DU COURS THÉORIQUE La modularité La modularité est la caractéristique qu ont les programmes décomposés en modules! Les modules ont des responsabilités bien définies et coopèrent pour honorer les obligations du programme. Un module peut déléguer une partie de ses responsabilités à un autre. La modularité est une forme particulière de décomposition. L abstraction L abstraction est la faculté d oublier momentanément les détails d un problème pour se focaliser sur les aspects intéressants. Nous connaissons déjà : - L abstraction par paramétrisation (lorsque l on faisait des méthodes (rappel : paramètres dans l appel de la méthode : paramètres effectifs; paramètres dans l en-tête de la méthode : paramètres formels)). - L abstraction par spécification (pré/post, le quoi assumé par le module pas le comment). De là se dérivent 3 techniques avancées : - L abstraction procédurale (procedural abstraction) Extension de l ensemble des opérations/méthodes/fonctions/routines fournies par la machine virtuelle/abstraite définie par le langage de programmation. Décomposition de type fonctionnel, utilisant les deux premiers types d abstraction. - L abstraction par les données (data abstraction) Extension de l ensemble des types de données fournis par la machine virtuelle du langage. Autour d un type de données, on regroupe les opérations qui le concernent : CRUD (Create, Read, Update, Delete). On parle de type de données abstrait. Pour les autres programmeurs, le nouveau type de donnée peut être utilisé au travers des opérations empty, insert, delete... Ces opérations doivent pouvoir être utilisées sans avoir à connaître leur implémentation. Elles peuvent être définies les unes par rapport aux autres. C est l abstraction la plus importante, l outil de base de la POO. Cette abstraction est complémentée par l abstraction par hiérarchie de types : - Les sous-types (+ spécifiques) et les super-types (+ généraux). - Toute propriété qui est valable pour un type, est valable pour tous ses sous-types et toute opération définie pour un type est applicable pour tous ses sous-types. - On raisonne donc sur une famille de types. - L abstraction de l itération (iteration abstraction) Permet d itérer sur un ensemble d éléments en ignorant comment ceux-ci sont obtenus. Résumé supp du Chapitre : Le «secret» du développement efficace de logiciels de qualité est une bonne décomposition! La décomposition doit être guidée par l abstraction. Deux formes d abstraction de base : par paramétrisation et par spécification. 11

12 Formes plus élaborées : procédurale, itération, données, hiérarchie de types. Il est plus important de savoir bien décomposer un problème/ programme que de savoir «coder». 12

13 Chapitre 2 : Objets et Java Les Objets Objet (au sens restreint) : - «Morceau» de programme en cours d exécution qui possède : Un état contenant des données manipulées par le programme. Un comportement fait d opérations (appelées méthodes). - On interagit avec un objet en invoquant ses méthodes. «On» = le code appelant (un objet, une méthode ou le programme principal). - Les méthodes d un objet permettent (entre autres) d'accéder à son état : lire/consulter (Read, le R de CRUD) ou écrire/modifier (Update, le U de CRUD). Note : l OO manipule des objets représentant souvent des entités de la vie réelle (personnes, concepts, ). Les classes Les programmes Java sont composés de définitions de classes (et d interfaces). Classe = élément d un programme. Objet = élément d une exécution. A tout moment de l exécution, chaque classe du programme peut avoir plusieurs objets (instances). Une classe a deux utilités possibles : Définir des collections de méthodes/méthodes/opérations (abstraction procédurale) Définir des types de données (abstraction par les données). Les diagrammes de classe Dans les diagrammes de classe, les méthodes static sont soulignées, les méthodes public sont précédées d un «+». Rappel : les méthodes static d une classe sont des méthodes ne contenant que des variables de classes (les variables de classes sont communes à toutes les instances de notre classe), et les méthodes public sont visibles et accessibles par les autres méthodes (de la classe ou en dehors de la classe). Il n y a pas de static dans les déclarations de méthodes de type de données. Le nom de la méthode appelée est précédé du nom de la classe dans laquelle elle est définie suivi d un «.». On appelle cette méthode comme ceci (par ex) : int x = Num.gcd(15,6); L absence de valeur de retour s indique par le «type» void. Lorsque l on instancie un nouvel objet, par exemple : MultiSet m = new et puis que l on appelle une méthode de la classe MultiSet via m : m.insert(9); par exemple, on fait un appel sur l instance et non pas sur la classe. Si on avait fait par ex : init(m); on aurait fait un appel sur la classe. Les méthodes invisibles pour les autres classes sont déclarées private, une méthode private est dite encapsulée dans sa classe. Dans les diagrammes de classes, les méthodes private sont précédées d un «-». 13

14 L encapsulation Petit rappel : les classes servent entre autres à programmer des types abstraits (c est l abstraction par les données). Ces types abstraits sont dotés : - D une interface spécifiant les méthodes pouvant être effectuées par une instance du type et représentant ses responsabilités. - D une implémentation précisant : - Les structures de données (qui encodent l état d une instance). - Le corps des méthodes. - Des méthodes auxiliaires. Attention, type abstrait et méthode (et classe) abstraite sont deux notions différentes. Une méthode abstraite est une méthode qui n a pas de corps, qui délègue son implémentation aux classes filles. Rappel : si, dans une classe, on a une méthode abstraite, cette classe doit être déclarée abstraite, avec abstract. L abstraction par les données est une forme d encapsulation : seule l interface d un objet est accessible depuis son environnement (= les autres classes); l implémentation est cachée. N oublions pas qu une méthode private est dite encapsulée, comme on a pas accès non plus à l implémentation d une abstraction de données, c est aussi une forme d encapsulation. Rappel : une interface est une classe (abstraite) ne contenant que des méthodes abstraites. Principe de Parnas : - La définition d une classe doit fournir à l environnement toutes les informations nécessaires pour manipuler correctement une instance de la classe, et rien d autre. - L implémentation d une méthode doit se baser sur toutes les informations nécessaires à l accomplissement de sa tâche, et sur rien d autre. Visibilité Dans la définition d une classe, la distinction entre une interface et une implémentation s exprime par un marqueur de visibilité associé aux éléments, c est à dire les méthodes et les variables membres de la classe : - Un élément public est rendu accessible à tout le code du programme. - Un élément private n est accessible que par le code de la classe même. En fait, la notion d interface ici est un peu différente de la notion vue plus haut. Mais on voit quand même bien instinctivement que cette notion est assez proche de la définition d une interface comme étant une classe 100% abstraite, dans le sens que l implémentation de celle-ci reste cachée aux classes extérieures (l environnement) comme en quelque sorte avec le private. Rappel : on ne peut pas instancier une classe abstraite. Packages et visibilité Les classes sont regroupées en packages, ces packages sont avant tout une méthode d encapsulation. Les classes ont une visibilité, seules les classes déclarées public peuvent être utilisées par du code se trouvant dans d autres packages. Les classes non déclarées public ne sont utilisables que par le code du package. Déclarations : package NomPackage; public class NomClasse{ } 14

15 Les éléments private restent confinés à la classe. Les éléments public d une classe déclarée public sont accessible de l extérieur du package (exception : visibilité protected). Les éléments déclarés package sont accessible au code (des autres classes) du package quelle que soit la visibilité de la classe à laquelle ils appartiennent. Les packages sont également utiles pour le nommage : - Les packages sont organisés hiérarchiquement (différent de la hiérarchie de classes). - Chacun possède un nom qualifié (fully qualified name) qui reprend toute la hiérarchie du package et l identifie de manière absolue. - Un même package ne peut donc contenir deux sous-packages (directs) de même nom. - Un même package ne peut pas non plus contenir directement deux classes de même nom. - Toute classe possède un nom court ou nom relatif (par rapport au package). - Toute classe possède aussi un nom qualifié (fully qualified name) ou nom absolu : nomqualpackage.nomclasse. - Si du code doit accéder à une classe du même package, il peut se contenter du nom court. - Si du code doit accéder à une classe d un autre package, il doit utiliser : - Soit le nom qualifié, - Soit importer la classe ou le package dans laquelle elle se trouve. Attention aux conflits! Si on importe un package, on a plus besoin d écrire le nom qualifié, mais alors il y a possibilité de conflit si une classe de même nom que celle du package existe déjà dans la classe actuelle. Pour importer un package : [import NomPackage [.NomPackage] * [.NomClasse] ;]* Objets et variables Les données du programme sont stockées dans des variables. Toute variable possède un type, qui est soit : - Un type primitif (int, boolean, char ). - Un type d objet (String, MultiSet, int[], ). Les types primitifs : il en existe 8 en Java, ils sont prédéfinis et on ne peut pas en définir de nouveaux, un type primitif définit un ensemble de valeurs. Les types d objets : définit un ensemble d objets, l utilisateur peut définir autant de nouveau types d objets qu il veut. Il en existe déjà qui sont prédéfinit (par ex : String). Une variable primitive (variable d un type primitifs) contient une valeur de ce type. Elle peut être initialisée à la déclaration, elle doit l être avant toute utilisation. Une variable de référence est une variable de type objet qui contient une référence vers un objet de ce type. (aussi appelé pointeur). Toute variable qui n est pas primitive est un pointeur, elle doit être initialisée avant toute utilisation, si elle ne pointe vers aucun objet, elle a la valeur null. Stack et Heap Ce sont les deux mémoires de la JVM (stack = pile, heap = tas). Les variables locales, contenant des valeurs ou des références, sont stockées dans le stack, tandis que les objets sont stockés dans le heap. 15

16 Pour créer un objet dans le heap, on utilise new (par ex : int[] tab = new int[3];) New a pour effet : 1. D allouer une partie du heap au stockage d un objet du type indiqué. 2. D initialiser l objet par un constructeur. 3. D assigner une valeur de référence à l objet nouvellement créé, qui le distingue de tous les autres (object ID) 4. De retourner cette valeur de référence (et donc dans l ex assigner à tab la valeur de référence). On peut aussi faire : int[] tab = {1,5,7,9}; Partage de référence Si une variable de référence se voit donner une valeur de référence déjà assignée à une autre variable, les deux variables partagent (la référence vers) l objet. L objet devient alors accessible par ces deux variables. L opérateur «==» détermine si deux variables ont la même valeur, et renvoie un boolean. Attention, pour les variables de références, ça teste s ils pointent vers le même objet. Le garbage Collector Le garbage collector (ou ramasse-miettes) est la partie de la machine virtuelle Java chargée de libérer la mémoire (heap) occupée par les objets qui ne sont plus référencés. Le processus de garbage collection se déclenche périodiquement ou lorsque la mémoire est saturée. La mutabilité Un objet est mutable ssi son état peut changer. Dans le cas contraire, il est immutable. Il appartient au concepteur de la classe de décider de sa mutabilité. Par exemple, les String sont immutables, il n existe pas de méthode ou d opérateur qui modifie (Update) un String une fois qu il a été créé. Quand on modifie un String, cela crée un nouvel objet String avec les modifications dedans, l ancien objet String va être supprimé au prochain passage du garbage collector, car il ne sera plus référencé, car son ancienne référence pointera vers le nouveau String. Les tableaux sont quant à eux mutables. Si un objet mutable est partagé par plusieurs variables, toute modification de l objet effectuée à partir d une des variables est visible au travers des autres. L appel de méthodes En Java, l appel à une méthode m se fait via l"instruction <expr>.m(<expr1>, <expr2>,...,<exprn>) et est traité comme suit: <expr> est évaluée de manière à fournir la classe (si méthode statique) ou l objet dont on invoque la méthode. Si <expr> est évaluée à null, l exécution sera interrompue par une NullPointerException. Les expressions <expr1>, <expr2>,...<exprn> sont évaluées (de gauche à droite) de manière à fournir les paramètres effectifs de l appel. 16

17 Un activation record est créé dans le stack réservant de la mémoire pour les paramètres formels et variables locales de la méthode. Les paramètres formels prennent les paramètres effectifs pour valeurs dans le stack (passage de paramètres par valeur). C est à dire que les valeurs des paramètres effectifs sont copiées dans l activation record Le contrôle est passé à la méthode. C est le dispatching. Ce mécanisme complexe sera abordé plus loin. Le type checking Java étant un langage fortement typé, le compilateur vérifie que toutes les assignations et que tous les appels sont corrects du point de vue du typage, toute erreur à ce niveau étant sanctionné par une erreur de compilation. Le type checking requiert : Que toute déclaration de variable indique le type de celle-ci. Que toute déclaration de méthode indique sa signature les types des paramètres, le type du résultat, les types d exceptions renvoyées. Ces informations de typage permettent au compilateur de déduire le type apparent de toute expression, ce qui permet de vérifier la correction des assignations et des appels. Cela assure le «type safe», aucune erreur de typage (type mismatch) ne peut survenir pendant l exécution, et il n est pas possible que le programme manipule des données d un autre type que celui qu il croit manipuler. Il existe deux autres mécanismes pour que le programme soit type safe : l automatic storage management (Il s agit de l allocation et la désallocation automatique de la mémoire dans le heap) et l array bound checking. Hiérarchie des types Les types non primitifs sont organisés de façon hiérarchique. Un type donné T peut avoir plusieurs super-types (ses ancêtres dans la hiérarchie). Il est dit être un sous-type (subtype) de chacun de ses super-types. (Cela ne contredit pas ce qui est dit au début du résumé, une classe ne peut être héritée que d une classe à la fois, mais cette classe peut elle même être une sous classe d une autre classe). L organisation hiérarchique des types est un mécanisme d abstraction permettant d ignorer les différences entre types pour ne plus voir que ce que leurs comportements ont de commun et qui se trouve dans leurs supertypes communs. La relation de sous-typage est : transitive et réflexive. Principe de substitution «Si S est un sous-type de T, les objets de type S doivent pouvoir être utilisés dans tout contexte qui requiert des objets de type T.» Implications : - Toutes les méthodes de T doivent être disponibles dans S (vérifié par le compilateur Java). - Les appels à ces méthodes doivent produire le même comportement dans S et T Non vérifiable par le compilateur puisque cela reviendrait à pouvoir prouver que deux programmes ont le même comportement. Doit être garantit par le programmeur. 17

18 Pour l instant, contentons nous d utiliser des types prédéfinis supposés offrir ces garanties. Object Il existe un type Object, qui est supertypes de tous les types (qu ils soient prédéfinis ou non). Ce type contient notamment : boolean equals (object o); et String tostring(); qui peuvent être invoquée sur tout objet java. Validité des assignations Règle : l assignation v = <expr> (v variable de référence) est valide si le type apparent de <expr> est un sous-type du type apparent de v. Type déclaré VS type effectif Type déclaré (apparent type, compile-time type) = type d une variable tel qu il est donné dans sa déclaration (il est le même pendant toutes les exécutions). Type effectif (actual type, runtime type) = type d une variable à un moment donné de l exécution, déterminé par le type de l objet qu elle référence dans le heap (celui-ci est déterminé à la création de l objet). Le type checking (à la compilation) est toujours effectué sur base du type déclaré. Validité des appels de méthodes : Règle : la validité des appels de méthodes est vérifiée de manière analogue aux assignations c est à dire : - Le type déclaré de l objet sur lequel on invoque la méthode doit être un sous-type du type pour lequel la méthode a été définie. - Le type déclaré d un paramètre effectif doit être un sous-type du type déclaré du paramètre formel. Les deux règles de validité que l on vient de voir ont pour conséquence que, à l exécution, le type effectif d une variable ou d une expression est toujours un sous-type de son type déclaré. Le casting Via le casting on peut invoquer une méthode sur un objet dont le type déclaré l interdit mais dont on sait que le type effectif le permet. On peut aussi assigner à une variable la valeur d une expression dont le type déclaré l interdit mais dont on sait que le type effectif le permet. (par ex : (String) obj ; on assure que obj est bien un String). Il provoque la survenance d une vérification de type à l exécution. Si cette vérification échoue => renvoie ClassCastException. Conversion de type On peut faire des conversions implicites de valeurs d un type primitif en valeur d un autre type primitif. Par ex, les char peuvent être élargis (widened) en int. L overloading Les opérateurs sont overloadés (surcharchés). On peut overloader les méthodes que nous définissons. Il s agit du même nom de méthode, soit avec plus de paramètres, soit avec les mêmes paramètres mais de types différents. Lorsque plusieurs définitions de méthodes surchargées peuvent convenir à un même appel de méthode, le 18

19 compilateur résout l ambiguïté en choisissant la plus spécifique. Une définition de méthode m1 est plus spécifique qu une autre définition m2 si tout appel valide à m1 serait également un appel valide à m2 moyennant plus de conversions. S il ne sait pas résoudre l ambiguïté, l utilisateur peut la lever en faisant une conversion explicite du type en utilisant un cast dans l appel. L overloading s applique sur les types primitifs mais aussi sur les types abstraits. Il existe cependant des ambiguïtés que l on ne peut lever. Vient alors le dispatching. Le Dispatching Idée : garantir que quand une méthode est appelée sur un objet donné, c est le code fourni pour cette méthode et cet objet (type effectif) qui est exécuté. Mais il se peut qu à la compilation, on ne puisse déterminer quel code appeler car seul le type apparent est connu du compilateur. Il est donc nécessaire d avoir un mécanisme à l exécution qui fasse le dispatching vers le code souhaité. Dispatch Vector Chaque objet (dans le heap) contient une référence vers un dispatch vector. Celui-ci contient une entrée pour chaque méthode d un type d objet donné. Un dispatch vector n est associé à un objet qu à l exécution en fonction de son type effectif. Le compilateur ne fait que générer le code qui accède à l entrée de la méthode dans le dispatch vector et qui se branche à l endroit où le dispatch vector dit que le code de la méthode se trouve. Les types d objets primitifs Les types primitifs n étant pas des sous-types d Object, ils ne peuvent pas être utilisés là où on attend un Object (car violation du principe de substitution). On peut résoudre cela grâce aux types d objets primitifs (les wrapper types) : pour chaque type primitif il existe un type d objet correspondant qui «emballe» sa valeur dans un objet et le mettra donc dans le heap et non le stack. Integer pour int, Character pour char, etc Chaque type d objet primitif fournit un constructeur permettant d emballer la valeur dans un objet. Par ex : public Integer(int x); et à l inverse chaque type d objet primitif fournit une méthode renvoyant la valeur contenue dans l objet. Par ex : public int intvalue(); On trouve également d autres méthodes, par exemple celle qui construit un objet à partir de la lecture d un String : int n = Integer.parseInt(s);si s pointe vers le String 1024, n prendra la valeur Vector Dans java.util, sert à représenter des tableaux d objets de tailles variables. De plus ces objets peuvent être de types différents dans le même vector. Sa longueur est donnée par int size(); Ex : Vector v = new Vector(); add(object o); get(int i); Vector set (int i, Object o); Vector remove(int i); Ne pas oublier de faire un cast lors du get vers un String. 19

20 Chapitre 3 : Abstraction procédurale Bien que Java soit un langage POO, nous pouvons aussi faire de la programmation impérative (procédurale) classique. On va juste revoir quelques principes et les adapter à Java. Rappel : abstraction par spécification spécification qui suffit à comprendre le quoi d une méthode, peut importe le comment. A une spécification peut correspondre plusieurs implémentation. Les choix d implémentation sont indépendants les uns des autres grâce à la spécif, on peut comprendre plus vite le rôle de la méthode, et l on peut introduire les concepts de localité et de modifiabilité. Localité : l implémentation d une abstraction peut être lue/écrite sans qu il n y ait besoin de consulter L implémentation d aucune autre abstraction. Permet l indépendance des activités des programmeurs. Modifiabilité : une abstraction peut être réimplémentée sans nécessiter la réimplémentation des parties de programme qui l utilisent (pour peu que l abstraction (la spécification) ne doive pas changer). Par exemple pour améliorer les performances : remplacer un tri à bulle par un tri rapide. Cela permet de ne devoir réimplémenter que les parties où la performance est insuffisante (approche itérative). Les spécifications Les abstractions sont décrites à l aide des spécifications, celles-ci sont écrit sont écrites dans un langage formel ou informel. La spécification d une méthode comprend : sa signature (header) (information syntaxique qui décrit la forme mais pas ce que fait la méthode, ne décris pas son comportement). une description des effets (comportement) de celle-ci (information sémantique). Canevas de spécifications : type_de_retour nomproc (...) { // REQUIRES : contraintes sur l utilisation de la méthode (précondition) // MODIFIES : liste des inputs modifiés par la méthode // EFFECTS : définition du comportement (postcondition) [seule cette clause est obligatoire] } Les 3 clauses ont pour but de décrire les relations qui existent entre les inputs et les outputs de la méthode. Les inputs : - explicites : les paramètres repris dans la signature. - implicites : fichiers, sorties/entrées standard (System.out, System.in). REQUIRES définit les conditions sous lesquelles la méthode (ou du moins l abstraction) est définie. Elle n est utile que si la méthode est partielle et définit les classes d inputs pour lesquels son comportement est défini. Si la méthode est totale, REQUIRES n est pas nécessaire car son comportement est défini pour tout les inputs respectant la signature. = préconditions 20

21 MODIFIES donne les noms des inputs, explicites et implicites, qui sont modifiés par la méthode. Si la clause n est pas vide (i.e., si des inputs sont modifiés), on dira que la méthode a des effets de bord (side effects). EFFECTS définit les effets de la méthode pour tous les inputs n ayant pas été éliminés par la clause REQUIRES. EFFECTS indique : - quels sont les outputs produits. - quelles sont les modifications apportées aux inputs figurant dans la clause MODIFIES. EFFECTS n indique rien de ce qui se passe lorsque la clause REQUIRES n est pas satisfaite, cela reste indéfini. = postconditions Méthode en Java En Java, on programme les méthodes en tant que méthodes statiques de classes. Pour appeler une telle méthode, il faut connaître la classe (statique) dans laquelle elle se trouve mais pas l objet (dynamique). Une méthode statique se comporte de la même façon quel que soit l objet sur laquelle elle est exécutée. Souvent, les méthodes statiques sont regroupées dans des classes statiques i.e. qui n admettent aucune instance (même via leurs sous-classes). Les méthodes statiques sont parfois appelées des méthodes standalone (indépendantes) car leur comportement ne dépend pas d un contexte (objet) particulier. Ne pas oublier l OVERVIEW: description générale de l utilité de la classe. Petite convention pour lier les valeurs d inputs modifiée : - soit x le nom d un des paramètres formels. - x dénotera sa valeur avant l appel. - x_post (parfois aussi noté x") dénotera sa valeur après l appel. Quand la méthode retourne un nouvel objet, il faut le mettre dans la spécification. Note : l approche incrémentale et itérative : On écrit les spécifications des méthodes et les programmeurs se répartissent ensuite les tâches d implémentation, ils vont peut être ajouter des méthodes auxiliaires auxquels ils vont donner la visibilité private car ça ne regarde pas les autres programmeurs. Conception d abstractions procédurales Les méthodes doivent être modulaires (décomposer mais pas trop). Les méthodes doivent être simples (utilité bien définie, exprimable, indépendante du contexte d exécution). Les spécifications doivent être minimales (une spécification est plus minimale qu une autre si elle contient moins de contraintes, idée : avoir des spécifications contraignantes mais pas trop). Une spécification peut être sous-déterminée, c est à dire que pour certains inputs, il y a plusieurs outputs autorisés. Elle peut être voulue. Elle doit renvoyer le même output si on exécute deux fois le même input. 21

22 Méthodes totales vs méthodes partielles : Une méthode est totale ssi sa spécification donne un comportement bien défini pour chaque input vérifiant sa signature. Une méthode est partielle dans le cas contraire. Les méthodes partielles sont plus dangereuses que les méthodes totales : - Lorsqu on les appelle sans satisfaire la clause REQUIRES, aucune garantie n est fournie quant à leur comportement. - Elles peuvent boucler indéfiniment, «planter», renvoyer un output quelconque. - Sauf pour les plantages, il est possible qu on ne se rende compte du problème que longtemps après... Mais les méthodes partielles sont souvent plus efficaces que les totales. Il faut trouver le bon compromis entre efficacité (par ex pour contexte d utilisation restreint) et sûreté (par ex pour application très globale). On peut vérifier si la clause REQUIRES est bien respectée (si pas trop coûteux) et utiliser les exceptions. 22

23 Chapitre 4 : Les Exceptions Les méthodes partielles mènent à des programmes non robustes. Un programme robuste fournit un comportement raisonnable et bien défini même en présence d erreurs. Au pire, il fournit un message d erreur clair et s arrête. Pour améliorer la robustesse, on peut utiliser des méthodes totales, qui doivent prévenir l appelant lorsque les inputs reçus ne peuvent être traités correctement. Première solution : renvoyer une valeur spéciale du type de la valeur attendue. Retour d une valeur particulière du type de retour Cette manière de faire comporte divers inconvénients : - Risque pour l appelant de ne pas remarquer la survenance d un cas particulier. - Complication du code appelant. - Impossible si toutes les valeurs du type de retour sont déjà des résultats possibles dans le cas normal. Le mécanisme des exceptions résout ces 3 problèmes. Principe des exceptions Si la méthode appelée se termine normalement, elle renvoie une valeur du type de retour. Si un problème survient pendant son exécution une exception (objet d un type spécial) est renvoyée. A différentes catégories de terminaisons exceptionnelles correspondent différents types d exceptions. Les noms des types d exceptions doivent être choisis de manière à communiquer de l information sur la nature du problème. Dans la spécification Si une méthode est susceptible de renvoyer une exception, il faut indiquer le type d exception dans sa signature, à la fin, après une clause «throws». Au niveau de la signature, on exigera que l on renseigne tous les types des exceptions que la méthode peut renvoyer dans le cadre de son comportement «ordinaire» c est à dire sur des inputs admis par la clause REQUIRES. Au niveau de la clause EFFECTS, on exigera que soient clairement indiqués : - La cause de chaque type d exception. - Une description complète des effets dans chacun des cas. En particulier, les inputs apparaissant dans la clause MODIFIES (modifiés si exception? comment?). Si aucun comportement (normal ou d exception) n est prévu pour une combinaison d inputs donnée, celle-ci doit être exclue par la clause REQUIRES. Le comportement dans tous les autres cas doit être clairement spécifié dans EFFECTS. Les types d exceptions Les types d exceptions sont des sous-types d Exception ou bien de RuntimeException. La plupart des types d exceptions prédéfinis sont de type unchecked. Les exceptions de type unchecked sont des sous-types de RuntimException, les checked sont directement sous-type de Exception. Deux différences entre les unchecked et les checked exceptions : 23

24 - Si une méthode renvoie une exception vérifiée (checked) il faut que celle-ci figure dans sa signature. - Si une partie de programme appelle une méthode qui peut renvoyer une exception vérifiée, il faut que cette partie de programme traite explicitement le cas d exception. Dans le cours, on exige que toutes les exceptions (vérifiées ou non) soient listées dans la clause throws des méthodes. Définition d exceptions On définit un nouveau type d exception vérifiée en sous-typant Exception. On définit un nouveau type d exception non vérifiée en sous-typant RuntimeException. Définir de nouvelles classes d exception est très simple : deux constructeurs dont le code est hérité. Création d exceptions On peut créer une nouvelle instance de NewKindOfException (pour la renvoyer par la suite) d une des deux manières suivantes : - Exception e1 = new NewKindOfException( origine de l exception ); - Exception e2 = new NewKindOfException(); On peut consulter le String contenu dans l exception via la méthode tostring. Les nouveaux types d exceptions créés par l utilisateur sont de préférence à mettre dans un package regroupant tout les types d exceptions du programme, car cela permet leur réutilisation. Il est conseillé d écrire le nom d un type d exception avec à la fin «Exception». Renvoi d exceptions On renvoie une exception à l aide de throw, avec en paramètre du nom du type de l exception la source de l exception, et idéalement le nom de la méthode qui l a générée. Gestions d exceptions : try{} et catch{} Lorsqu une méthode appelée renvoie une exception, il y a deux méthodes pour l appelant pour la gérer : - Utiliser un try{} catch{} - Le code ne gère pas l exception et la propage à son tour à la méthode qui l appelle. J ai déjà parlé du try{} catch{} dans la première partie du résumé, j ai cependant deux remarques à ajouter : - Un catch convient si le type effectif de l exception est un sous-type du type d exception de la clause. L argument de la clause appelée (e1, e2,...) contient alors une référence vers l exception interceptée. - Le bloc suivant le mot-clé finally est toujours exécuté, et en toujours en dernier lieu. (catch et finally sont optionnels). Rappel : les try et catch peuvent être imbriqués. La propagation Si l exécution d une instruction dans le corps d une méthode P génère une exception qui n est pas récupérée par un catch dans P, alors Java renvoie l exception au code qui appelle P. Il faut toutefois qu une des deux conditions ci-dessous soit vérifiée: - Le type de l exception ou un de ses super-types apparaît dans la signature (clause throws) de P. - Ou bien l exception est de type non vérifiée. 24

25 Dans le code qui appelle P, le même processus s applique et ainsi de suite. La propagation d une exception se poursuit donc de méthode appelée à méthode appelante, jusqu à rencontrer une clause catch qui convienne. Si une telle clause ne peut être trouvée, l exception est propagée jusqu à l environnement d exécution Java qui signale alors une erreur. (Attention, erreur et exception sont deux choses différentes). Remarque : il faut faire attention aux exceptions non vérifiées, c est au programmeur de vérifier qu elle sont dans la signature des méthodes (ce qui est important pour l utilisateur de la méthode, pour connaître les comportements probables de celle-ci), de plus, puisque chaque méthode est susceptible de renvoyer une exception non vérifiées, en trouver la source est compliqué (pour être sûr de l origine de l exception, il faut réduire la portée du try). Programmer avec les exceptions Lorsqu une méthode est susceptible de recevoir une exception du code qu elle appelle, il faut faire en choix entre : - La transmettre au code appelant cette méthode. - La masquer au code appelant cette méthode. Il y a deux manières de transmettre une exception au code appelant : - Propagation implicite de l exception reçue (propagation). (limité car c est le même type d exception qui est renvoyé) - Renvoi explicite d une exception via un throw (permet de renvoyer une exception d un autre type que celle reçue et donc de fournir au code appelant un feedback du bon niveau d abstraction). Quand utiliser des exceptions? - Pour permettre d éliminer le REQUIRES (on la maintiendra si plus efficace ou contexte d utilisation restreint). - Pour éviter d encoder une info singulière dans un résultat ordinaire. Des exceptions vérifiées ou non? Les exceptions non vérifiées n étant pas listées obligatoirement dans la clause throws, il peut y avoir gestion de celle-ci par erreur. Les exceptions vérifiées peuvent emmener à une complication inutile du code du programme (par ex écrire le code qui gère l exception même si on est sûr qu elle ne surviendra pas). On utilisera donc des exceptions non vérifiées seulement quand on s attend à ce que le code appelant ne fasse pas survenir d exception (si manière facile d éviter sa survenance, ou si local), sinon, on utilisera des vérifiées. On ne peut cependant pas garantir à 100% que tout fonctionnera bien utiliser les exceptions et laisser faire le code de plus haut niveau (ex : restart). Pour tous les cas où il apparaît qu une hypothèse faite par le programme n est pas vérifiée, on générera FailureException (non vérifiée). Utilisation typiques : - Violation du REQUIRES (si pas trop coûteux à vérifier). - Survenance d une exception qui ne devait pas se produire. On ne renseignera pas FailureException ni dans la signature des méthodes, ni dans la clause EFFECTS, car son utilisation sera réservée aux situations où les choses ne se passent pas comme spécifiées! 25

26 Chapitre 5 : Abstraction de données Principe Objectif de l abstraction de données : s abstraire du format (ou représentation) et de l interprétation des données. Moyen: définition d opérations permettant l accès aux données des objets. Avantages : Indépendance du code utilisateur par rapport à l implémentation des types de données. Reporter le choix des formats de données jusqu au moment où on en connaîtra mieux les usages (efficacité). Reporter l implémentation des opérations d accès aux données (efficacité). Accélérer la maintenance (corrective ou additive). La spécification Comme pour les méthodes, la signification d un type de données doit être fournie par sa Spécification. On définit un nouveau type au moyen : - D une classe (ou d une interface). - De méthodes d instance (non static) qui permettent l accès aux données d un objet. - De constructeurs qui permettent de créer et d initialiser des objets. Chacun de ces éléments devra être spécifié. Exemple : visibilité class nomtd { // OVERVIEW: brève description du comportement // des objets du type, y compris mutabilité // constructeurs // specs des constructeurs // méthodes // specs des méthodes } Les principes restent identiques à ce qu on a vu pour les abstractions procédurales : - Utilisation massive de l abstraction par paramétrisation et par spécification. - Les spécifications définissent de nouveaux concepts en termes de concepts connus (autres abstractions définies dans le programme, abstractions mathématiques ou concepts du domaine). - Les spécifications seront placées en commentaire dans le code. Différences : - Les méthodes (non static!) et les constructeurs sont relatifs aux objets plutôt qu aux classes. - Pour référencer l objet dans le corps d une méthode, d un constructeur ou dans leur spécification, on utilise le paramètre implicite this (désigne l objet courant). N oublions pas que le(s) constructeur(s) portent le même nom que celui de la classe! On ne mentionne pas this dans le MODIFIES d un constructeur. Les mutateurs (mutators) modifient this (utilisation de this_post dans la spécification) et les observateurs (observers) ne font que fournir des informations sur this. Les types immutables n ont pas de mutators (= méthode dans laquelle this est modifié). 26

27 L implémentation Pour utiliser un type il faut uniquement connaître sa spécification. Dans une classe représentant un type, tout ce qui n est pas dans sa spécification est son implémentation. Pour écrire l implémentation d un type, il faut : choisir une représentation pour les instances de ce type. implémenter les constructeurs qui initialisent la représentation d une instance. implémenter les méthodes qui modifient ou utilisent la représentation d une instance. Une représentation (ou rep) consiste en un certain nombre de variables d instance (non static) de la classe implémentant le type et doit permettre d implémenter de manière raisonnablement simple et efficace les méthodes et constructeurs prévus par la spécification. Les variables d instance sont ainsi nommées car, à tout moment de l exécution, elles existent en autant d exemplaires qu il existe d instances de la classe dans le heap (les variables d instances sont stockées dans le heap). Rem: dans de rares cas, on a besoin de variables static pour implémenter un type de données. Très souvent, une représentation n influence pas de la même manière la simplicité et l efficacité de toutes les méthodes. (certaines représentation rendent certaines méthodes du type plus efficace, mais rend d autres moins efficace). Seuls les méthodes et constructeurs de la spécification doivent avoir accès à la représentation. Les variables d instance seront donc déclarées private (sauf exception des «records»), car en interdisant aux autres classes l accès aux variables d instance (encapsulation), on garantit l indépendance des premières par rapport aux changements de représentation. Rappel : lorsque l on fait un throw, on sort automatiquement du bloc d instructions en cours. Rem : this.v et this.m( ) servent respectivement à accéder à la variable v et à invoquer la méthode m( ) de/sur l objet courant. this ne doit être utilisé que quand il y a ambiguïté. Rem2 : pour la classe Integer, equals renvoie true ssi : - Les deux objets sont tous deux des Integer. - S ils contiennent la même valeur d entier. Rappel : les méthodes d une classe où une variable d instance private a été définie peuvent accéder à cette variable d instance. Les méthodes equals, similar, clone et tostring equals, clone et tostring sont implémentée par le type prédéfini Object. Ces implémentations sont donc héritées lors de la création d un nouveau type. Cependant, ces implémentations peuvent ne pas convenir à notre type, et il faut donc les overrider, les redéfinir par une implémentation qui convient Equals : Représente l équivalence comportementale de deux objets. Spécification standard d equals : boolean equals (Object o). 2 objets sont equals si aucune séquence d accès à leurs méthodes ne permet de les distinguer. 27

28 - Un objet mutable n est equal qu avec lui-même càd que equals et == doivent fournir le même résultat l implémentation par défaut convient. - 2 objets immutables sont equals s ils ont le même état (moins restrictif) il faut réimplémenter equals. Similar : Similarité = notion plus faible que l égalité. Deux objets sont similaires s il n est pas possible de les distinguer en invoquant leurs observateurs (méthodes qui ne font que fournir des infos sur l objet sans le modifier). La méthode similar n est pas prédéfinie, il faut donc l implémenter soi-même. Clone : Spécification standard de clone : Object clone(). Clone crée une copie d un objet qui a le même état que celui-ci. L implémentation par défaut fournie par Object crée un nouvel objet de même type (run-time) et assigne à ses variables d instances les mêmes valeurs que celles de l objet d origine. Peut ne pas convenir pour les types mutables car elle peut conduire à des partages de références non désirés. Convient pour les types immutables. Pour réutiliser l implémentation par défaut il faut ajouter «implements Cloneable» à la signature classe. Pour réimplémenter clone : - Ajouter implements Cloneable à la classe. - Fournir une nouvelle implémentation de clone. Si aucune des deux options n est choisie, la classe ne permet pas de cloner des objets (et si on essaye quand même bah, ça renvoie une CloneNoSupportedException). La spécification de clone est standard => pas besoin de la spécifier. Bien que renvoyant un objet de même type (runtime) que celui sur lequel elle est invoquée, clone doit conserver la signature de la méthode d origine: Object clone(). Les appels nécessitent donc l utilisation de casts. ToString : Selon sa spécification standard, tostring renvoie un String représentant l état courant de l objet ainsi qu une indication de son type. L implémentation par défaut de tostring renvoie le nom du type de l objet suivi d un hashcode. Il est donc souvent souhaitable de réimplémenter tostring. tostring ne doit pas être spécifié non plus. Aides à la compréhension et à la vérification de l implémentation Outre les spécifications, nous allons commenter le code à l aide de deux informations supplémentaires : - La fonction d abstraction. - L invariant de représentation. Ces deux éléments documentent les hypothèses qui ont conduit à l implémentation telle qu elle est et qui doivent être préservées si l implémentation évolue. La fonction d abstraction (FA) Toute implémentation d une abstraction de données doit définir comment les objets du type sont représentés 28

29 (càd encodés dans la rep). La relation entre la rep et les objets abstraits peut être rendue explicite par la définition d une fonction d abstraction. Définition : FA: C A, où - C (domaine de la fonction) est l ensemble des états concrets possibles des objets de la classe. - A (co-domaine de la fonction ou range) est l ensemble des états abstraits possibles des objets de la classe. - c C FA(c)=a t.q. a A et a est l objet abstrait représenté par c. La fonction d abstraction est généralement «manyto-one», car l abstraction est essentiellement l oubli d un certain nombre de détails. La fonction d abstraction est essentielle en ce qu elle définit la signification de la représentation. A est décrit sous forme de commentaire dans l OVERVIEW. Ex : // Un IntSet typique est {x1,...,xn} où x1,...,xn sont des entiers. NB : ça reste informel mais généralement suffisant. C est décrit par les variables d instance de la classe. Il reste à décrire la fonction proprement dite, par ex : // La fonction d abstraction est FA(c) = {c.els[i].intvalue 0 i < c.els.size} On peut simplifier les notations tant qu il n y a pas d ambiguïté. L invariant de représentation (IR) La vérification de type de Java vérifie que chaque appel à une méthode ou constructeur d un objet est bien effectué sur une instance de la classe. Toutes les instances possibles de la classe ne sont cependant pas toujours des instances légitimes du type abstrait. Un invariant de représentation est une propriété que toutes les instances légitimes d un type doivent satisfaire. Par ex, pour IntSet, l invariant de rep est : //c.els différent de null && tous les éléments de c.els sont des Integer //&& il n y a pas de doublons dans c.els Expliciter l IR permet au programmeur chargé d implémenter ou de ré-implémenter des méthodes et constructeurs de la classe de savoir quelles hypothèses il peut faire sur la rep et quelles hypothèses il doit conserver. Si on change la rep, il faut redéfinir la FA et l IR, et réimplémenter les méthodes, mais leurs spécifications et le code appelant restent identiques. L implémentation de la FA et de l IR On indiquera toujours la FA et l IR en commentaire de chaque nouveau type. Il est également possible de les implémenter à l aide de méthodes dédiées, par ex la FA est implémentée simplement par la méthode tostring. On appelle repok la méthode qui vérifie l IR. La spécification standard de la repok est : public boolean repok() { // EFFECTS: renvoie true si l IR est satisfait // pour this; sinon, renvoie false } Elle doit être fournie pour chaque type, mais sa spécification ne doit pas être fournie (IR étant de toute façon indiqué dans l overview). 29

30 tostring et repok sont utilisées pour aider à détecter des erreurs (tostring est aussi utilisée pour les sorties). Il y a 2 manières d utiliser repok pour détecter des erreurs : - A partir de l extérieur de la classe testée: par des programmes de test (doù la visibilité public)(uniquement en phase de debugging). - De l intérieur : dans les méthodes et constructeurs du type. (invoquer repok sur les objets nouvellement créés (ou dont on vient de modifier la rep, et ce juste avant le return). (On renvoie une exception si repok renvoie false. On ne conserve l appel en production que s il n est pas trop coûteux). Remarques sur la FA et l IR L IR ne doit pas être vrai à tout moment : Pendant qu une méthode modifie la rep, l IR est généralement violé. Il ne doit être vrai qu à la sortie et à l entrée des méthodes du type (entre les appels). (rem : Il est aussi vrai à tout moment pendant l exécution des méthodes qui ne modifient pas la rep (les observateurs)). Il existe un lien entre la FA et l IR : - La FA n est pertinente que pour les états de la rep qui vérifient l IR. - La FA ne doit pas être définie pour les autres états (ceux qui violent la rep). Ne pas exposer la rep Objectif : on veut être capable de raisonner localement sur une classe càd que le code de cette seule classe doit nous permettre de vérifier qu elle est correcte. Le raisonnement local n est possible que si la rep ne peut être modifiée que par les méthodes de la classe. - les variables d instance de la rep doivent être private. - Mais il y a d autres manières d exposer la rep aux modifications extérieures... Par exemple si l on renvoie la référence à un objet de la classe au code appelant qui serait extérieur à cette classe. Si cet objet est de type mutable, grave erreur. Dans ce cas, renvoyer une copie. Types mutables VS types immutables La mutabilité (ou l immutabilité) est une propriété du type (c-à-d de l abstraction) et non de L implémentation (mais l implémentation doit la respecter, bien évidemment!). Habituellement, un type doit être immutable si, naturellement, ses objets ne changent pas de valeur. Habituellement, un type doit être mutable si ces objets représentent des entités du monde réel dont L état évolue avec le temps. Les types destinés au stockage (tableaux, ensembles,...) sont généralement aussi mutables (dépend du compromis entre efficacité et sécurité, ils seront immutables si on veut plus de sécurité). Les 4 types d opérations 1. Les Créateurs (creators): créent de nouvelles instances du type «à partir de rien» («from scratch») càd sans nécessiter aucune instance de ce même type en entrée. - Tous les créateurs sont des constructeurs. 30

31 - La plupart des constructeurs sont des créateurs (si un constructeur a pour paramètre un objet du type qu il doit créer, ce n est pas un créateur). 2. Les Producteurs (producers) : prennent en entrée un objet de leur type et créent un autre objet de leur type. - Ce sont soit des constructeurs, soit des méthodes. 3. Les Mu(ta)teurs (mutators) : modifient les objets de leur type. - Seuls les types mutables ont des mutateurs. Ils jouent le même rôle dans les types mutables que les producteurs dans les types immutables. Les types mutables peuvent avoir tant des mutateurs que des producteurs. 4. Les Observateurs (observers, parfois aussi accessors) : prennent en entrée des objets de leur type et retournent des objets d autres types. Ils sont utilisés pour obtenir de l information sur les objets. Remarques : - Les noms des observateurs commencent souvent par get mais il est parfois plus naturel d utiliser un autre nom. - Les noms des mutateurs commencent souvent par set. - Les observateurs sont parfois combinés avec des mutateurs ou producteurs. - Les créateurs sont généralement capables de produire certains objets de la classe mais pas tous. - Les autres objets sont produits par les producteurs ou les mutateurs. Adéquation de types Un type est adéquat s il fournit un ensemble d opérations permettant aux utilisateurs (programmes appelants) de réaliser tout ce qu ils désirent sur les objets de manière raisonnablement facile et efficace. 3 bons plans pour fournir un type adéquat : - Avoir des opérations d au moins 3 catégories parmi les 4 : créateurs, observateurs et mutateurs (si mutable). créateurs, observateurs et producteurs (si immutable). - Permettre un peuplement complet du type (via les créateurs et les mutateurs/producteurs). - Envisager le contexte d utilisation : suffisamment d opérations mais pas trop, sinon le type devient trop complexe et trop de code devient dépendant de l implémentation. Raisonnement Démonstration de la correction d une méthode : démontrer que si la précondition (REQUIRES) est vérifiée au moment de l appel, alors la postcondition (EFFECTS) est vérifiée au moment du retour de l appel. Pour les abstractions de données, c est plus compliqué car il faut considérer toute la classe. Il y a 3 choses à vérifier : - L implémentation préserve l IR? - On démontre, séparément pour chaque opération, que si l IR est respecté à l entrée, il est respecté à la sortie. - Par induction sur le nombre d invocations de méthodes (data type induction). - L implémentation préserve la spécification? - On démontre séparément que chaque implémentation d opération (travaillant sur la rep) satisfait sa spécification (exprimée en termes d objets abstraits). 31

32 - On utilise l IR ainsi que FA pour lier les objets concrets de la rep aux objets abstraits. - La spécification préserve les invariants abstraits? - Par induction sur le nombre d invocations de méthodes (data type induction). NB : les observateurs peuvent être ignorés pour la preuve des invariants abstraits. Résumé du chapitre 5 (tel que dans le cours) - Classes d abstraction procédurales (= assemblages de méthodes, opérations ajoutées à la MV) : voir chapitre 3 + cours de programmation de base. - Classes d abstractions de données (= nouveau types de données ajoutés à la MV) : o Doivent spécifier une OVERVIEW : - Description générale. - Mutable ou immutable. - FA (via un exemple type). o o o o Doivent spécifier et implémenter (REQUIRES, MODIFIES et EFFECTS) pour chaque créateur, mutateur, producteur et observateur. Doivent implémenter FA (tostring). Doivent implémenter IR (repok). Doivent appeler repok dans les constructeurs, producteurs et mutateurs qui accèdent directement à la rep. - Renvoyer une FailureException si échec. - Désactiver si trop coûteux (typiquement on garde pendant les tests, mais pas en production). o Selon la catégorie : Mutable - pour fournir clone, doivent généralement la réimplémenter. - ne doivent pas réimplémenter equals. Immutable - peuvent fournir clone en réutilisant la méthode par défaut - doivent réimplémenter equals... o o Ne doivent pas exposer la rep - Toutes les variables d instance doivent être maintenues private. - Eviter le partage de références via une mauvaise implémentation des méthodes. Doivent fournir un ensemble d opérations adéquat. 32

33 Chapitre 6 : Abstraction de l Itération Objectif Besoin récurrent dans les types de données destinés au stockage d éléments (càd représentant des collections) : pour chaque élément de la collection faire action. 2 variantes: - Itération complète: parcourir toute la collection. - Itération partielle: s arrêter à un moment donné. Problème : le type collection ne fournit pas toujours les méthodes permettant de faire cela de manière facile et efficace (problème d adéquation du type). L itérateur est une solution générique (design pattern) au problème de l itération sur des collections. Cette solution est facile, efficace, préserve l abstraction des données, n expose pas la rep. Un itérateur est une méthode qui fournit une manière de générer des éléments d une collection à la demande. Le schéma des itérations devient : pour chaque élément i produit par l itérateur A faire action sur i. Avantages : le parcours de la rep est encapsulé dans l itérateur. Il peut être ré-implémenté sans affecter le code des itérations externes. Il y a génération à la demande pas de gaspillage de ressources. Les itérateurs en Java Ils sont une généralisation des boucles for, mais permettent aussi l itération sur les collections nonindexées. Il n y a pas de support direct aux itérateurs génériques avant java 5 mais il existe un super-type Iterator (dans java.util). Voici son interface : public interface Iterator { public boolean hasnext(); // EFFECTS: renvoie true s il reste des éléments // à fournir dans la collection public Object next() throws NoSuchElementException; // MODIFIES: this // EFFECTS: s il reste des éléments à fournir, // retourne l élément suivant et modifie l état de // this en conséquence; sinon, retourne une // NoSuchElementException } Un itérateur est une méthode de la collection ou une méthode à part qui retourne un générateur. Un générateur est une instance d un sous-type de Iterator. Iterator est une interface, c-à-d un super-type sans implémentation. Tout générateur doit fournir une implémentation respectant l interface Iterator. Essentiellement, un générateur doit implémenter hasnext() et next(). NoSuchElementException est prédéfinie et non vérifiée. Rem : les générateurs sont utilisés typiquement dans des boucles while. Des casts sont souvent nécessaires car retour d Objects. Dans ce cas, NoSuchElementException est inutile car présence de l élément testée par hasnext. 33

34 La spécification d un itérateur La spécification du type Iterator explique le comportement de next() et hasnext() de manière générique. La spécification de chaque itérateur doit préciser : comment est produit le générateur (d après les éventuels paramètres de l itérateur) et le comportement du générateur (y compris le type des objets qu il génère). NB : le générateur n a pas de spécification propre, elle est déduite de celle d Iterator et de celle de l itérateur. Rem : Un type peut avoir plusieurs itérateurs. Habituellement, ni l itérateur, ni le générateur ne modifient this. Dans les rares cas où c est nécessaire, cela doit être documenté dans la spécification de l itérateur. Il n y a pas que les méthodes qui peuvent être des itérateurs, une abstraction procédurale (méthode standalone) peut l être aussi. Implémentation d itérateur Il s agit : - D implémenter la méthode (ou méthode) itérateur. Ex : public Iterator terms() {return new PolyGen(this);} - De définir et d implémenter une classe pour le générateur (sous-type de Iterator). Ex : la classe Polygen. Les générateurs sont implémentés sous forme d inner class du type de la collection sur laquelle il itèrent. Inner class = classe décrite et implémentée entièrement à l intérieur d une autre et pouvant être nommée seulement à partir de celle-ci. Donc classe écrite dans une autre, private static et implements Iterator. 34

35 Chapitre 7 : Hiérarchies de types Définir des familles de types composées d un super-type et de sous-types représentant des hiérarchies du monde réel (mammifères, polygones,...) ou propres aux programmes (BufferedReader spécialisant Reader, NullPointerException spécialisant Exception,...). Une famille peut avoir un ou plusieurs niveaux, certaines familles servent juste à fournir de multiples implémentations du super-type. Mais les sous-types peuvent aussi étendre le comportement du super-type en ajoutant des méthodes. Le principe de substitution maintient la cohérence entre comportement du super- et des sous-types. L intérêt des hiérarchies de types repose sur la flexibilité de l affectation et du dispatching. Définition d une hiérarchie de types On commence par définir le super-type, qui peut être incomplet (ex: manque des constructeurs, ne fournit pas d implémentations de certaines méthodes,...). Les sous-types sont définis relativement au supertype, les parties du sous-type qui sont conservées ne doivent pas être précisées (réutilisation implicite), on n indique que ce qui est nouveau (ex: constructeurs, méthodes supplémentaires, (re-)implémentation de méthodes du super-type). Un super-type est défini par une classe ou une interface qui fournit sa spécification, et si c est une classe, éventuellement une implémentation partielle ou complète. Une sous-classe hérite de la définition /implémentation d une classe (extends) et de 0,1 ou plusieurs interfaces (implements). Java distingue : - Les classes concrètes: qui fournissent une implémentation complète d un type peuvent être instanciées (et donc exécutées). - Les classes abstraites: qui fournissent au plus une implémentation partielle d un type ne peuvent être instanciées (ni exécutées). peuvent avoir des méthodes abstraites (sans implémentation). - Pour le code appelant, cette distinction n a pas d importance, sauf pour les appels aux constructeurs. Une sous-classe déclare sa super-classe par une clause extends dans son en-tête, cela lui confère automatiquement les méthodes de sa super-classe (avec les mêmes signatures), mais elle peut fournir des méthodes supplémentaires. Rappel : absence d extends = extends Object implicite. A part Object, toute classe a une et une seule superclasse directe (mais éventuellement plusieurs super-types directs). Une classe concrète doit fournir une implémentation des constructeurs et éventuellement des méthodes supplémentaires, elle doit aussi fournir une implémentation des méthodes abstraites de sa super-classe. Elle peut réimplémenter (overriding) les méthodes concrètes (non abstract) de sa super-classe. Elle hérite des méthodes concrètes non-réimplémentées ainsi que des méthodes final de sa super-classe. NB : une méthode est déclarée final si on veut en interdire la ré-implémentation (pas utilisé dans le cours). La rep d un objet instanciant une sous-classe est composée : - Des variables d instance déclarées dans la super-classe (rep héritée). - + des variables d instance déclarées dans la sous-classe. Question de conception : comment le code d une sous-classes va-t-il accéder à sa rep héritée (généralement private)? 35

36 - indirectement, càd via les méthodes public de la superclasse? Idéal mais peut être inefficace ou peu pratique. - directement? Dans ce cas, la rep de la super-classe peut être déclarée protected, donc accessible aux sous-classes mais aussi au package, attention, la rep est alors exposée! Rappel : on utilise super pour appeler une méthode d une superclasse. En général, on commence l implémentation du (des) constructeur d une sousclasse par super() pour hériter des instructions du constructeur de la superclasse. La FA d une sous-classe est typiquement définie en utilisant la FA de la super-classe. L IR d une sous-classe (I_sub) ne doit inclure la vérification de l IR de sa super-classe (I_super) que si la super-classe possède des variables protected. Cependant, dans tous les cas, repok de la sous-classe doit toujours faire appel à repok de la super-classe. Classe abstraite Une classe abstraite ne fournit qu une implémentation partielle d un type, elle peut avoir des variables d instances (et dans ce cas,aussi des constructeurs). Ces constructeurs ne peuvent cependant pas être appelés de l extérieur, mais uniquement par des sous-classes pour initialiser la rep héritée. Une classe abstraite contient typiquement des méthodes normales et des méthodes abstraites. Les méthodes normales font cependant souvent usage de méthodes abstraites (template pattern). Plus l implémentation est haute dans la hiérarchie des types, plus la réutilisation est grande, plus les sousclasses sont simples et plus la correction est facile à établir. Rem : l overriding ne fonctionne que pour les méthodes et pas pour les variables. On utilise les classes abstraites lorsque, par exemple, une rep ne nous convient plus, on aimerait en faire une autre pour une sous classe, or, on ne peut pas overrider les variables, et on va avoir deux rep dans la même classe pitoyable. Donc, on va faire de la superclasse une classe abstraite, sans rep. Cette classe abstraite, dépourvue de rep propre, n aura donc pas de FA, d IR ni de méthode repok. Il faut éviter l utilisation de protected pour les membres de classes (variables d instances et méthodes) pour 2 raisons : - Si les membres demeurent private, la super-classe peut être ré-implémentée sans affecter les sousclasses. - protected rend les membres accessibles par tout le package. Les membres protected sont introduits pour permettre l implémentation efficace des sous-classes. Il y a 2 alternatives : - Variables protected. - Variables private et accès via méthodes protected. OK si cela permet à la super-classe de maintenir un invariant intéressant. Interfaces Une classe (d abstraction de données) sert à définir un type et à en donner une implémentation complète ou partielle. Une interface ne sert qu à définir un type, elle ne fournit pas d implémentation et elle ne contient que des méthodes à la fois publiques, non statiques et abstraites. 36

37 Ces 3 caractéristiques sont implicites pour les interfaces.on continuera, par convention, à expliciter le modificateur public. Exemple d interfaces : Iterator, Cloneable. Avantage principal : une classe peut implémenter un nombre quelconque d interfaces (alors qu elle ne peut étendre qu une seule super-classe). Les interfaces servent à fournir à une classe plusieurs super-types directs, elles simulent ce qu on appelle l héritage multiple. Une interface est implémentée par une ou plusieurs classes. Toute classe qui implémente une interface l indique dans son en-tête par la clause implements. L implémentation multiple est une manière de définir une forme restreinte de famille de types où tous les membres (les types) de la famille ont exactement les mêmes méthodes (sauf constructeurs) et le même comportement tel que défini par la spécification du type implémenté (l ancêtre commun). Celui-ci est soit une classe abstraite, soit une interface. L existence des sous-types est dans une large mesure invisible pour le code appelant (hormis lors de la création des instances). Des instances de différents sous-types coexistent à l exécution. Remarques : les sous-classes ne sont pas indépendantes les unes des autres (contrairement aux autres sousclasses vues jusqu ici). Lorsque l on divise un type en deux sous type, le code appelant ne distingue pas les deux types sauf à la création. Sémantique du sous-typage 3 règles doivent être respectées : - Règle des signatures : Le sous-type doit avoir toutes les méthodes du super-type et leurs signatures doivent être compatibles, cette règle est vérifiée par le compilateur Java. - Règle des méthodes : Les appels aux méthodes du sous-type doivent se comporter comme des appels aux méthodes du super-type, cela doit être vérifié par le programmeur. - Règle des propriétés : Le sous-type doit préserver toutes les propriétés qui sont vérifiées par le supertype. Cela doit être vérifié par le programmeur. Règle des signatures But : garantir que chaque appel type-correct au super-type est un appel type-correct au sous-type. Le compilateur garantit que le sous-type possède toutes les méthodes du super-type et que leurs signatures sont compatibles, càd qu elles sont identiques, sauf pour les exceptions: le sous-type doit renvoyer (throws) les mêmes ou moins de types d exceptions que le super-type logique: si l appel fonctionne en prévoyant la survenance des exceptions A,B et C, il marchera également si seules B et C sont possibles. La notion de compatibilité des signatures de Java est en fait plus exigeante que nécessaire, en effet, la règle des signatures identiques (hormis exceptions), exige que les types de retour soient identiques, or la méthode du sous-type pourrait se contenter de retourner un sous-type du type de retour de la méthode du super-type. (Ex avec Clone, il faut Object clone() ce qui implique en général un cast). Règle des méthodes But : permettre de raisonner sur la signification des appels en se bornant à la spécification du super-type même si c est le code d un sous-type qui est exécuté. Jusqu ici, toutes les méthodes de super-types réimplémentées par les sous-types vues au cours ont gardé la même spécification, c est la règle des méthodes vérifiée. 37

38 Lever une partie de l indéterminisme d une méthode au niveau du sous-type est fréquent et correct, mais toute re-spécification du sous-type n est pas sans danger... La règle des méthodes est : Règle des préconditions : un sous-type peut affaiblir la précondition : pré sup pré sub. Règles des postconditions : un sous-type peut renforcer la postcondition : pré sup && post sub post sup. Affaiblissement des préconditions : Idée : la méthode du sous-type demande moins de son appelant que la méthode du super-type, motivation: c est logique, puisque l appelant suppose qu il a à faire au super-type, alors son appel sera valable pour le sous-type aussi. Renforcement des postconditions : Idée : la méthode du sous-type fournit plus à son appelant que la méthode du super-type, motivation : c est logique, puisque l appelant suppose qu il a à faire au super-type, alors son appel lui fournira le résultat qu il attend (plus, éventuellement, un bonus qui ne l intéresse pas). Mais, pour ça, l appelant doit respecter la précondition (de la méthode du super-type, évidemment!), sinon la méthode peut faire n importe quoi. Règle des propriétés But : permettre de raisonner sur les objets comme s ils étaient des instances du super-type même si leur type effectif est plus spécifique. Attention : c est un raisonnement au niveau de l abstraction sur la spécification. Toutes les méthodes (celles du super-type + celles de tous les sous-types) doivent préserver ces propriétés. Typiquement (à indiquer dans l overview) : Invariants abstraits, Propriétés d évolution du type abstrait. A démontrer. Comment? Comme d habitude : - Par induction sur les types de données. - Montrer que les créateurs et producteurs établissent la propriété. - Montrer que les autres méthodes la préservent. Résumé de ce chapitre Le mécanisme d héritage fourni par Java a été utilisé pour définir des familles de types. Il y a 2 utilisations possibles : les implémentations multiples et les extensions du comportement. Avantages : - Les similarités et différences entre les types sont clairement identifiées, cela facilite la compréhension du programme. - Réutilisation : écrire du code dans le super-type qui fonctionne pour tous les sous-types. - Extensibilité : pour ajouter de nouvelles abstractions (soustypes) tout en réutilisant du code du super-type. (Avec l encapsulation on était prémunis contre les changements d implémentation seulement) Attention: ces avantages ne sont garantis que si on obéit au principe de substitution, qui étend l abstraction par spécification aux hiérarchies de types et qui est garant de la sémantique du sous-typage. 38