Java: llamar a un supermétodo que llama a un método anulado

public class SuperClass
{
    public void method1()
    {
        System.out.println("superclass method1");
        this.method2();
    }

    public void method2()
    {
        System.out.println("superclass method2");
    }

}

public class SubClass extends SuperClass
{
    @Override
    public void method1()
    {
        System.out.println("subclass method1");
        super.method1();
    }

    @Override
    public void method2()
    {
        System.out.println("subclass method2");
    }
}



public class Demo 
{
    public static void main(String[] args) 
    {
        SubClass mSubClass = new SubClass();
        mSubClass.method1();
    }
}

mi salida esperada:

subclase método1
superclase método1
superclase método2

salida real:

subclase método1
superclase método1
subclase método2

Sé que técnicamente he anulado un método público, pero pensé que debido a que estaba llamando al super, cualquier llamada dentro del super permanecería en el super, esto no está sucediendo. ¿Alguna idea de cómo puedo hacer que suceda?

La palabra clave superno "se pega". Cada llamada a método se maneja individualmente, por lo que incluso si lo hiciste SuperClass.method1()llamando super, eso no influye en ninguna otra llamada a método que puedas realizar en el futuro.

Eso significa que no hay una forma directa para llamar SuperClass.method2()desde SuperClass.method1()sin ir aunque SubClass.method2()menos que usted está trabajando con una instancia real de SuperClass.

Ni siquiera puede lograr el efecto deseado usando Reflection (consulte la documentación dejava.lang.reflect.Method.invoke(Object, Object...) ).

[EDITAR] Todavía parece haber cierta confusión. Déjame intentar una explicación diferente.

Cuando invocas foo(), en realidad invocas this.foo(). Java simplemente le permite omitir elthis . En el ejemplo de la pregunta, el tipo de thises SubClass.

Entonces, cuando Java ejecuta el código en SuperClass.method1() , finalmente llega athis.method2();

El uso superno cambia la instancia a la que apunta this. Entonces la llamada va aSubClass.method2() ya que thises de tipo SubClass.

Tal vez sea más fácil de entender cuando imagina que Java pasa this como un primer parámetro oculto:

public class SuperClass
{
    public void method1(SuperClass this)
    {
        System.out.println("superclass method1");
        this.method2(this); // <--- this == mSubClass
    }

    public void method2(SuperClass this)
    {
        System.out.println("superclass method2");
    }

}

public class SubClass extends SuperClass
{
    @Override
    public void method1(SubClass this)
    {
        System.out.println("subclass method1");
        super.method1(this);
    }

    @Override
    public void method2(SubClass this)
    {
        System.out.println("subclass method2");
    }
}



public class Demo 
{
    public static void main(String[] args) 
    {
        SubClass mSubClass = new SubClass();
        mSubClass.method1(mSubClass);
    }
}

Si sigue la pila de llamadas, puede ver que thisnunca cambia, siempre es la instancia creada en main().

Solo puede acceder a los métodos reemplazados en los métodos de reemplazo (o en otros métodos de la clase de reemplazo).

Entonces: o no anule method2()o llame super.method2()dentro de la versión anulada.

Estás usando la thispalabra clave que en realidad se refiere a la "instancia en ejecución del objeto que estás usando", es decir, estás invocando this.method2();en tu superclase, es decir, llamará al método2 () en el objeto que ' que está usando, que es la subclase.

Lo pienso de esta manera

+----------------+
|     super      |
+----------------+ <-----------------+
| +------------+ |                   |
| |    this    | | <-+               |
| +------------+ |   |               |
| | @method1() | |   |               |
| | @method2() | |   |               |
| +------------+ |   |               |
|    method4()   |   |               |
|    method5()   |   |               |
+----------------+   |               |
    We instantiate that class, not that one!

Déjame mover esa subclase un poco hacia la izquierda para revelar lo que hay debajo ... (Hombre, me encantan los gráficos ASCII)

We are here
        |
       /  +----------------+
      |   |     super      |
      v   +----------------+
+------------+             |
|    this    |             |
+------------+             |
| @method1() | method1()   |
| @method2() | method2()   |
+------------+ method3()   |
          |    method4()   |
          |    method5()   |
          +----------------+

Then we call the method
over here...
      |               +----------------+
 _____/               |     super      |
/                     +----------------+
|   +------------+    |    bar()       |
|   |    this    |    |    foo()       |
|   +------------+    |    method0()   |
+-> | @method1() |--->|    method1()   | <------------------------------+
    | @method2() | ^  |    method2()   |                                |
    +------------+ |  |    method3()   |                                |
                   |  |    method4()   |                                |
                   |  |    method5()   |                                |
                   |  +----------------+                                |
                   \______________________________________              |
                                                          \             |
                                                          |             |
...which calls super, thus calling the super's method1() here, so that that
method (the overidden one) is executed instead[of the overriding one].

Keep in mind that, in the inheritance hierarchy, since the instantiated
class is the sub one, for methods called via super.something() everything
is the same except for one thing (two, actually): "this" means "the only
this we have" (a pointer to the class we have instantiated, the
subclass), even when java syntax allows us to omit "this" (most of the
time); "super", though, is polymorphism-aware and always refers to the
superclass of the class (instantiated or not) that we're actually
executing code from ("this" is about objects [and can't be used in a
static context], super is about classes).

En otras palabras, citando la especificación del lenguaje Java :

El formulario se super.Identifierrefiere al campo denominadoIdentifier del objeto actual, pero con el objeto actual visto como una instancia de la superclase de la clase actual.

La forma se T.super.Identifierrefiere al campo nombrado Identifierde la instancia que encierra léxicamente correspondiente a T, pero con esa instancia vista como una instancia de la superclase de T.

En términos thissencillos , es básicamente un objeto (* el ** objeto; el mismo objeto que se puede mover en variables), la instancia de la clase instanciada, una variable simple en el dominio de datos; superes como un puntero a un bloque de código prestado que desea que se ejecute, más como una mera llamada a función, y es relativo a la clase donde se llama.

Por lo tanto, si usa superde la superclase, obtiene código de la clase superduper [el abuelo] ejecutado), mientras que si usa this(o si se usa implícitamente) de una superclase, sigue apuntando a la subclase (porque nadie lo ha cambiado, y nadie podría).

Si no desea que superClass.method1 llame a subClass.method2, haga que el método2 sea privado para que no se pueda anular.

He aquí una sugerencia:

public class SuperClass {

  public void method1() {
    System.out.println("superclass method1");
    this.internalMethod2();
  }

  public void method2()  {
    // this method can be overridden.  
    // It can still be invoked by a childclass using super
    internalMethod2();
  }

  private void internalMethod2()  {
    // this one cannot.  Call this one if you want to be sure to use
    // this implementation.
    System.out.println("superclass method2");
  }

}

public class SubClass extends SuperClass {

  @Override
  public void method1() {
    System.out.println("subclass method1");
    super.method1();
  }

  @Override
  public void method2() {
    System.out.println("subclass method2");
  }
}

Si no funcionara de esta manera, el polimorfismo sería imposible (o al menos ni la mitad de útil).

Dado que la única forma de evitar que un método se anule es usar la palabra clave super , he pensado en subir el método2 () de SuperClass a otra nueva clase Base y luego llamarlo desde SuperClass :

class Base 
{
    public void method2()
    {
        System.out.println("superclass method2");
    }
}

class SuperClass extends Base
{
    public void method1()
    {
        System.out.println("superclass method1");
        super.method2();
    }
}

class SubClass extends SuperClass
{
    @Override
    public void method1()
    {
        System.out.println("subclass method1");
        super.method1();
    }

    @Override
    public void method2()
    {
        System.out.println("subclass method2");
    }
}

public class Demo 
{
    public static void main(String[] args) 
    {
        SubClass mSubClass = new SubClass();
        mSubClass.method1();
    }
}

Salida:

subclass method1
superclass method1
superclass method2

this siempre se refiere al objeto que se está ejecutando actualmente.

Para ilustrar más el punto, aquí hay un bosquejo simple:

+----------------+
|  Subclass      |
|----------------|
|  @method1()    |
|  @method2()    |
|                |
| +------------+ |
| | Superclass | |
| |------------| |
| | method1()  | |
| | method2()  | |
| +------------+ |
+----------------+

Si tiene una instancia de la caja exterior, un Subclassobjeto, dondequiera que se aventure dentro de la caja, incluso en el Superclass'área', sigue siendo la instancia de la caja exterior.

Además, en este programa solo hay un objeto que se crea de las tres clases, por thislo que solo puede hacer referencia a una cosa y es:

como se muestra en "Heap Walker" de Netbeans .

class SuperClass
{
    public void method1()
    {
        System.out.println("superclass method1");
        SuperClass se=new SuperClass();
        se.method2();
    }

    public void method2()
    {
        System.out.println("superclass method2");
    }
}


class SubClass extends SuperClass
{
    @Override
    public void method1()
    {
        System.out.println("subclass method1");
        super.method1();
    }

    @Override
    public void method2()
    {
        System.out.println("subclass method2");
    }
}

vocación

SubClass mSubClass = new SubClass();
mSubClass.method1();

salidas

subclase método1
superclase método1
superclase método2

No creo que puedas hacerlo directamente. Una solución alternativa sería tener una implementación interna privada del método2 en la superclase y llamar a eso. Por ejemplo:

public class SuperClass
{
    public void method1()
    {
        System.out.println("superclass method1");
        this.internalMethod2();
    }

    public void method2()
    {
        this.internalMethod2(); 
    }
    private void internalMethod2()
    {
        System.out.println("superclass method2");
    }

}

"esta" palabra clave se refiere a la referencia de clase actual. Eso significa que, cuando se usa dentro del método, la clase 'actual' sigue siendo SubClass y, por lo tanto, se explica la respuesta.

Para resumir, esto apunta al objeto actual y la invocación del método en Java es polimórfica por naturaleza. Entonces, la selección del método para la ejecución depende totalmente del objeto señalado por este. Por lo tanto, la invocación del método method2 () de la clase principal invoca el método2 () de la clase secundaria, ya que this apunta al objeto de la clase secundaria. La definición de esto no cambia, independientemente de la clase que se use.

PD. a diferencia de los métodos, las variables miembro de clase no son polimórficas.

Durante mi investigación para un caso similar, terminé verificando el seguimiento de la pila en el método de subclase para averiguar de dónde proviene la llamada. Probablemente haya formas más inteligentes de hacerlo, pero me funciona y es un enfoque dinámico.

public void method2(){
        Exception ex=new Exception();
        StackTraceElement[] ste=ex.getStackTrace();
        if(ste[1].getClassName().equals(this.getClass().getSuperclass().getName())){
            super.method2();
        }
        else{
            //subclass method2 code
        }
}

Creo que la cuestión de tener una solución para el caso es razonable. Por supuesto, hay formas de resolver el problema con diferentes nombres de métodos o incluso con diferentes tipos de parámetros, como ya se mencionó en el hilo, pero en mi caso no me gustaría confundir con diferentes nombres de métodos.

Más extendido el resultado de la pregunta planteada, esto dará más información sobre el especificador de acceso y el comportamiento de anulación.

            package overridefunction;
            public class SuperClass 
                {
                public void method1()
                {
                    System.out.println("superclass method1");
                    this.method2();
                    this.method3();
                    this.method4();
                    this.method5();
                }
                public void method2()
                {
                    System.out.println("superclass method2");
                }
                private void method3()
                {
                    System.out.println("superclass method3");
                }
                protected void method4()
                {
                    System.out.println("superclass method4");
                }
                void method5()
                {
                    System.out.println("superclass method5");
                }
            }

            package overridefunction;
            public class SubClass extends SuperClass
            {
                @Override
                public void method1()
                {
                    System.out.println("subclass method1");
                    super.method1();
                }
                @Override
                public void method2()
                {
                    System.out.println("subclass method2");
                }
                // @Override
                private void method3()
                {
                    System.out.println("subclass method3");
                }
                @Override
                protected void method4()
                {
                    System.out.println("subclass method4");
                }
                @Override
                void method5()
                {
                    System.out.println("subclass method5");
                }
            }

            package overridefunction;
            public class Demo 
            {
                public static void main(String[] args) 
                {
                    SubClass mSubClass = new SubClass();
                    mSubClass.method1();
                }
            }

            subclass method1
            superclass method1
            subclass method2
            superclass method3
            subclass method4
            subclass method5