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

Dans les génériques contexte, <Type extends IInterface> gère à la fois prolonge et met en œuvre. Voici un exemple:

public class GenericsTest<S extends Runnable> {
    public static void main(String[] args) {
        GenericsTest<GT> t = new GenericsTest<GT>();
        GenericsTest<GT2> t2 = new GenericsTest<GT>();
    }
}

class GT implements Runnable{
    public void run() {

    }
}

class GT2 {

}

GenericsTest acceptera GT car il implémente Runnable. GT2 n'est pas, par conséquent, il échoue lorsque vous essayez de compiler ce deuxième GenericsTest de l'instanciation.

Vous écrit ce qui suit:

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

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

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

La raison en est que ce que vous a écrit à l'origine en souffre potentiellement illimitée récursive imbrication des paramètres de type. Une forme peut être imbriquées à l'intérieur d'un parent de la forme, qui peut être imbriquée dans une autre, tout ce qui doit être représenté dans le type de signature... pas une bonne recette pour des raisons de lisibilité. Eh bien, il ne se passe pas tout à fait de cette façon dans votre exemple, dans lequel vous déclarez "Forme<X>" au lieu de "Forme<Figure<X>>" mais c'est la direction que vous allez, si vous jamais eu envie d'utiliser effectivement la Forme de sa propre...

Je ne serais probablement aussi recommande d'aller une étape plus loin et de se débarrasser de la variable Y pour des raisons similaires. Java génériques n'avez pas à faire face très bien avec ce genre de composition. Lorsque vous tentez d'appliquer les types statiques pour ce type de modélisation par les génériques, j'ai trouvé que le système de type commence à se décomposer lorsque vous commencez à étendre les choses par la suite.

C'est typique de l'Animal/Chien de problème... Animal a un getChildren(), mais le Chien, les enfants doivent aussi être des Chiens... Java ne supporte pas ce bien à cause (en partie en raison de l'absence de résumé types, comme dans les langues, comme Scala, mais je ne dis pas que vous devriez se précipiter et de l'utilisation de Scala pour ce problème) le type de variables doivent commencer à être déclarée dans toutes sortes d'endroits où ils n'ont pas vraiment leur place.

Je pourrais être loin de la base ici, mais ma compréhension des génériques est un peu différent.

Je demande à quelqu'un de me corriger si je me trompe.

OMI -

C'est un très déroutant de la structure que vous avez. Vous avez des sous-classes de la Forme référencé à l'infini, il ressemble.

Votre Forme d'interface est utilisé de la même manière qu'une table de hachage, mais je n'ai jamais vu une HashMap faire ce que vous essayez de faire, éventuellement, vous devez avoir soit X une classe en Forme. Sinon, vous faites HashMap

Si vous voulez toujours que X soit un "EST" UNE relation à une interface, il ne se produira pas. Ce n'est pas ce que les génériques sont pour. Les génériques sont utilisés pour appliquer des méthodes à Objets multiples, et les interfaces ne peuvent pas être des Objets. Les Interfaces de définir un contrat entre un client et une classe. Tout ce que vous pouvez faire avec de la est à dire que vous allez accepter n'importe quel Objet qui implémente Runnable, parce que tous ou certains de vos méthodes sont nécessaires pour utiliser les méthodes d'interface Runnable. Sinon, si vous ne spécifiez pas et que vous définissez comme , votre contrat entre votre classe avec le client peut produire un comportement inattendu et provoquent la mauvaise valeur de retour ou la levée d'une exception.

Par exemple:

public interface Animal {
    void eat();

    void speak();
}

public interface Dog extends Animal {
    void scratch();

    void sniff();
}

public interface Cat extends Animal {
    void sleep();

    void stretch();
}

public GoldenRetriever implements Dog {
    public GoldenRetriever() { }

    void eat() {
        System.out.println("I like my Kibbles!");
    }

    void speak() {
        System.out.println("Rufff!");
    }

    void scratch() {
        System.out.println("I hate this collar.");
    }

    void sniff() {
        System.out.println("Ummmm?");
    }
}

public Tiger implements Cat {
    public Tiger() { }

    void eat() {
        System.out.println("This meat is tasty.");
    }

    void speak() {
        System.out.println("Roar!");
    }

    void sleep() {
        System.out.println("Yawn.");
    }

    void stretch() {
        System.out.println("Mmmmmm.");
    }
}

Maintenant, si vous avez cette classe, vous pouvez vous attendre que vous POUVEZ toujours appeler le "parler ()" & " sniff()'

public class Kingdom<X extends Dog> {
    public Kingdom(X dog) {
        dog.toString();
        dog.speak();
        dog.sniff();
    }
}

Toutefois, si vous avez fait cela, vous NE peut pas TOUJOURS faire appel à "faire parler ()" & " sniff()'

public class Kingdom<X> {
    public Kingdom(X object) {
        object.toString();
        object.speak();
        object.sniff();
    }
}

CONCLUSION:

Génériques de vous donner la capacité d'utiliser des méthodes sur un large éventail d'objets, pas des interfaces. Votre inscription définitive dans un générique DOIT être d'un type d'Objet.