Spécialisation covariante cours et TP

Plan  Introduction  Rappels théoriques  Définition de la covariance  Présentation du modèle servant d'exemple  Comportement par défaut de Java  Implémentation du comportement covariant en Java  Conclusion

Rappels (1)  Quel est le mécanisme qui permet aux méthodes des magasins concrets de se comporter différemment ?  Polymorphisme

Rappels (2)  Les objets Client ne connaissent que les types abstraits Magasin et Paiement.

 Covariance : définition  Polymorphisme multiple Sur-classe ( abstraite ) Méthode ( argument) Spécialisation des méthodes Spécialisation des classes Spécialisation des arguments Sous-classes ( concrètes ) Méthodes spécialisées ( argument spécialisé)

Modèle exemple  Modèle de référence pour la suite de la démonstration

Covariance : supportée ?  Langages orientés objet supportant la covariance  Eiffel, CLOS  Langages orientés objet ne supportant pas la covariance  Java, C++, Python

But du cours  Montrer que Java ne supporte pas la covariance  Proposer une implémentation en Java  Simulant la covariance  Pour des méthodes avec un seul argument covariant  Le modèle exemple servant de modèle de classes pour l'implémentation (à utliser pour le TP qui suit)

Types déclarés et types inhérents Magasin objet_mag = new McDonalds( ); type déclarétype inhérent

Surcharge et polymorphisme en Java surcharge (signatures différentes) polymorphisme (même signature)

Conversions en Java (1)  Conversion d'un sous-type en sur-type (« upcast »)  McDonalds macdo = new McDonalds();  Magasin mag = (Magasin) macdo;  Toujours possible

Conversions en Java (2)  Conversion d'un sur-type en sous-type(« downcast »)  Impossible si le type inhérent et le type déclaré sont les mêmes  Magasin mag = new Magasin();  McDonalds macdo = (McDonalds) mag; // impossible  Possible si le type inhérent est le même que le type de la conversion  Magasin mag = new McDonalds();  McDonalds macdo = (McDonalds) mag; // possible

Magasin mag = new Magasin(); McDonalds mac = new McDonalds(); Magasin macMag = new McDonalds(); Paiement paiement = new Paiement(2.00); Liquide liquide = new Liquide(2.00); Paiement liquidePaiement = new Liquide(2.00); Méthode invoquée mag.accepte(paiement) mag.accepte(liquide) mag.accepte(liquidePaiement) mac.accepte(paiement) mac.accepte(liquide) mac.accepte(liquidePaiement) macMag.accepte(paiement) macMag.accepte(liquide) macMag.accepte(liquidePaiement) Invariance* Covariance** Magasin.accepte(Paiement) McDonalds.accepte(Liquide) Magasin.accepte(Paiement) McDonalds.accepte(Liquide) Magasin.accepte(Paiement) McDonald.accepte(Liquide) Magasin.accepte(Paiement) Méthode exécutée Magasin.accepte(Paiement) (*) comportement par défaut de java (**) comportement recherché

Problèmes  Comportement de Java par défaut dans ce cas:  Aucun comportement polymorphe  Comportement de surcharge quand les types sont explicites  Conversion implicite dans les autres cas  Java va à la facilité, il ne descend pas dans l'arbre d'héritage pour trouver la méthode adéquate

Solution en Java  Technique  Basée sur les mécanismes de reflexion de Java  package reflect  mécanisme dynamique ( runtime)  La solution doit respecter le modèle objet  La solution ne doit pas affecter le comportement du modèle

Implémentation (1)  Algorithme 1. Implémentation dans la méthode accepte de Magasin  void accepte(Paiement) 2. Déterminer le type inhérent de l'argument  avec la méthode getClass() du package Class  appliquée à l'argument 3. Déterminer le type inhérent du receveur  avec la méthode getClass() du package Class  appliquée à l'objet (this : le receveur)

Implémentation (2) 1. Récupérer la méthode à invoquer  avec la méthode getDeclaredMethod() du package reflect 1. appliquée au type inhérent de l'objet 2. Invoquer la méthode 1. avec la méthode invoke() du package reflect 2. appliquée à la m éthode

Implémentation (3)  Extrait du code Java public abstract class Magasin { public void accepte(Paiement paiement) { try { Class typeInherentArgument[ ] = { paiement.getClass() } ; Class typeInherentReceveur = this.getClass() ; Method lamethode = typeInherentReceveur.getDeclaredMethod(''accepte'', typeInherentArgument) ; Object args[ ] = {paiement}; lamethode.invoke(this, args); } catch (Exception e) {... } }

Test (1)  Faire dériver de Magasin les classes McDonalds et Auchan class McDonalds extends Magasin { public void accepte (Liquide liquide) { System.out.println( ''accepte le liquide '') ; } class McDonalds extends Magasin { public void accepte (Liquide liquide) { System.out.println( ''accepte le liquide '') ; } public void accepte ( CarteBancaire cb) { System.out.println( ''accepte les cartes bancaires '') ; }

Test (2)  La méthode main public static void main ( String arg[ ] ) { Paiement li = new Liquide(5.50) ; Paiement cb = new CarteBancaire(250.20) ; Magasin macMag = new McDonalds() ; macMag.accepte(li) ; Magasin auchMag = new Auchan() ; auchMag.accepte(li) ; auchMag.accepte(cb) ; }

Conclusion  Technique relativement transparente  Non gourmande en ressources  Respecte le modèle objet initial  Permet à Java de supporter la covariance  Le mécanisme peut être pris en compte dès la modélisation (diagramme de classe)  L'accès au méta-modèle objet avec le mécanisme de réflexion est un « must » du langage Java

Solution avec « double dispatch »  Le double dispatch  Basé sur le patron de conception (design pattern) « Visiteur »  Fort couplage entre les classes qui acceptent le visiteur et les classes qui implémentent les visiteurs

Solution avec « double dispatch » Polymorphisme A B C D

Solution avec « double dispatch »  Le cycle de vie du double dispatch  Appels A, B (premier dispatch)  Détermination du type inhérent de l'objet argument de la méthode accepte(arg) (du visiteur; ici CB ou Liquide)  Appels C, D (deuxième dispatch)  Détermination du type inhérent de l'objet sur lequel est invoquée la méthode accepte() (du visité; ici McDonalds ou Auchan)