Délimitation des génériques avec des "super" mot-clé

Que personne n'a donné de réponse satisfaisante, la réponse semble être "sans raison valable".

polygenelubricants donne un bon aperçu de mauvaises choses qui se passe avec le java de la matrice de covariance, ce qui est une terrible fonctionnalité en elle-même. Considérons le fragment de code suivant:

String[] strings = new String[1];
Object[] objects = strings;
objects[0] = 0;

C'est évidemment mauvais code compile sans recourir à une "super" construire, de sorte que la matrice de covariance ne doit pas être utilisé comme un argument.

Maintenant, ici, j'ai un bon exemple de code nécessitant super nommé dans le paramètre de type:

class Nullable<A> {
    private A value;
    //Does not compile!!
    public <B super A> B withDefault(B defaultValue) {
        return value == null ? defaultValue : value;
    }
}

Potentiellement soutenir certaines agréable d'utilisation:

Nullable<Integer> intOrNull = ...;
Integer i = intOrNull.withDefault(8);
Number n = intOrNull.withDefault(3.5);
Object o = intOrNull.withDefault("What's so bad about a String here?");

Le dernier fragment de code ne compile pas, si je retire la B ensemble B est en effet nécessaire.

Noter que la fonctionnalité que je suis en train de mettre en œuvre est facilement obtenu si je inverser l'ordre de paramètre de type de déclarations, et donc de changer la super contrainte à extends. Cependant, cela n'est possible que si je réécrire la méthode statique:

//This one actually works and I use it.
public static <B, A extends B> B withDefault(Nullable<A> nullable, B defaultValue) { ... }

Le point est que ce langage Java restriction est en effet la restriction de certains possible autrement fonctionnalités utiles et peuvent nécessiter laide des solutions de contournement. Je me demande ce qui se passerait si nous avions besoin d' withDefault être virtuel.

Maintenant, à corréler avec ce qu'polygenelubricants dit, nous utilisons B ici de ne pas restreindre le type de l'objet passé comme defaultValue (voir la Chaîne utilisée dans l'exemple), mais plutôt de limiter l'appelant attentes à propos de l'objet à notre retour. Comme une règle simple, vous utilisez extends avec les types de demande et de super avec les types de vous fournir.

OriginalL'auteur Rotsor

Supposons que l'on ait:

• classes de base A > B >, C et D

  class A{
      void methodA(){}
  };
  class B extends  A{
      void methodB(){}
  }
  
  class C extends  B{
      void methodC(){}
  }
  
  class D {
      void methodD(){}
  }

• de l'emploi classes wrapper

  interface Job<T> {
      void exec(T t);
  }
  
  class JobOnA implements Job<A>{
      @Override
      public void exec(A a) {
          a.methodA();
      }
  }
  class JobOnB implements Job<B>{
      @Override
      public void exec(B b) {
          b.methodB();
      }
  }
  
  class JobOnC implements Job<C>{
      @Override
      public void exec(C c) {
          c.methodC();
      }
  }
  
  class JobOnD implements Job<D>{
      @Override
      public void exec(D d) {
          d.methodD();
      }
  }

• et un gérant de classe avec 4 approches différentes pour exécuter le travail sur l'objet

  class Manager<T>{
      final T t;
      Manager(T t){
          this.t=t;
      }
      public void execute1(Job<T> job){
          job.exec(t);
      }
  
      public <U> void execute2(Job<U> job){
          U u= (U) t;  //not safe
          job.exec(u);
      }
  
      public <U extends T> void execute3(Job<U> job){
          U u= (U) t; //not safe
          job.exec(u);
      }
  
      //desired feature, not compiled for now
      public <U super T> void execute4(Job<U> job){
          U u= (U) t; //safe
          job.exec(u);
      }
  }

• avec l'utilisation de la

  void usage(){
      B b = new B();
      Manager<B> managerB = new Manager<>(b);
  
      //TOO STRICT
      managerB.execute1(new JobOnA());
      managerB.execute1(new JobOnB()); //compiled
      managerB.execute1(new JobOnC());
      managerB.execute1(new JobOnD());
  
      //TOO MUCH FREEDOM
      managerB.execute2(new JobOnA()); //compiled
      managerB.execute2(new JobOnB()); //compiled
      managerB.execute2(new JobOnC()); //compiled !!
      managerB.execute2(new JobOnD()); //compiled !!
  
      //NOT ADEQUATE RESTRICTIONS     
      managerB.execute3(new JobOnA());
      managerB.execute3(new JobOnB()); //compiled
      managerB.execute3(new JobOnC()); //compiled !!
      managerB.execute3(new JobOnD());
  
      //SHOULD BE
      managerB.execute4(new JobOnA());  //compiled
      managerB.execute4(new JobOnB());  //compiled
      managerB.execute4(new JobOnC());
      managerB.execute4(new JobOnD());
  }

Des suggestions pour mettre en œuvre execute4 maintenant ?

==========édité =======

    public void execute4(Job<? super  T> job){
        job.exec( t);
    }

Merci à tous 🙂

========== édité ==========

    private <U> void execute2(Job<U> job){
        U u= (U) t;  //now it's safe
        job.exec(u);
    }
    public void execute4(Job<? super  T> job){
        execute2(job);
    }

beaucoup mieux, n'importe quel code avec U à l'intérieur de execute2

super type U devient nommé !

discussion intéressante 🙂

OriginalL'auteur nxdrvr