Comment référencer un type de retour générique avec plusieurs limites

Quant à la question de la prime,

Il y a des cas où une méthode appelée renvoyant une valeur peut être utilisée par l'appelant sans que connaisse le type concret. Il est même probable que ce type n'existe pas du tout, c'est seulement un proxy:

import java.lang.reflect.*;

interface Foo {}
interface Bar {}

class FooBar1 implements Foo, Bar {public String toString() { return "FooBar1"; }}
class FooBar2 implements Foo, Bar {public String toString() { return "FooBar2"; }}   

class FooBar {
    static <T extends Foo & Bar> T getFooBar1() { return (T) new FooBar1(); }
    static <T extends Foo & Bar> T getFooBar2() { return (T) new FooBar2(); }
    static <T extends Foo & Bar> T getFooBar() { 
        return (T) 
        Proxy.newProxyInstance(
            Foo.class.getClassLoader(),
            new Class[] { Foo.class, Bar.class },
            new InvocationHandler() {
                public Object invoke(Object proxy, Method method, Object[] args) {
                    return "PROXY!!!";}});
    }

    static <U extends Foo & Bar> void show(U u) { System.out.println(u); }

    public static void main(String[] args) {
        show(getFooBar1());
        show(getFooBar2());
        show(getFooBar());      
    }

}

Deux FooBar1 et FooBar2 mettre en œuvre Foo et Bar. Dans main, les appels à getFooBar1 et getFooBar2 peuvent être affectés à une variable, bien qu'il n'y ait pas de raison forte de savoir à mon humble avis.

Mais getFooBar est l' cas intéressant, qui utilise un proxy. En pratique, il peut s'agir de l'instance seulement d'un objet qui implémente les deux interfaces. Une méthode différente (show ici) peut être utilisée avec un temporaire d'une manière plus sûre, mais elle ne peut pas être affectée à une variable sans le hack FooBarWrapper décrit dans la question. Il n'est même pas possible de créer un wrapper générique, class Wrapper<T extends U & V> n'est pas autorisé.

Le seul problème semble être de définir une syntaxe, d'autres mécanismes de vérification de type semblent être en place, au moins dans Oracle javac 1.7.0.

Comme @ Paul Bellora mentionné dans sa réponse, le type est résolu par l'appelant, car essentiellement il va maintenant ce qu'il appelle. Je voudrais juste ajouter à sa réponse avec un cas d'utilisation où je pense que l'utilisation de la syntaxe pourrait être bénéfique.

Il existe toujours des alternatives qui évitent d'utiliser une telle syntaxe. Je ne peux pas penser à un seul exemple que cela est tout à fait nécessaire. Cependant je peux penser à un cas d'utilisation d'une situation particulière que cette syntaxe pourrait être utilisée commodément, bien que je ne l'ai même pas utilisé moi-même. Je sais que ce n'est pas le meilleur exemple là-bas, mais il peut arriver au point.

Cas

Récemment, j'ai travaillé au développement d'une interface utilisateur. Dans cette application, j'utilise une bibliothèque pour gérer mes éléments GUI. En plus des fonctionnalités de la bibliothèque, j'ai créé une interface personnalisée qui définit une vue dans mon application qui a des entrées pour un type spécifique de données, disons, entrée de coordonnées. Cette interface aurait l'air comme:

 public interface CoordinateView extends View
 {
      Coordinate getCoordinate();

      //Maybe more stuff
 } 

J'ai plusieurs fenêtres à travers mon application qui implémentent cette interface. Maintenant, disons que pour une raison quelconque, je veux stocker dans un modèle la dernière coordonnée soumise dans une fenêtre et fermer la fenêtre juste après. Pour cela, je peux attacher un gestionnaire au bouton de fenêtre qui soumet le formulaire, le gestionnaire sera déclenché lorsque l'utilisateur ferme la fenêtre. Je pourrais y parvenir en ajoutant simplement le gestionnaire anonymement dans chaque fenêtre, comme:

  public MyWindow extends Window implements CoordinateView, OtherInterface
  {
       private Button submitButton;

       public MyWindow()
       {
          super();
          //Create all the elements

          submitButton.addClickHandler(
              new ClickHandler()
              {
                 @Override
                 onCLick(ClickEvent e)
                 {
                   getModel().add(getCoordinate());
                   destroy();
                 }
              });  
       }
  }

Toutefois, cette conception n'est pas souhaitable pour moi, il n'est pas assez modulaire. Considérant que j'ai une quantité décente de fenêtres avec ce comportement, le changer pourrait devenir plutôt fastidieux. Donc, je préfère extraire la méthode anonyme dans une classe afin qu'il soit plus facile de changer et de maintenir. Mais le problème est que la méthode destroy () n'est définie dans aucune interface, fait juste partie de window et la méthode getCoordinate () est définie dans l'interface I définir.

Utilisation

Dans ce cas, je pourrais utiliser plusieurs limites comme suit:

  public class MyController <T extends Window & CoordinateView> implements ClickHandler
  {
      private T windowWithCoordinates;

      public MyController (T window)
      {
         windowWithCoordinates = window;
      }

      @Override
      onClick(ClickEvent e)
      {
          getModel().add(windowWithCoordinates.getCoordinate());
          windowWithCoordinate.destroy();
      }
  }

Alors le code dans windows sera maintenant:

 public MyWindow extends Window implements CoordinateView, OtherInterface
  {
       private Button submitButton;

       public MyWindow()
       {
          super();
          //Create all the elements

          submitButton.addClickHandler(new MyController<MyWindow>(this));

       }
  }

Notez que le comportement restera le même, le code est juste un cohésif comme il était. C'est seulement plus modulaire, mais il n'a pas nécessité la création d'une interface supplémentaire pour pouvoir l'extraire correctement.

Alternative

Alternativement, j'aurais pu définir une interface supplémentaire étendre CoordinateView et définir une méthode pour fermer la fenêtre.

public interface CoordinateWindow extends CoordinateView
{
    void destroy();
}

Faire en sorte que la fenêtre implémente cette interface plus spécifique au lieu d'utiliser inutilement des paramètres génériques dans le contrôleur extrait:

  public class MyController implements ClickHandler
  {
      private CoordinateWindow windowWithCoordinates;

      public MyController (CoordinateWindow window)
      {
         windowWithCoordinates = window;
      }

      @Override
      onClick(ClickEvent e)
      {
          getModel().add(windowWithCoordinates.getCoordinate());
          windowWithCoordinate.destroy();
      }
  }



    public MyWindow extends Window implements CoordinateWindow
   {
       private Button submitButton;

       public MyWindow()
       {
          super();
          //Create all the elements  
          submitButton.addClickHandler(new MyController(this));                  
       }

       @Override
       void destroy(){
          this.destroy();
       }
  }

Cette approche pour certains peut être considérée comme beaucoup plus propre que la précédente et encore plus réutilisable puisque maintenant elle pourrait être ajoutée à d'autres "fenêtres" en dehors de la hiérarchie spécifiée. Personnellement, je préfère cette approche. Cependant, il peut y avoir un peu de plus de codage puisqu'une nouvelle interface doit être définie juste pour obtenir un accès à une méthode désirée.

En conclusion, bien que personnellement je ne le recommande pas, je pense que l'utilisation de types génériques avec plusieurs limites pourrait aider à coupler des définitions tout en réduisant la quantité de code.

Je ne sais pas ce que Eclipse fait pour vous, mais la plupart du code ci-dessus ne se rapproche pas de la compilation....

J'ai fait les changements appropriés pour le faire compiler autant que possible et voici ce que je reçois:

public class Foo
{
  public String getFoo() { return ""; }  // must have a body
}
public interface Bar // no ()
{
  public void setBar(String bar);
}
public class FooBar<T>
{
  public static <T extends Foo & Bar> T getFooBar()
  {
    return null;
  }
}
public class FB
{
  private FooBar<Object> fb = new FooBar<Object>();

  public static void main(String args[])
  {
    new FB();
  }

  public FB()
  {
    System.out.println(fb.getFooBar());
  }
}

FB.java:12: type parameters of <T>T cannot be determined; no unique maximal instance exists for type variable T with upper bounds java.lang.Object,Foo,Bar
    System.out.println(fb.getFooBar());
                                   ^
1 error