java - settitle - Comportamiento del método estático final

para que sirve settitle en java

Question

He estado jugando con modificadores con método estático y encontré un comportamiento extraño.

Como sabemos, los métodos estáticos no pueden anularse, ya que están asociados con la clase en lugar de la instancia.

Entonces, si tengo el siguiente fragmento, compila bien

//Snippet 1 - Compiles fine
public class A {
static void ts() {
}
}
class B extends A {
static void ts() {
}
}

Pero si incluyo el modificador final en el método estático en la clase A, entonces la compilación falla ts () en B no puede anular ts () en A; el método reemplazado es estático final .

¿Por qué sucede esto cuando el método estático no puede anularse en absoluto?

Answer 1

los métodos estáticos no pueden ser anulados

Esto no es exactamente cierto. El código de ejemplo realmente significa que el método ts en B oculta el método ts en A. Por lo tanto, no es la anulación exacta. En Javaranch hay una buena explicación.

Answer 2

Creo que el error de compilación fue bastante engañoso aquí. No debería haber dicho "el método reemplazado es estático final", sino que debería haber dicho "el método reemplazado es definitivo". El modificador estático es irrelevante aquí.

Answer 3

El método ts () en B no anula el método ts () en A, simplemente es otro método. La clase B no ve el método ts () en A ya que es estático, por lo tanto puede declarar su propio método llamado ts ().

Sin embargo, si el método es final, el compilador detectará que hay un método ts () en A que no se debe anular en B.

Answer 4

Los métodos estáticos no pueden anularse, pero pueden ocultarse. El método ts() de B no anula (no está sujeto a polimorfismo) el ts() de A pero lo ocultará. Si llama a ts() en B (NO A.ts() o B.ts() ... simplemente ts() ), se llamará a la de B y no a A. Como esto no está sujeto a polimorfismo, el la llamada ts() en A nunca será redireccionada a la de B.

La palabra clave final desactivará el método para que no se oculte. Por lo tanto, no se pueden ocultar y un intento de hacerlo generará un error de compilación.

Espero que esto ayude.

Answer 5

Los métodos estáticos pertenecen a la clase, no a la instancia.

A.ts() y B.ts() siempre serán métodos separados.

El verdadero problema es que Java le permite llamar a métodos estáticos en un objeto instancia. Los métodos estáticos con la misma firma de la clase padre se hidden cuando se los llama desde una instancia de la subclase. Sin embargo, no puede anular / ocultar los métodos finales .

Pensarías que el mensaje de error usaría la palabra oculto en lugar de anular ...

Answer 6

Puede encontrarse en la posición de pensar en hacer que un método estático sea definitivo, teniendo en cuenta lo siguiente:

Tener las siguientes clases:

class A {
static void ts() {
System.out.print("A");
}
}
class B extends A {
static void ts() {
System.out.print("B");
}
}

Ahora la forma "correcta" de llamar a estos métodos sería

A.ts();
B.ts();

lo que daría como resultado AB pero también podría llamar a los métodos en instancias:

A a = new A();
a.ts();
B b = new B();
b.ts();

lo que resultaría en AB también.

Ahora considera lo siguiente:

A a = new B();
a.ts();

eso imprimiría A Eso podría sorprenderte ya que en realidad tienes un objeto de clase B Pero como lo está llamando desde una referencia de tipo A , llamará a A.ts() . Puede imprimir B con el siguiente código:

A a = new B();
((B)a).ts();

En ambos casos, el objeto que tienes es en realidad de la clase B Pero dependiendo del puntero que apunta al objeto, llamarás al método desde A o desde B

Ahora digamos que usted es el desarrollador de la clase A y desea permitir la subclasificación. Pero realmente quiere el método ts() , siempre que se le llame, incluso desde una subclase, que haga lo que quiera que haga y que no esté oculto por una versión de subclase. Entonces podrías hacer que sea final e impedir que se oculte en la subclase. Y puede estar seguro de que el siguiente código llamará al método de su clase A :

B b = new B();
b.ts();

Ok, de manera puntual eso está de alguna manera construido, pero podría tener sentido en algunos casos.

No debe llamar a métodos estáticos en instancias sino directamente en las clases, entonces no tendrá ese problema. También IntelliJ IDEA, por ejemplo, le mostrará una advertencia, si llama a un método estático en una instancia y también si hace un método estático final.