«Polymorphisme et Généricité en Java»

Transcription

1 Année Polytech Paris-Sud 4 ème année Département Informatique «Polymorphisme et Généricité en Java» Frédéric Voisin Département Informatique

2 Co-variance vs Contra-variance (rappel!) Soit Figures Id (X: Figures ) { dans Figures Dans Cercle on redéfinit la méthode Id en gardant son en-tête: Figures Cercle::Id (X: Figures ) { -- OK Pourrait-on lors d une redéfinition spécialiser/élargir le type des paramètres ou du résultat? Id (X: Cercle) return Figures is Id (X: Figures) return Cercle is... Id (X: FigureAbstraite) return Figures is Id (X: Figures) return FigureAbstraite is -- KO -- OK -- OK -- KO Co-variance pour le résultat (ex : clone() en Java) Contra-variance pour les paramètres (pas implémenté en Java, vu comme une surcharge) La généricité en Java 2

3 Polymorphisme paramétrique à la Ada (rappel) generic type Elem is private; type Table is array(integer range <>) of elem; with function "<="(E1,E2 : Elem) return boolean; procedure Tri(t: in out Table); tri générique... paramètres Idée? Pouvoir paramétrer une procédure ou un type par : des types, des procédures, des fonctions en précisant les «propriétés» attendues de ces paramètres (prototype, degré d'encapsulation,...) On doit instancier explicitement un composant générique pour «déduire» l'élément avec lequel on travaille réellement. procedure TriIntDecr is new Tri(Elem => integer, "<=" => ">=", Table => TableInt) ; La généricité en Java 3

4 La généricité à partir de Java 5.0 public class Paire<T1, T2> { // détail dans le prochain transparent protected T1 first; protected T2 second ; public Paire(T1 a, T2 b) { first = a; second = b; Paire<String, Integer> mapaire = new Paire<String, Integer>("a", 1); Paire<String, Integer> mapaire = new Paire<>("a", 1) ; // OK, Java 7! Contraintes possibles sur le paramètre de type : public class C <T extends T1 & I1 & I2> { C<A> monobj; // OK si A sous-classe de T1 et implémente I1 et I2 Au plus une classe, forcément en tête, et des interfaces arbitraires; Si seulement des interfaces, l'ordre importe (voir après)! La généricité en Java 4

5 Une classe générique simple public class Paire<T1, T2> { private T1 first ; private T2 second; public Paire() { first = null; second = null; public Paire(T1 a, T2 b) { first = a; second = b; public T1 first() { return first; public T2 second() { return second; public void setfirst(t1 val) { first = val; public void setsecond(t2 val) { second = val; etc Ici simple car il n'y a pas de contraintes sur T1 et T2. En pratique, moins simple à concevoir qu'on croit, si on veut qu'elle soit réellement réutilisable La généricité en Java 5

6 Autres éléments génériques Java 5.0 Interfaces génériques public interface Comparable<T> { public class C implements Comparable<C> { Méthodes génériques (ici supposées dans une classe Utilitaires) public static <T> T anyone(t[] tab) // version provisoire de l'en-tête public static <T extends Comparable<T>> T max(collection<t> c) String[] matable = { "Adieu", "monde", "cruel" ; Collection<String> l = Arrays.asList("Adieu", "monde", "cruel");//java 7! String s = Utilitaires.<String>anyOne(maTable); String s = Utilitaires.max(l); // <String>.max(...) Souvent le système peut déduire automatiquement le paramètre d'instantiation La généricité en Java 6

7 La généricité en Java : Principes de base Renforcer le typage statique et diminuer le besoin en transtypage explicite Compatibilité avec le code existant, d où sous-typage «osé» avec contrôle dynamique à l exécution Compatibilité avec la JVM La généricité est traitée uniquement à la compilation Pas de classe générique à l'exécution : la JVM reste non générique. Le compilateur convertit tous les génériques en non-génériques En effectuant au préalable les contrôles statiques En ajoutant silencieusement les transtypages nécessaires ; Paire<String, String> ps; ps.setfirst(e) ;... ; String s = ps.first(); À l exécution une seule version de la classe, basée sur le «type limitatif» du paramètre : les paramètres de type sont «effacés»! Les librairies ont été mises à jour pour être génériques. Différent donc du modèle Ada/C++ : Dynamiquement, il existe une unique version non générique de la classe «générique» La généricité en Java 7

8 Exemples d'effacement de type ArrayList<E> où E est une classe arbitraire : la version «effacée» est ArrayList<Object>! public class Paire<T1, T2> : T1 et T2 n'ont pas de contraintes. la version «effacée» est Paire i.e. Paire<Object, Object> public class C<T extends T1 & I1 & I2, > { la version «effacée» est C, i.e. C<T1>! public class Intervalle<T extends Comparable> { la version «effacée» est Intervalle, i.e. Intervalle<Comparable>! C++: Paire ou Paire<T1, T2> n aurait pas de sens à l exécution! Java : Paire est une classe standard Dynamiquement il existe une unique version non générique! Typage statique et transtypage font le reste. Paire p ; compile en Java, mais représente quoi? class ArrayList<E> implements List<E>, Cloneable { ArrayList ArrayList<Object> ArrayList<? > pas les mêmes règles de typage, pour compatibilité avec Java 4! La généricité en Java 8

9 Polymorphisme générique et par inclusion Figure Set Figure Cercle Set X Set Cercle Java 1.5 : comme C La généricité en Java 9

10 Polymorphisme générique et par inclusion (2) Syntaxe à la Java mais même problème dans tout langage avec héritage+généricité public class Set<Elem> { public Set() { public void insert(elem e){ etc ; par instantiation du paramètre, on peut obtenir les classes: Set<Figure> // définit void insert(figure e) { Set<Cercle> // définit void insert(cercle e) { static void teste(set<figure> s) { s.insert(new Rectangle()); // OK ou KO? teste(new Set<Cercle>()); // OK ou KO? Avec OK partout on obtient une absurdité => on doit dire KO quelque part! La généricité en Java 10

11 Polymorphisme générique et par inclusion (3) Figure Set Figure Cercle Set X Set Cercle Java 1.5? Comme en C++ Figure Cercle Set X Set Set Figure Java 1.5 : OK?! Set<Figure> et Set<Cercle> n existent pas dynamiquement mais Set existe! Set Cercle La généricité en Java 11

12 Le poids du passé... Java 5 : compatibilité délicate avec le code existant non générique ArrayList<Integer> a1 = new ArrayList<Integer>(); ArrayList a2 = new ArrayList(); // Java 1.4 ArrayList<Object> a3; a1 = a2; // OK? a3 = a1; // OK? a1 = (ArrayList<Integer>) a2; // OK? a2 = a1; // OK? a2.add("sad world"); Bien sûr, on n'écrira pas cela directement mais le problème se pose avec des méthodes écrites en Java4- dont la signature mentionne ArrayList. Pas de problème si on ne mélange jamais Java4- et Java La généricité en Java 12

13 Cas particuliers des tableaux Figure[] tf = new Figure[2]; Cercle[] tc = new Cercle[2]; Rectangle r = new Rectangle( ); Figure f ; tf[0] = r; // OK tf = tc; // OK en Java! tf[0] = r; tf[0] = f; // KO à l exécution(arraystoreexception) // KO possible à l exécution(arraystoreexception) Les tableaux doivent mémoriser dynamiquement le type d éléments stockés. Contrôle explicite à l'exécution et risque de levée d'exception! Était-ce une bonne idée d'autoriser tf = tc? La notion de tableaux est vue comme une opération covariante en Java! La généricité en Java 13

14 Quelques restrictions Pas de classe générique d exceptions. Pas de type primitif dans les instanciations : Paire<int, double> p; // KO : serait Paire<Object, Object> Paire<Integer, Double> p; // OK Inconvénient allégé par «boxing/unboxing» automatique! Perte de fiabilité des informations dynamiques de type ArrayList<Integer> ai = new ArrayList<Integer>(); ArrayList<String> as; ArrayList a = ai; // mélange avec du Java4- ArrayList<Integer> x = (ArrayList<Integer>) a; // OK? ArrayList<String> x = (ArrayList<String>) a; // OK? ArrayList<String> x = (ArrayList<String>) ai; // KO!! instanceof est interdit sur les classes paramétrées : dynamiquement, pas de différence entre Paire<String,String> et Paire<Integer,Integer> La généricité en Java 14

15 Quelques restrictions (suite) Pas de tableaux d'instantiation de génériques Paire<String, Integer>[] t = // KO pb avec l'effacement de types et la gestion de ArrayStoreException Pas d objet d un type paramètre public class Paire<T1, T2> { public static Paire<T1, T2> getfirst() { return new T1(...); // le new est dynamique : créerait quoi? Pas de variable de type générique dans les méthodes ou attributs static : public class Singleton<T> { static T theinst; // KO. static T getinst() { // KO. Ferait un drôle de Singleton après instantiation! La généricité en Java 15

16 Retour sur un exemple simple... public class Paire<T1, T2> { private T1 first; private T2 second; public Paire() { first = null; second = null; public Paire(T1 a, T2 b) { first = a; second = b; public T1 first() { return first; public T2 second() { return second; public void setfirst(t1 val) { first = val; public void setsecond(t2 val) { second = val; Que se passe-t-il avec l'effacement de type? La généricité en Java 16

17 Après effacement... Tout se passe comme si dans la JVM il y avait en fait: public class Paire { private Object first; private Object second; public Paire() { first = null; second = null; public Paire(Object a, Object b){ first=a; second=b; public Object first() { return first; public Object second() { return second; public void setfirst(object v) { first = v; public void setsecond(object v) { second = v; sauf que le compilateur ajoute contrôles et transtypages à votre code pour garantir le typage sûr La généricité en Java 17

18 Une utilisation de Paire static int teste(paire<integer, Integer> pi) { return pi.first() + pi.second() ; // Compile? static void t2(paire<integer, Integer> pi) { pi.second(); public static void main(string[] argv) { Paire<Integer> pi = new Paire<Integer, Integer>(1, 2); Paire p = pi ; // OK! teste(pi); pi.setsecond("coucou"); // KO à la compilation p.setsecond("coucou"); // OK ou KO? teste(pi); // OK ou KO? t2(pi) ; // OK ou KO? La «vraie» forme de setsecond à l'exécution est : public void setsecond(object val) { second = val; La généricité en Java 18

19 Une sous-classe de Paire public class PaireInteger extends Paire<Integer, Integer> { public setsecond(integer i) { // redéfinition ou pas? super.setsecond(2*i) ; A cause de l'effacement de types, il ne s'agit pas d'une redéfinition mais d'une surcharge (profils différents). Dans la JVM pour PaireInteger il y a deux méthodes setsecond : public void setsecond(object v) { héritée de Paire<Integer,Integer> public void setsecond(integer i) { locale! PaireInteger pi = new PaireInteger(); Paire p = pi ; OK? p.setsecond(1); Quelle méthode? System.out.println(pi.first() + pi.second()); OK? Bien sûr, si on ne passe jamais par Paire on ne se pose pas la question La généricité en Java 19

20 Méthodes «bridges» (1) But : Régler le problème lié à l'effacement de type et assurer la cohérence avec le polymorphisme... Pour rétablir le polymorphisme, le compilateur ajoute automatiquement une méthode («bridge») dans la classe PaireInteger qui redéfinit la version qu'on hériterait par défaut de la classe générique et fait le lien avec la méthode surchargée! public void setsecond(object v) { this.setsecond((integer) v) ; // Cast risqué ou pas? Méthode ajoutée automatiquement par le compilateur, non référençable par le programmeur (n existe que dans le bytecode, mais visible via introspection) La généricité en Java 20

21 Exercice : Méthodes «bridges» (2) public class C implements Comparable<C> { public int compareto(c arg) {...; public static int teste2(comparable c1, Comparable c2) { c1.compareto(c2); C c2 = new C(); Object o = c2; Comparable c1 = c2; // et non pas Comparable<C> c1 System.out.println(c1.compareTo(c2)); System.out.println(c1.compareTo(o)); System.out.println(c2.compareTo(c2)); System.out.println(c2.compareTo(o)); System.out.println(c2.compareTo(new Integer(1))); System.out.println(teste2(c1, c1)); System.out.println(teste2(c1, o)); System.out.println(teste2(c1, new Integer(1))); Et si on avait écrit : public class C implements Comparable? La généricité en Java 21

22 Exercice : Méthodes «bridges» (3) Même problème pour gérer la covariance du type de retour! public class A { public A f() { return new A(); public class B extends A { public B f() { // co-variance (Java 1.5) Redéfinition? Surcharge? B res1 = this.f(); // Boucle à l exécution: Normal. A res2 = super.f(); // OK, version A de f appelée B res3 = ((A) this).f(); // Compile pas: OK. A res4 = ((A) this).f(); // Compile mais exécute quoi? Génération automatique d une méthode bridge dans B équivalente à public A f() { return this.f(); Deux méthodes f() sans paramètre dans (la version JVM de) B: une à valeurs dans A, l'autre à valeurs dans B La généricité en Java 22

23 Écriture de méthodes/classes génériques La «non-compatibilité» entre instantiation et héritage complique l écriture de méthodes réutilisables static void dessinetout (Collection<Figure> c) { for(figure f: c) f.dessine(); // OK Collection<Cercle> ac = new ArrayList<>(); // Java 7.0 dessinetout(ac); // KO! dessinetout((collection<figure>) ac); // KO! Pourtant dessinetout ne met pas en danger le typage Quand on utilise les librairies génériques (Collection, Comparable, etc.), cela reste généralement transparent! Merci les concepteurs des bibliothèques! Attention à la spécification parfois surprenante des paramètres ;- Il faut des mécanismes pour différencier les cas «problématiques» La généricité en Java 23

24 Tentatives de solutions Retour à la version 4? Perte d'information statique = risque d'exceptions public static void dessine (Collection c) { for(object o: c) ((Figure) o).dessine() ; Passage par une procédure générique? public static <T extends Figure> void dessine (Collection<T> c) { for(figure f: c) f.dessine(); OK, mais artificiel : T ne sert à rien pour dessine Introduction de «joker» (wildcard) dans la description des paramètres ou du résultat pour mieux faire coexister instantiation et héritage! La généricité en Java 24

25 Types «Joker» Possibilité d avoir des types «joker» bornés inférieurement ou supérieurement : <? > correspond à «n importe quel type» <? extends Figure> n importe quel sous-type de Figure (inclus) <? super Figure> n importe quel super-type de Figure (inclus) Différentes usages/limitations associés à ces types joker Notions similaires en Scala, liées à covariance/contravariance La généricité en Java 25

26 Hiérarchies de sous-typage avec Joker Collection Collection<Object> Collection<?> super: contravariant! Collection<? extends Figure> Collection<? super Figure> extends : covariant! Collection<Cercle> Collection<Figure> List<Cercle> : «est sous-type de» List<E> extends Collection<E> { OK! La généricité en Java 26

27 Hiérarchies de sous-typage avec Joker ArrayList ArrayList<?> class ArrayList<E> implements Collection<E> { boolean add(e elt); E get(int i) ; Compatibilité avec Java 1.4 : typage et contraintes plus «souples» pour ArrayList que pour ArrayList<?> et ArrayList<Object> public static void f(arraylist<?> arg, Object o) { arg.add(o); // KO: pas de type spécifique à la place de E public static void f(arraylist arg, Object o) { arg.add(o); // perte d information statique // donc recours à des cast comme en 1.4 Distinction entre positions covariantes et contra-variantes La généricité en Java 27

28 Restrictions pour les Joker f(arraylist<? extends Figure> arg) class ArrayList<E> implements Collection<E> { boolean add(e elt); E get(int i) ; Si une méthode de ArrayList<E> prend un paramètre de type E on ne peut pas passer un type spécifique (Figure, Cercle, ) dans la version instantiée. Par contre si une méthode renvoie un résultat de type E, on peut l utiliser là où on peut utiliser une instance de type Figure! f(arraylist <? extends Figure> arg): covariant => interdit l'usage de arg en position contravariante (donc comme paramètre). «? extends Figure» représente un sous-type inconnu de Figure et ne peut pas correspondre à une instance d un type spécifique. On ne peut donc que parcourir la collection, pas la modifier (sauf par des méthodes comme clear qui ne se soucient pas du type des objets stockés) Dans Collection de nombreuses méthodes (contains, remove, ) ne prennent par un E en paramètre mais un Object. Donc «ça compile»! public static void f(arraylist<figure> arg, Object o) { arg.contains(o); La généricité en Java 28

29 Restrictions pour les Joker (2) ArrayList<? super Figure> : restrictions duales Pas d'usage en position contravariante, seulement en position covariante. Ajoute à une List les éléments d une ArrayList : static void tolist(arraylist<? extends Figure> src, ArrayList<? super Figure> dst) { for(figure f: src) dst.add(f); // OK. // On peut parcourir src et modifier dst! ArrayList<Cercle> ac = new ArrayList<Cercle>(); Array<Object> os = new ArrayList<Object>(); ac.add(new Cercle()); ac.add(new Cercle()); os.add("coucou"); os.add(1); tolist(ac, os); // OK : introduit les deux cercles dans os La généricité en Java 29

30 Joker? Méthode paramétrée? static <T> ArrayList<T> add(arraylist<t> al, ArrayList<? super T> l) { // pour l'instant l ne sert pas! ArrayList<T> r = new ArrayList<T>(); // T? viendra d'où? Compile? for(t e: al) r.add(e); // Compile?? A l exécution?? return r; static <T> ArrayList<T> add2(arraylist<? extends T> al, ArrayList<T> l){ ArrayList<T> r = new ArrayList<T>(); // T? viendra d'où? Compile? for(t e: al) r.add(e); // Compile?? return r; ArrayList<Figure> af = new ArrayList<>(); ArrayList<object> ao = new ArrayList<>(); af.add(new Cercle()); af.add(new Rectangle()); ao.add("coucou"); ao.add(1); La généricité en Java 30

31 Pour voir si on a compris ;-( Qu est-ce qui est correct? Il faut vérifier les appels à add et add2 ainsi que l affectation ArrayList<Figure> s1 = add(af, ao); // OK ou KO? ArrayList<Object> s2 = add(af, ao); // OK ou KO? ArrayList<Figure> s3 = add2(af, ao); // OK ou KO? ArrayList<Object> s4 = add2(af, ao); // OK ou KO? La généricité en Java 31

32 ? super again interface Comparator<E> { int compare(e o1, E o2); TreeSet : Nécessite une relation d ordre sur E ou un comparateur de E Usage? TreeSet<Cercle> s = new TreeSet(unComparateur); Quels comparateurs peut-on utiliser pour uncomparateur? class TreeSet<E> { TreeSet(Comparator c) Ça dépend de ce qu a prévu le concepteur de TreeSet! Version naïve : TreeSet(Comparator<E> c) { int compare(cercle o1, Cercle o2) ; N'accepte que les comparateurs entre cercles :-( Version améliorée : TreeSet(Comparator<? super E> c) { On peut passer en paramètre un éventuel comparateur plus général qui existerait et aurait défini: ou int compare(figure o1, Figure o2); int compare(object o1, Object o2); La généricité en Java 32

33 max revisitée (cf transparent 7) static <T extends Comparable<T>> T max(collection<t> tab) { Trop restrictif : impose à C une méthode int compareto(c arg) alors qu on dispose peut-être dans C de int compareto(object arg) public class C implements Comparable { // ou Comparable<Object>? public int compareto(object o) { Collection<C> matab = ; C monc = max(matab); // KO Une meilleure interface de max? static <T extends Comparable<? super T>> T max(collection<t> tab) L interface exacte de max? static <T extends Object & Comparable<? super T> > T max(collection<? extends T> tab) Sinon la version «effacée» serait : Comparable max(collection arg) or la version Java 4 a pour en-tête : Object max(collection arg) La généricité en Java 33

34 Pour résumer (Java) Les librairies sont bien conçues et peuvent être réutilisées facilement mais Paramètres parfois surprenants : ex. dans Collection<E> méthode contains(object e) plutôt que contains(e e) Méthodes «bridges» qui peuvent être nécessaires pour avoir le «comportement attendu» du polymorphisme Le mélange avec du code 4.0 réintroduit les risques d'exceptions à l'exécution Concevoir une classe générique réutilisable? Nécessite de bien maîtriser les types «Joker» Méthode générique d une classe standard vs méthode standard d une classe générique? La généricité en Java 34

35 Que manque-t-il encore? Passage de méthodes en paramètre («Lambda expressions» Java 1.8) Plus de flexibilité pour gérer co- et contra-variance à la Scala. Figure Set Figure Cercle Set X Set Cercle Le problème vient que insert de Set<Figure> peut insérer une Figure arbitraire qui polluerait un Set<Cercle> Plus de modification d un ensemble => plus de problème! Déclaration de la variance (l'usage attendu!) au niveau du paramètre, pas globalement! Par exemple, décrire l'usage effectué de c dans dessinetout(collection<figure> c) La généricité en Java 35