Discussion :

[Deaf]

Bonjour!

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[Alkhan]

bonjour,

le code est le suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

tu aura un warning, mais ca passe

[Deaf]

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>)

[Alkhan]

pour quel raison as tu besoin du type ?

[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.

[divxdede]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[Alkhan]

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.

[Deaf]

@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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[Alkhan]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 ?

[Deaf]

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

[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.

[divxdede]

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...

[tchize_]

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

[Deaf]

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...)

[Alkhan]

finalement, tu a choisi quel solution ?

[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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[Deaf]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
public interface ServiceProvider<T> {
 
    T getService();
 
    String getServiceType();
}

- Conserver une class, mais sans contrainte:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
public interface ServiceProvider {
 
    Object getService();
 
    String/Class<?> getServiceType();
}

[tchize_]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[Deaf]

ç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é.

[tchize_]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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é