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

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: