No he probado la respuesta de WhiteFang34. Podría funcionar, pero no lo tengo claro ...
Si realmente desea definir una extensión de su clase interna en otro lugar que en la clase externa, lo más natural sería definirlo como una extensión de la clase interna en otra ampliación de su clase externa externa de la siguiente manera:
class Outer {
int some_member;
abstract class InnerBase {
abstract void method();
}
}
class OuterExtendsOuter extends Outer {
class InnerExtendsInner extends Outer.InnerBase {
void method() {
System.out.println(some_member);
}
}
}
que en realidad no ha ejecutado este código sea, pero debería funcionar.
Actualización:
Basado en el hilo de comentarios, ahora han compilado y ejecutado tanto mi código y el código de WhiteFang34.
Tanto en el trabajo hecho, pero como se ha señalado en los comentarios de Paulo Ebermann, tanto para crear dos copias del exterior dentro de la clase interna instancia.
voy a upvote respuesta de Paulo, y estaría a favor de no tratar de hacerlo por cualquiera de táctica, ya que es realmente un abuso del mecanismo de clase interna.
Simplemente haga su clases internas extendidas viven dentro de la misma clase externa!
Actualización 2:
lo que sucede en mi código, basado en el examen de tiempo de ejecución utilizando un depurador y en el examen de la salida de las inspecciones javap de las clases, es que tanto InnerBase
y OuterExtendsOuter$InnerExtendsInner
tienen campos final privado sintéticas nombradas this$0
. Debido a que no hay constructores se definen explícitamente, se utilizan los constructores por defecto, y el fragmento de código
OuterExtendsOuter outer = new OuterExtendsOuter();
Outer.InnerBase inner = outer.new InnerExtendsInner();
hace que estos dos campos a la vez referencia outer
.
En otras palabras, el comentario de Paŭlo es completamente correcto.
Por la experimentación, la misma que realmente sucede si extiende InnerBase
en otra clase interna de Outer
, por lo que tiene poco que ver con lo que se define de la misma clase externa o una extensión de la misma, sino que es, de hecho, un resultado de cómo se manejan generalmente las clases internas no estáticas.
Sospecho que esto está documentado en alguna parte, pero no he visto eso.
¡Probablemente lo mejor es mezclar la herencia y las clases internas lo menos posible!
"Mejor organización de código" rara vez implica clases internas, y no puedo imaginar que alguna vez involucre algo como esto. – Anon
Es por eso que quería extender la clase interna fuera de la clase externa. Estoy implementando un intérprete, y cada clase "interna" modela un tipo (nombre, número entero, etc.). El comportamiento del tipo puede necesitar o no una referencia al objeto del intérprete que lo creó. He repasado el problema pasando una referencia de intérprete a cada método que pueda necesitarlo. – zvrba