¿Por qué es super.super.method (); no permitido en Java?

Leí esta pregunta y pensé que se resolvería fácilmente (no es que no se pueda resolver sin ella) si se pudiera escribir:

@Override
public String toString() {
    return super.super.toString();
}

No estoy seguro de si es útil en muchos casos, pero me pregunto por qué no lo es y si existe algo así en otros idiomas.

¿Qué piensan ustedes?

EDITAR: Para aclarar: sí, lo sé, eso es imposible en Java y realmente no lo extraño. Esto no es nada que esperaba que funcionara y me sorprendió recibir un error del compilador. Acabo de tener la idea y me gusta discutirla.

Viola la encapsulación. No debería poder evitar el comportamiento de la clase principal. A veces tiene sentido poder omitir el comportamiento de su propia clase (particularmente desde el mismo método) pero no el de sus padres. Por ejemplo, supongamos que tenemos una "colección de artículos" base, una subclase que representa "una colección de artículos rojos" y una subclase de esa que representa "una colección de artículos rojos grandes". Tiene sentido tener:

public class Items
{
    public void add(Item item) { ... }
}

public class RedItems extends Items
{
    @Override
    public void add(Item item)
    {
        if (!item.isRed())
        {
            throw new NotRedItemException();
        }
        super.add(item);
    }
}

public class BigRedItems extends RedItems
{
    @Override
    public void add(Item item)
    {
        if (!item.isBig())
        {
            throw new NotBigItemException();
        }
        super.add(item);
    }
}

Está bien: RedItems siempre puede estar seguro de que los elementos que contiene son todos rojos. Ahora supongamos que éramos capaces de llamar super.super.add ():

public class NaughtyItems extends RedItems
{
    @Override
    public void add(Item item)
    {
        // I don't care if it's red or not. Take that, RedItems!
        super.super.add(item);
    }
}

Ahora podríamos agregar lo que queramos, y la invariante RedItemsestá rota.

¿Tiene sentido?

Creo que Jon Skeet tiene la respuesta correcta. Solo me gustaría agregar que puede acceder a las variables sombreadas de las superclases de las superclases al emitir this:

interface I { int x = 0; }
class T1 implements I { int x = 1; }
class T2 extends T1 { int x = 2; }
class T3 extends T2 {
        int x = 3;
        void test() {
                System.out.println("x=\t\t"          + x);
                System.out.println("super.x=\t\t"    + super.x);
                System.out.println("((T2)this).x=\t" + ((T2)this).x);
                System.out.println("((T1)this).x=\t" + ((T1)this).x);
                System.out.println("((I)this).x=\t"  + ((I)this).x);
        }
}

class Test {
        public static void main(String[] args) {
                new T3().test();
        }
}

que produce la salida:

x = 3
super.x = 2
((T2) esto) .x = 2
((T1) esto) .x = 1
((I) esto) .x = 0

(ejemplo del JLS )

Sin embargo, esto no funciona para las llamadas a métodos porque las llamadas a métodos se determinan en función del tipo de tiempo de ejecución del objeto.

Creo que el siguiente código permite usar super.super ... super.method () en la mayoría de los casos. (incluso si es feo hacer eso)

En breve

1. crear una instancia temporal de tipo ancestro
2. copiar valores de campos del objeto original a uno temporal
3. invocar método de destino en objeto temporal
4. copiar valores modificados de nuevo al objeto original

Uso:

public class A {
   public void doThat() { ... }
}

public class B extends A {
   public void doThat() { /* don't call super.doThat() */ }
}

public class C extends B {
   public void doThat() {
      Magic.exec(A.class, this, "doThat");
   }
}


public class Magic {
    public static <Type, ChieldType extends Type> void exec(Class<Type> oneSuperType, ChieldType instance,
            String methodOfParentToExec) {
        try {
            Type type = oneSuperType.newInstance();
            shareVars(oneSuperType, instance, type);
            oneSuperType.getMethod(methodOfParentToExec).invoke(type);
            shareVars(oneSuperType, type, instance);
        } catch (Exception e) {
            throw new RuntimeException(e);
        }
    }
    private static <Type, SourceType extends Type, TargetType extends Type> void shareVars(Class<Type> clazz,
            SourceType source, TargetType target) throws IllegalArgumentException, IllegalAccessException {
        Class<?> loop = clazz;
        do {
            for (Field f : loop.getDeclaredFields()) {
                if (!f.isAccessible()) {
                    f.setAccessible(true);
                }
                f.set(target, f.get(source));
            }
            loop = loop.getSuperclass();
        } while (loop != Object.class);
    }
}

No tengo suficiente reputación para comentar, así que agregaré esto a las otras respuestas.

Jon Skeet responde excelentemente, con un hermoso ejemplo. Matt B tiene un punto: no todas las superclases tienen supers. Su código se rompería si llamara a un super de un super que no tenía super.

La programación orientada a objetos (que es Java) se trata de objetos, no de funciones. Si desea una programación orientada a tareas, elija C ++ u otra cosa. Si su objeto no encaja en su superclase, entonces debe agregarlo a la "clase de abuelo", crear una nueva clase o encontrar otro súper en el que encaje.

Personalmente, he encontrado que esta limitación es una de las mayores fortalezas de Java. El código es algo rígido en comparación con otros idiomas que he usado, pero siempre sé qué esperar. Esto ayuda con el objetivo "simple y familiar" de Java. En mi opinión, llamar a super.super no es simple ni familiar. ¿Quizás los desarrolladores sintieron lo mismo?

Hay algunas buenas razones para hacer esto. Es posible que tenga una subclase que tiene un método que se implementa incorrectamente, pero el método principal se implementa correctamente. Debido a que pertenece a una biblioteca de terceros, es posible que no pueda / no quiera cambiar la fuente. En este caso, desea crear una subclase pero anular un método para llamar al método super.super.

Como se muestra en algunos otros carteles, es posible hacer esto a través de la reflexión, pero debería ser posible hacer algo como

(SuperSuperClass this) .theMethod ();

Estoy lidiando con este problema en este momento: la solución rápida es copiar y pegar el método de superclase en el método de subclase :)

Además de los muy buenos puntos que otros han hecho, creo que hay otra razón: ¿qué pasa si la superclase no tiene una superclase?

Como cada clase se extiende naturalmente (al menos) Object, super.whatever()siempre se referirá a un método en la superclase. Pero lo que si su clase sólo se extiende Object- lo que super.superse refieren a continuación? ¿Cómo debe manejarse ese comportamiento: un error del compilador, un puntero nulo, etc.?

Creo que la razón principal por la que esto no está permitido es que viola la encapsulación, pero esta podría ser una pequeña razón también.

Creo que si sobrescribe un método y desea toda la versión de equalssuperclase del mismo (como, por ejemplo ), entonces virtualmente siempre querrá llamar primero a la versión de superclase directa, que a su vez llamará a su versión de superclase si así lo desea .

Creo que rara vez tiene sentido (si es que no. No puedo pensar en un caso en el que lo haga) llamar a una versión arbitraria de una superclase de un método. No sé si eso es posible en Java. Se puede hacer en C ++:

this->ReallyTheBase::foo();

Supongo que porque no se usa con tanta frecuencia. La única razón por la que pude ver su uso es si su padre directo ha anulado alguna funcionalidad y está tratando de restaurarlo al original.

Lo que me parece estar en contra de los principios OO, ya que el padre directo de la clase debería estar más estrechamente relacionado con su clase que el abuelo.

Mire este proyecto de Github, especialmente la variable objectHandle. Este proyecto muestra cómo llamar de manera real y precisa al método de abuelo en un nieto.

En caso de que el enlace se rompa, aquí está el código:

import lombok.val;
import org.junit.Assert;
import org.junit.Test;

import java.lang.invoke.*;

/*
Your scientists were so preoccupied with whether or not they could, they didn’t stop to think if they should.
Please don't actually do this... :P
*/
public class ImplLookupTest {
    private MethodHandles.Lookup getImplLookup() throws NoSuchFieldException, IllegalAccessException {
        val field = MethodHandles.Lookup.class.getDeclaredField("IMPL_LOOKUP");
        field.setAccessible(true);
        return (MethodHandles.Lookup) field.get(null);
    }

    @Test
    public void test() throws Throwable {
        val lookup = getImplLookup();
        val baseHandle = lookup.findSpecial(Base.class, "toString",
            MethodType.methodType(String.class),
            Sub.class);
        val objectHandle = lookup.findSpecial(Object.class, "toString",
            MethodType.methodType(String.class),
            // Must use Base.class here for this reference to call Object's toString
            Base.class);
        val sub = new Sub();
        Assert.assertEquals("Sub", sub.toString());
        Assert.assertEquals("Base", baseHandle.invoke(sub));
        Assert.assertEquals(toString(sub), objectHandle.invoke(sub));
    }

    private static String toString(Object o) {
        return o.getClass().getName() + "@" + Integer.toHexString(o.hashCode());
    }

    public class Sub extends Base {
        @Override
        public String toString() {
            return "Sub";
        }
    }

    public class Base {
        @Override
        public String toString() {
            return "Base";
        }
    }
}

Feliz codificación !!!!

Pondría el cuerpo del método super.super en otro método, si es posible

class SuperSuperClass {
    public String toString() {
        return DescribeMe();
    }

    protected String DescribeMe() {
        return "I am super super";
    }
}

class SuperClass extends SuperSuperClass {
    public String toString() {
        return "I am super";
    }
}

class ChildClass extends SuperClass {
    public String toString() {
        return DescribeMe();
    }
}

O si no puede cambiar la super-super clase, puede intentar esto:

class SuperSuperClass {
    public String toString() {
        return "I am super super";
    }
}

class SuperClass extends SuperSuperClass {
    public String toString() {
        return DescribeMe(super.toString());
    }

    protected String DescribeMe(string fromSuper) {
        return "I am super";
    }
}

class ChildClass extends SuperClass {
    protected String DescribeMe(string fromSuper) {
        return fromSuper;
    }
}

En ambos casos, el

new ChildClass().toString();

resultados para "Soy super super"

Parecería posible obtener al menos la clase de la superclase de la superclase, aunque no necesariamente la instancia de la misma, utilizando la reflexión; Si esto puede ser útil, considere el Javadoc en http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Class.html#getSuperclass ()

public class A {

     @Override
     public String toString() {
          return "A";
     }

}


public class B extends A {

     @Override
     public String toString() {
          return "B";
     }

}

public class C extends B {

     @Override
     public String toString() {
          return "C";
     }

}


public class D extends C {

     @Override
     public String toString() {
          String result = "";
          try {
                result = this.getClass().getSuperclass().getSuperclass().getSuperclass().newInstance().toString();
          } catch (InstantiationException ex) {
                Logger.getLogger(D.class.getName()).log(Level.SEVERE, null, ex);
          } catch (IllegalAccessException ex) {
                Logger.getLogger(D.class.getName()).log(Level.SEVERE, null, ex);
          }
          return result;
     }

}

public class Main {

     public static void main(String... args) {
          D d = new D();
          System.out.println(d);

     }
}

ejecutar: UNA CREACIÓN EXITOSA (tiempo total: 0 segundos)

Llamar a super.super.method () tiene sentido cuando no puede cambiar el código de la clase base. Esto sucede a menudo cuando está extendiendo una biblioteca existente.

Pregúntese primero, ¿por qué está extendiendo esa clase? Si la respuesta es "porque no puedo cambiarlo", puede crear un paquete y una clase exactos en su aplicación, y reescribir un método travieso o crear un delegado:

package com.company.application;

public class OneYouWantExtend extends OneThatContainsDesiredMethod {

    // one way is to rewrite method() to call super.method() only or 
    // to doStuff() and then call super.method()

    public void method() {
        if (isDoStuff()) {
            // do stuff
        }
        super.method();
    }

    protected abstract boolean isDoStuff();


    // second way is to define methodDelegate() that will call hidden super.method()

    public void methodDelegate() {
        super.method();
    }
    ...
}

public class OneThatContainsDesiredMethod {

    public void method() {...}
    ...
}

Por ejemplo, puede crear la clase org.springframework.test.context.junit4.SpringJUnit4ClassRunner en su aplicación para que esta clase se cargue antes que la real desde jar. Luego reescribe métodos o constructores.

Atención: este es un truco absoluto, y NO se recomienda su uso, ¡pero FUNCIONA! El uso de este enfoque es peligroso debido a posibles problemas con los cargadores de clases. Además, esto puede causar problemas cada vez que actualice la biblioteca que contiene una clase sobrescrita.

He tenido situaciones como estas cuando la arquitectura es crear una funcionalidad común en una CustomBaseClass común que implementa en nombre de varias clases derivadas. Sin embargo, debemos evitar la lógica común para un método específico para una clase derivada específica. En tales casos, debemos usar una implementación super.super.methodX.

Logramos esto mediante la introducción de un miembro booleano en CustomBaseClass, que se puede usar para diferir selectivamente la implementación personalizada y ceder a la implementación de marco predeterminada cuando sea deseable.

        ...
        FrameworkBaseClass (....) extends...
        {
           methodA(...){...}
           methodB(...){...}
        ...
           methodX(...)
        ...
           methodN(...){...}

        }
        /* CustomBaseClass overrides default framework functionality for benefit of several derived classes.*/
        CustomBaseClass(...) extends FrameworkBaseClass 
        {
        private boolean skipMethodX=false; 
        /* implement accessors isSkipMethodX() and setSkipMethodX(boolean)*/

           methodA(...){...}
           methodB(...){...}
        ...
           methodN(...){...}

           methodX(...){
                  if (isSkipMethodX()) {
                       setSKipMethodX(false);
                       super.methodX(...);
                       return;
                       }
                   ... //common method logic
            }
        }

        DerivedClass1(...) extends CustomBaseClass
        DerivedClass2(...) extends CustomBaseClass 
        ...
        DerivedClassN(...) extends CustomBaseClass...

        DerivedClassX(...) extends CustomBaseClass...
        {
           methodX(...){
                  super.setSKipMethodX(true);
                  super.methodX(...);
                       }
        }

Sin embargo, con buenos principios de arquitectura seguidos tanto en el marco como en la aplicación, podríamos evitar tales situaciones fácilmente, usando el enfoque hasA, en lugar del enfoque isA. Pero en todo momento no es muy práctico esperar una arquitectura bien diseñada y, por lo tanto, la necesidad de alejarse de principios de diseño sólidos e introducir hacks como este. Solo mis 2 centavos ...

@ Jon Skeet Buena explicación. En mi opinión, si alguien quiere llamar al método super.super, entonces uno debe querer ignorar el comportamiento del padre inmediato, pero quiere acceder al comportamiento del padre principal. Esto se puede lograr a través de la instancia de. Como abajo código

public class A {
    protected void printClass() {
        System.out.println("In A Class");
    }
}

public class B extends A {

    @Override
    protected void printClass() {
        if (!(this instanceof C)) {
            System.out.println("In B Class");
        }
        super.printClass();
    }
}

public class C extends B {
    @Override
    protected void printClass() {
        System.out.println("In C Class");
        super.printClass();
    }
}

Aquí está la clase de conductor,

public class Driver {
    public static void main(String[] args) {
        C c = new C();
        c.printClass();
    }
}

La salida de esto será

In C Class
In A Class

El comportamiento de clase B printClass se ignorará en este caso. No estoy seguro de si es una práctica ideal o buena para lograr super.super, pero aún funciona.

Si cree que va a necesitar la superclase, puede hacer referencia a ella en una variable para esa clase. Por ejemplo:

public class Foo
{
  public int getNumber()
  {
    return 0;
  }
}

public class SuperFoo extends Foo
{
  public static Foo superClass = new Foo();
  public int getNumber()
  {
    return 1;
  }
}

public class UltraFoo extends Foo
{
  public static void main(String[] args)
  {
    System.out.println(new UltraFoo.getNumber());
    System.out.println(new SuperFoo().getNumber());
    System.out.println(new SuperFoo().superClass.getNumber());
  }
  public int getNumber()
  {
    return 2;
  }
}

Debe imprimir:

2
1
0

En mi opinión, es una forma limpia de lograr un super.super.sayYourName()comportamiento en Java.

public class GrandMa {  
    public void sayYourName(){  
        System.out.println("Grandma Fedora");  
    }  
}  

public class Mama extends GrandMa {  
    public void sayYourName(boolean lie){  
        if(lie){   
            super.sayYourName();  
        }else {  
            System.out.println("Mama Stephanida");  
        }  
    }  
}  

public class Daughter extends Mama {  
    public void sayYourName(boolean lie){  
        if(lie){   
            super.sayYourName(lie);  
        }else {  
            System.out.println("Little girl Masha");  
        }  
    }  
}  

public class TestDaughter {
    public static void main(String[] args){
        Daughter d = new Daughter();

        System.out.print("Request to lie: d.sayYourName(true) returns ");
        d.sayYourName(true);
        System.out.print("Request not to lie: d.sayYourName(false) returns ");
        d.sayYourName(false);
    }
}

Salida:

Request to lie: d.sayYourName(true) returns Grandma Fedora
Request not to lie: d.sayYourName(false) returns Little girl Masha

Creo que este es un problema que rompe el acuerdo de herencia.
Al extender una clase, obedece / acuerda su comportamiento, características
Mientras que cuando llama super.super.method(), quiere romper su propio acuerdo de obediencia.

Simplemente no puedes elegir entre la súper clase .

Sin embargo, pueden ocurrir situaciones en las que sienta la necesidad de llamar super.super.method(), ¡generalmente un signo de diseño incorrecto, en su código o en el código que hereda!
Si las clases super y super super no se pueden refactorizar (algún código heredado), entonces opte por la composición sobre la herencia.

La ruptura de la encapsulación se produce cuando se omiten algunos métodos rompiendo el código encapsulado. Los métodos diseñados para no ser anulados se marcan como finales .

En C # puede llamar a un método de cualquier antepasado como este:

public class A
    internal virtual void foo()
...
public class B : A
    public new void foo()
...
public class C : B
    public new void foo() {
       (this as A).foo();
    }

También puedes hacer esto en Delphi:

type
   A=class
      procedure foo;
      ...
   B=class(A)
     procedure foo; override;
     ...
   C=class(B)
     procedure foo; override;
     ...
A(objC).foo();

Pero en Java puedes hacer ese enfoque solo con algún equipo. Una forma posible es:

class A {               
   int y=10;            

   void foo(Class X) throws Exception {  
      if(X!=A.class)
         throw new Exception("Incorrect parameter of "+this.getClass().getName()+".foo("+X.getName()+")");
      y++;
      System.out.printf("A.foo(%s): y=%d\n",X.getName(),y);
   }
   void foo() throws Exception { 
      System.out.printf("A.foo()\n");
      this.foo(this.getClass()); 
   }
}

class B extends A {     
   int y=20;            

   @Override
   void foo(Class X) throws Exception { 
      if(X==B.class) { 
         y++; 
         System.out.printf("B.foo(%s): y=%d\n",X.getName(),y);
      } else { 
         System.out.printf("B.foo(%s) calls B.super.foo(%s)\n",X.getName(),X.getName());
         super.foo(X);
      } 
   }
}

class C extends B {     
   int y=30;            

   @Override
   void foo(Class X) throws Exception { 
      if(X==C.class) { 
         y++; 
         System.out.printf("C.foo(%s): y=%d\n",X.getName(),y);
      } else { 
         System.out.printf("C.foo(%s) calls C.super.foo(%s)\n",X.getName(),X.getName());
         super.foo(X);
      } 
   }

   void DoIt() {
      try {
         System.out.printf("DoIt: foo():\n");
         foo();         
         Show();

         System.out.printf("DoIt: foo(B):\n");
         foo(B.class);  
         Show();

         System.out.printf("DoIt: foo(A):\n");
         foo(A.class);  
         Show();
      } catch(Exception e) {
         //...
      }
   }

   void Show() {
      System.out.printf("Show: A.y=%d, B.y=%d, C.y=%d\n\n", ((A)this).y, ((B)this).y, ((C)this).y);
   }
} 

Resultado del resultado objC.DoIt ():

DoIt: foo():
A.foo()
C.foo(C): y=31
Show: A.y=10, B.y=20, C.y=31

DoIt: foo(B):
C.foo(B) calls C.super.foo(B)
B.foo(B): y=21
Show: A.y=10, B.y=21, C.y=31

DoIt: foo(A):
C.foo(A) calls C.super.foo(A)
B.foo(A) calls B.super.foo(A)
A.foo(A): y=11
Show: A.y=11, B.y=21, C.y=31

Es simplemente fácil de hacer. Por ejemplo:

C subclase de B y B subclase de A. Ambos tienen el método methodName () por ejemplo.

public abstract class A {

    public void methodName() {
        System.out.println("Class A");
    }

}

public class B extends A {

    public void methodName() {
        super.methodName();
        System.out.println("Class B");
    }

    // Will call the super methodName
    public void hackSuper() {
        super.methodName();
    }

}

public class C extends B {

    public static void main(String[] args) {
        A a = new C();
        a.methodName();
    }

    @Override
    public void methodName() {
        /*super.methodName();*/
        hackSuper();
        System.out.println("Class C");
    }

}

Ejecutar clase C La salida será: Clase A Clase C

En lugar de salida: Clase A Clase B Clase C

public class SubSubClass extends SubClass {

    @Override
    public void print() {
        super.superPrint();
    }

    public static void main(String[] args) {
        new SubSubClass().print();
    }
}

class SuperClass {

    public void print() {
        System.out.println("Printed in the GrandDad");
    }
}

class SubClass extends SuperClass {

    public void superPrint() {
        super.print();
    }
}

Salida: Impreso en el GrandDad

La palabra clave super es solo una forma de invocar el método en la superclase. En el tutorial de Java: https://docs.oracle.com/javase/tutorial/java/IandI/super.html

Si su método anula uno de los métodos de su superclase, puede invocar el método anulado mediante el uso de la palabra clave super.

¡No creas que es una referencia del súper objeto! No, es solo una palabra clave para invocar métodos en la superclase.

Aquí hay un ejemplo:

class Animal {
    public void doSth() {
        System.out.println(this);   // It's a Cat! Not an animal!
        System.out.println("Animal do sth.");
    }
}

class Cat extends Animal {
    public void doSth() {
        System.out.println(this);
        System.out.println("Cat do sth.");
        super.doSth();
    }
}

Cuando llame cat.doSth(), se imprimirá el método doSth()en clase y es un gato.Animalthis