Comment forcer un paramètre de type générique à être une interface?

Question

Existe-t-il un moyen en Java de spécifier que le paramètre de type d'une classe générique doit être une interface (et non simplement l'étendre!)?

Ce que je veux faire est le suivant:

public class MyClass

Signifiant que Y doit être une sous-classe de SomeOtherClass ET implémenter X. Ce que j'obtiens actuellement du compilateur est

Le type X n'est pas une interface; il ne peut pas être spécifié en tant que paramètre borné

Alors, comment puis-je dire au compilateur que X doit toujours être une interface?

Éditer:
D'accord, je suppose que j'ai simplifié un peu mon problème. Utilisons mon domaine d'application réel pour le rendre plus clair:

J'ai une API pour représenter des diagrammes. Un Diagramme contient des objets Noeud et Arête. Ces trois classes implémentent toutes l'interface Forme. Les formes peuvent avoir des formes enfants, une forme parent et appartiennent à un diagramme.

Le problème est que j'ai besoin de créer deux versions de cette API: une open-source avec juste des fonctionnalités de base et une étendue avec plus de fonctionnalités. Cependant, l'API étendue ne doit fournir que des méthodes qui renvoient les types étendus (DiagrammeEtendu, NoeudEtendu, ArêteEtendue et (voici le problème) FormeEtendue).
Donc j'ai quelque chose comme ceci:

/* CLASSES DE BASE */
public interface Forme, Y extends Diagramme>{
    public List getFormesEnfant();
    public X getParent();
    public Y getDiagramme();
    ...
}

public class Diagramme, Y extends Diagramme> implements Forme{...}
public class Arete, Y extends Diagramme> implements Forme{...}
...

/* CLASSES ÉTENDUES */
public interface FormeEtendue extends Forme { ... }

public class DiagrammeEtendu extends Diagramme implements FormeEtendue { ... }
public class AreteEtendue extends Arete implements FormeEtendue { ... }
...

L'API étendue fonctionne bien et le code de l'API de base donne quelques avertissements, mais le principal problème survient lors de l'utilisation de l'API de base:

public class SomeImporter, Y extends Diagramme, E extends Arete>{
    private Y diagramme;

    public void ajouterNouvelleArete(E nouvelleArete){
        diagramme.ajouterFormeEnfant(nouvelleArete);
    ...

Cette dernière ligne me donne l'avertissement suivant:

La méthode ajouterFormeEnfant(X) dans le type Diagramme n'est pas applicable pour les arguments (E)

Alors maintenant, j'aimerais simplement spécifier que E doit également implémenter X et tout serait parfait - du moins je l'espère ;)

Tout ceci a-t-il du sens? Connaissez-vous un moyen de le faire? Ou existe-t-il même une meilleure façon d'obtenir l'API étendue avec les restrictions mentionnées?
Merci de m'avoir suivi, toute aide est grandement appréciée!

Answer 1

Vous pouvez utiliser :

class Foo {...}

Une classe Foo avec un paramètre de type, T. Foo doit être instancié avec un type qui est un sous-type de Number et qui implémente Comparable.

Answer 2

Dans le contexte des génériques, gère à la fois les extensions et les implémentations. Voici un exemple :

public class GenericsTest {
    public static void main(String[] args) {
        GenericsTest t = new GenericsTest();
        GenericsTest t2 = new GenericsTest();
    }
}

class GT implements Runnable{
    public void run() {

    }
}

class GT2 {

}

~~

GenericsTest acceptera GT car il implémente Runnable. GT2 ne le fait pas, c'est pourquoi il échoue lors de la tentative de compilation de cette deuxième instantiation de GenericsTest.

~~

Answer 3

Peut-être pouvez-vous simplifier un peu votre modèle : trop de génériques deviennent rapidement un véritable casse-tête en termes de lisibilité, et c'est un problème assez important si vous définissez une API publique. En général, si vous ne comprenez plus ce qui devrait se trouver entre les crochets, alors vous allez trop loin pour vos besoins - et vous ne pouvez pas vous attendre à ce que les utilisateurs le comprennent mieux que vous...

Quoi qu'il en soit, afin de faire compiler votre code, vous pouvez essayer de définir quelque chose comme ceci, dans le type Shape:

public > void addChildShape(S shape);

~~

Cela devrait fonctionner.

J'espère que cela aide.

~~

Answer 4

Vous avez écrit ce qui suit:

public interface Shape, Y extends Diagram>{
    public List getChildShapes();
    public X getParent();
    public Y getDiagram();
    ...
}

Je conseillerais, au minimum, de vous débarrasser de la variable de type X, comme suit:

public interface Shape{
    public List> getChildShapes();
    public Shape getParent();
    public Diagram getDiagram();
    ...
}

La raison en est que ce que vous avez écrit initialement souffre d'un imbriquement récursif potentiellement non borné des paramètres de type. Une forme peut être imbriquée dans une forme parente, qui peut être à son tour imbriquée dans une autre, et tout cela doit être pris en compte dans la signature de type... pas une bonne recette pour la lisibilité. Eh bien, cela ne se produit pas exactement de cette manière dans votre exemple, dans lequel vous déclarez "Shape" au lieu de "Shape>" mais c'est la direction que vous prenez, si vous souhaitez réellement utiliser Shape par lui-même...

Je recommanderais probablement également d'aller un pas plus loin et de vous débarrasser de la variable Y pour des raisons similaires. Les génériques Java ne fonctionnent pas très bien avec ce type de composition. Lorsque vous essayez d'imposer des types statiques pour ce type de modélisation via les génériques, j'ai constaté que le système de types commence à se dégrader lorsque vous commencez à étendre les choses plus tard.

C'est typique du problème Animal/Chien... Animal a un getChildren(), mais les enfants de Chien doivent également être des Chiens... Java ne gère pas bien cela car (en partie en raison du manque de types abstraits comme dans des langages comme Scala, mais je ne dis pas que vous devriez vous précipiter pour utiliser Scala pour ce problème non plus) les variables de type doivent commencer à être déclarées dans toutes sortes d'endroits où elles ne vont pas vraiment.

Answer 5

Utilisez un préprocesseur pour générer la version "réduite" de votre code. Utiliser apt et des annotations pourrait être une bonne façon de le faire.