Récupérer une Class générique

Bonjour!

J'ai une interface de ce goût là:

Code:

---

1 2 3 4 5 6

public interface ServiceProvider<T> {   T getService();   Class<T> getServiceType(); }

---

où T représente l'interface exposée par le service.

Dans le cas où T est aussi un type généric, ça coince.
Par exemple, prenons T = List<Runnable>, mon implémentation ressemblerait à ça:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

public class Provider implements ServiceProvider<List<Runnable>> { ...   public List<Runnable> getService() { return monService; }   public Class<List<Runnable>> getServiceType() { return ???; } }

---

Je n'arrive pas à trouver une syntaxe qui satisfasse le compilo.
Est-ce possible?
Dois-je modifier mon interface 'ServiceProvider'?

Merci.

bonjour,

le code est le suivant :

Code:

---

1 2 3 4

public Class<List<Runnable>> getServiceType() { return (Class<List<Runnable>>) monService.getClass(); }

---

tu aura un warning, mais ca passe :P

Merci pour la réponse, malheureusement, cela convient pas car je vais renvoyer la classe de l'implémentation (ArrayList ou LinkedList par exemple) alors que je souhaite renvoyer l'interface du service (List<Runnable>)

pour quel raison as tu besoin du type ?

Lorsqu'une entité à besoin d'un certain type de service, elle va voir qui le propose via les providers.

Si j'affiche la classe de l'implémentation, elle pourrait éventuellement trouver des interfaces implémentées pour d'autres raisons.
De plus, d'un point de vue conceptuel, le service doit présenter l'interface et non l'implémentation.

Citation:

---

Envoyé par Deaf

Lorsqu'une entité à besoin d'un certain type de service, elle va voir qui le propose via les providers.

Si j'affiche la classe de l'implémentation, elle pourrait éventuellement trouver des interfaces implémentées pour d'autres raisons.
De plus, d'un point de vue conceptuel, le service doit présenter l'interface et non l'implémentation.

---

Justement je m'attends plus à un fonctionnement approchant ceci:

Code:

---

1 2 3 4

public interface ServiceProvider {   public <T> T getService( Class<T> classe ); }

---

C'est l'appelant qui passe au provider le type de service qu'il recherche.
Je peu a ce stade écrire

Code:

---

1 2	List<Toto> a = monProvider.getService( List<Toto>.class );

---

Et avoir une implémentation de mon service utlisant une ArrayList.
De plus, je n'aime pas trop utiliser des collections "brut" pour representer une notion de service. C'est trop abstrait, la liste ne te donne pas d'indication sur ce que represente ton ensemble. Par exemple List<Client> ne te dit pas qu'il s'agit d'un service te donnant la liste des clients mauvais payeur !! l'interface de ton service est floue.

tes types de service seront fixe ? si oui, tu peux peut être définir un enum avec tous les types et utiliser ensuite cet enum.

@divxdede

En ce qui concerne l'utilisation de l'interface List, ce n'était qu'un exemple d'interface générique. En réalité, j'utilise des interfaces de mon cru.

Malheureusement, ce bout de code:

Code:

---

List<Toto> a = monProvider.getService( List<Toto>.class );

---

ne passe pas le compilateur. Ce changement est sujet au même problème 'technique' que le code originel.

Vu ce que tu as proposé, je préfère préciser un point: Mon provider ne propose qu'un seul service, donc mettre le type en paramètre ne me semble pas judicieux. Cela pourrait laisser penser que le provider va choisir un service en fonction du type.
Mais bon, là, c'est du pinaillage et on s'éloigne du sujet ;)


@Alkhan
Non, les types ne sont pas fixes. Je suis dans une architecture modulaire, donc ce n'est pas possible d'utiliser d'enum pour représenter les services...


Merci à vous de vous pencher sur mon problème.

bien alors est il possible que tu retourne un le type sous forme de chaîne sauf si cela pause un problème à un autre niveau de ton programme.

Cela peux paraitre étrange mais au moins tu auras le bon type. je pense alors à 2 solutions :

soit tu gardes ton interface et dans la classe qui l'implemente tu écris :

Code:

---

1 2 3 4 5

java.util.List<java.lang.Runnable> String getServiceType() { return "java.util.List<java.lang.Runnable>"; }

---

soit ton interface devient une classe abstraite qui definit :

Code:

---

1 2 3 4 5 6

String getServiceType() { Type tI = this.getClass().getGenericSuperclass(); ParameterizedType p = (ParameterizedType) tI; return p.getActualTypeArguments()[0].toString(); }

---

évidement, il faudra tester si c'est un generic, la c'est pour l'exemple.
Cela peut il convenir ?

Je pense que le passage en chaîne me semble une des seules solutions acceptables.

Ceci dit, si quelqu'un trouve un autre moyen je reste preneur, au moins pour ma culture J ;)

pour information, "List<Toto>.class" et "List<Object>.class" sont des valeurs strictement identiques pour la jvm, puisque le generic ne sert qu'au compilateur.

Citation:

---

Envoyé par tchize_

pour information, "List<Toto>.class" et "List<Object>.class" sont des valeurs strictement identiques pour la jvm, puisque le generic ne sert qu'au compilateur.

---

Effectivement, il s'agit uniquement d'un sucre syntaxique utilisé par la compilation.


Ceci dit "List<String>.class" n'est effectivement pas autorisé par le compilateur et je suis assez surpris... :oops:

c'est normal, puisque ça ne veux rien dure. C'est List.class qu'il faut utiliser!

Sauf que le compilo n'accepte pas List.class dans mon exemple :?

Même si je suis conscient que cela ne change rien à l'exécution, j'aurai aimé faire un truc propre (et qui compile...)

finalement, tu a choisi quel solution ?

J'ai bien peur qu'on touche à une limitation des génériques Java (il y en a un paquet, après tout,) et qu'il te faille faire moins propre, genre :

Code:

---

1 2 3 4 5 6 7 8 9

public static <T> T getService(Class<?> classe) { if(classe == List.class) { return (T)(new ArrayList()); } else if(classe == Map.class) { return (T)(new HashMap()); } else { throw new IllegalArgumentException(); } }

---

En sachant qu'il n'y a pas de vérification statique que T est bien de la classe fournie, et que si on t'appelle en attendant un Date et qu'on te file Integer.class en paramètre, ça va faire un ClassCastException, parce que les deux ne correspondent pas mais ça compile quand même.

La seule manière propre que je vois, c'est de se taper des méthodes getListService(), getMapService(), ... Et ainsi de suite pour chaque type générique qui puisse être un service.
Et d'adapter le reste du code autour de cette limitation.
Pour le dire autrement, de s'interdire d'avoir "n'importe quel" service qui soit de type paramétré. Adapter pour faire autrement, donc.

Vu que cela semble être une limitation des Generics, je vais être obligé de retirer la généricité de la méthode getServiceType(), c'est dommage, mais si j'ai pas le choix.

J'arrive deux options:
- Le passage en String du type

Code:

---

1 2 3 4 5 6

public interface ServiceProvider<T> {   T getService();   String getServiceType(); }

---

- Conserver une class, mais sans contrainte:

Code:

---

1 2 3 4 5 6

public interface ServiceProvider<T> {   T getService();   Class<?> getServiceType(); }

---

Dans les deux cas, j'ai bien peur que ma généricité ne me soit plus d'une grande utilité. Du coup, je vais peut-être opter pour une solution:

Code:

---

1 2 3 4 5 6

public interface ServiceProvider {   Object getService();   String/Class<?> getServiceType(); }

---

Citation:

---

Envoyé par thelvin

J'ai bien peur qu'on touche à une limitation des génériques Java (il y en a un paquet, après tout,) et qu'il te faille faire moins propre, genre :

Code:

---

1 2 3 4 5 6 7 8 9

public static <T> T getService(Class<?> classe) { if(classe == List.class) { return (T)(new ArrayList()); } else if(classe == Map.class) { return (T)(new HashMap()); } else { throw new IllegalArgumentException(); } }

---

---

pour ça tu peux très bien faire ceci:

Code:

---

1 2 3 4 5 6 7 8 9

public static <T> T getService(Class<? extends T> classe) { if(classe == List.class) { return (T)(new ArrayList()); } else if(classe == Map.class) { return (T)(new HashMap()); } else { throw new IllegalArgumentException(); } }

---

ca forcera au moins l'appelant, mais ça va pas te servir à grand chose, car comme on est dans une service, tu va probablement appeler 'à l'aveugle' dans ta factory, donc les generics ne serviront à rien

Citation:

---

Envoyé par tchize_

ça va pas te servir à grand chose, car comme on est dans une service, tu va probablement appeler 'à l'aveugle' dans ta factory, donc les generics ne serviront à rien

---

Exactement! Le seul but des generics était, dans mon cas, d'ajouter des contrôles à la compilation pour éviter de faire n'importe quoi en assurant que le type déclaré correspondait bien au service renvoyé.

Citation:

---

Envoyé par Deaf

Exactement! Le seul but des generics était, dans mon cas, d'ajouter des contrôles à la compilation pour éviter de faire n'importe quoi en assurant que le type déclaré correspondait bien au service renvoyé.

---

ces controle ne pourront pas exister, puisque quand tu appelera une classe de service, tu n'aura aucune idée des type renvoyé réellement, du moins au moment de la compilation. Maintenant, si ton but était de forcer le Type dans le service même (éviter des bourde dans le service), pourquoi le pas plutot opter pour cette option:

Code:

---

1 2 3 4 5 6 7 8 9 10

public interface Service<T> {   public T createObject(); public Class<T> getType(); }     public class MachinService extends Service<Machin> { // il est maintenant impossible pour le codeur de ce service de revoyer autre chose que Machin ou de retourner autre chose que Class<Machin> depuis getType }

---

Ou alors j'ai rien compris au but recherché :aie:

En fait, je pense que tu as compris ma démarche, tu as d'ailleurs proposé le code de l'interface que j'ai posté au début (au nommage près).

Par contre, dans ce que tu proposes, j'aimerais voir comment tu écris l'implémentation de la méthode getType dans ce cas:

Code:

---

1 2 3 4 5

public class MachinService extends Service<Machin<Long>> { public Class<Machin<Long>> getType() { ???? } }

---

return Machin.class ?

Non, c'est bien là le problème, le compilateur ne l'accepte pas...

erf, et avec un typecasting forcé? +ignore warning? Dans ce cas ce sera ok pour la pluspart des classes sauf les classes génériques :/

Je peux m'en sortir, avec un truc du genre:

Code:

---

return (Class<Machin<Long>>) ((Object) Machin.class))

---

Mais cela n'a plus trop d'intérêt...

Eventuellement, je pensais à change la méthode getType comme cela:

Code:

---

Class<? super T> getType()

---

Comme cela, je peux faire sauter les généric et renvoyer Machin.class, ce qui est acceptable de mon point de vue.

Bonjour il y a quelque chose que je ne comprends pas : à quoi sert la méthode getType dans l'interface? Si elle est dans l'interface c'est qu'elle doit être utile au client mais je ne vois quand ce dernier devrait être amené à l'utiliser. Il serait intéressant de voir le code du client...

Je n'ai pas de code à montrer car l'exemple que j'ai montré est une grosse simplification de la réalité.

Par contre, je peux expliquer le principe.
C'est une architecture modulaire où les 'ServiceProvider's sont accessibles.
Un client va les parcourir jusqu'à en trouver un qui propose un service du type recherché.
Comme cela se passe à l'exécution, les types génériques ne servent plus à rien, d'où l'intérêt d'exposer le type du service.

Je ne pense pas que ce soit au client de parcourir les ServiceProvider. Je pense qu'il n'y a qu'un seul provider, et que ce dernier permet de renvoyer au client le bon service en fonction d'un paramètre, qu'on peut choisir comme étant la classe du service recherché (ou plutôt la classe de son interface). Ce qui donnerait :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

public interface Service<T> { void process(T arg); }   public class ServiceProvider { Map<Class<?>,Service<?>> map = ..;   public <T> Service<T> getService(Class<T> cls) { return (Service<T>) map.get(cls); } }

---

Quand je dis que le client parcours les ServiceProvider, c'est une image, il y a une entité intermédiaire qui le fait pour lui.

Ceci dit, l'exemple que tu donnes est trop rigide:
- Il ne gère pas l'héritage (si je veux une Collection, une List conviendra aussi)
- A une interface donnée peuvent exister plusieurs services

Après, c'est mon choix que les plugins exposent des ServiceProvider, donc il y en aura plusieurs (à noter que je ne l'ai pas appelé ServicesProvider). Autre détail, l'interface est plus riche que ce que j'ai affiché. La mettre dans une Map revient à la réduire à un simple couple (Type, ServiceDeCeType) et à perdre le bénéfice des autres méthodes de l'interface.

Mais bon, après tout, le but du post n'est pas de parler d'archi, d'autant plus que j'ai donné assez peu d'infos sur le sujet...

Pour gérer l'héritage et le multiservices, c'est pas bien compliqué :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

public <T> List<Service<? super T>> getServices(Class<T> cls) { List<Service<? super T>> list = new ArrayList<Service<? super T>>(); while (cls != null) { Service<? super T> service = (Service<? super T>) map.get(cls); if (service != null) { list.add(service); } cls = cls.getSuperClass(); } return list; }

---

dans l'ensemble, si ce n'est pas hyper important que le type de la classe retourné soit controlé par le compilateur, il reste l'option Class<?> dans la signature. Et je reconnais que certain forcage de type ne sont pas possibles proprement en generics :/

Ceci dit, quand on regarde certaines classes de sun (jette un oeil à AbstractList) c'est pas les suppresswarning qui manquent :aie: