txt - serializable java

Java: Múltiples declaraciones de clase en un archivo.

Question

En Java, puede definir varias clases de nivel superior en un solo archivo, siempre que como máximo una de ellas sea pública (consulte JLS §7.6 ). Vea a continuación por ejemplo.

1. ¿Hay un nombre ordenado para esta técnica (análogo a inner , nested , anonymous )?

2. El JLS dice que el sistema puede imponer la restricción de que no se puede hacer referred to by code in other compilation units of the package estas clases secundarias referred to by code in other compilation units of the package , por ejemplo, no pueden tratarse como paquetes privados. ¿Es eso realmente algo que cambia entre las implementaciones de Java?

Por ejemplo, PublicClass.java:

package com.example.multiple;

public class PublicClass {
    PrivateImpl impl = new PrivateImpl();
}

class PrivateImpl {
    int implementationData;
}

Answer 1

1. ¿Hay un nombre ordenado para esta técnica (análogo a interno, anidado, anónimo)?

Demostración de un solo archivo multi-clase.

2.El JLS dice que el sistema puede imponer la restricción de que no se puede hacer referencia a estas clases secundarias mediante el código en otras unidades de compilación del paquete, por ejemplo, no pueden tratarse como paquetes privados. ¿Es eso realmente algo que cambia entre las implementaciones de Java?

No tengo conocimiento de ninguna que no tenga esa restricción: todos los compiladores basados ​​en archivos no le permitirán referirse a clases de código fuente en archivos que no tengan el mismo nombre que el nombre de la clase. (Si compilas un archivo de varias clases y pones las clases en la ruta de clases, cualquier compilador las encontrará)

Answer 2

Creo que simplemente llama a PrivateImpl lo que es: una non-public top-level class . También puede declarar non-public top-level interfaces .

por ejemplo, en otro lugar en SO: clase no pública de nivel superior frente a clase anidada estática

En cuanto a los cambios en el comportamiento entre versiones, hubo una discusión sobre algo que "funcionó perfectamente" en 1.2.2. pero dejó de trabajar en 1.4 en el foro de sun: Java Compiler: no se pueden declarar clases de nivel superior no públicas en un archivo .

Answer 3

Mi nombre sugerido para esta técnica (incluidas varias clases de nivel superior en un solo archivo fuente) sería "desordenado". En serio, no creo que sea una buena idea, en su lugar usaría un tipo anidado en esta situación. Entonces aún es fácil predecir en qué archivo fuente se encuentra. Sin embargo, no creo que haya un término oficial para este enfoque.

En cuanto a si esto realmente cambia entre implementaciones, lo dudo mucho, pero si evita hacerlo en primer lugar, nunca tendrá que preocuparse :)

Answer 4

Puedes tener tantas clases como quieras así

public class Fun {
    Fun() {
        System.out.println("Fun constructor");
    }
    void fun() {
        System.out.println("Fun mathod");
    }
    public static void main(String[] args) {
        Fun fu = new Fun();
        fu.fun();
        Fen fe = new Fen();
        fe.fen();
        Fin fi = new Fin();
        fi.fin();
        Fon fo = new Fon();
        fo.fon();
        Fan fa = new Fan();
        fa.fan();
        fa.run();
    }
}

class Fen {
    Fen() {
        System.out.println("fen construuctor");

    }
    void fen() {
        System.out.println("Fen method");
    }
}

class Fin {
    void fin() {
        System.out.println("Fin method");
    }
}

class Fon {
    void fon() {
        System.out.println("Fon method");
    } 
}

class Fan {
    void fan() {
        System.out.println("Fan method");
    }
    public void run() {
        System.out.println("run");
    }
}

Answer 5

Sí, puede, con miembros públicos estáticos en una clase pública externa, como así:

public class Foo {

    public static class FooChild extends Z {
        String foo;
    }

    public static class ZeeChild extends Z {

    }

}

y otro archivo que hace referencia a lo anterior:

public class Bar {

    public static void main(String[] args){

        Foo.FooChild f = new Foo.FooChild();
        System.out.println(f);

    }
}

Ponlos en la misma carpeta. Compilar con:

javac folder/*.java

y correr con:

 java -cp folder Bar

Answer 6

Según la 2ª edición de Effective Java (Ítem 13):

"Si una clase de nivel superior (o interfaz) privada de un paquete es utilizada por una sola clase, considere hacer de la clase de nivel superior una clase anidada privada de la única clase que la usa (Artículo 22). Esto reduce su accesibilidad de todos las clases en su paquete a la clase que lo usa. Pero es mucho más importante reducir la accesibilidad de una clase pública gratuita que una clase privada de paquete de nivel superior: ... "

La clase anidada puede ser estática o no estática en función de si la clase miembro necesita acceso a la instancia adjunta (elemento 22).

Answer 7

javac no prohíbe activamente esto, pero tiene una limitación que significa que no querrás referirte a una clase de nivel superior desde otro archivo a menos que tenga el mismo nombre que el archivo en el que está.

Supongamos que tiene dos archivos, Foo.java y Bar.java.

Foo.java contiene:

• clase publica foo

Bar.java contiene:

• clase pública bar
• clase Baz

Digamos también que todas las clases están en el mismo paquete (y los archivos están en el mismo directorio).

¿Qué sucede si Foo.java se refiere a Baz pero no a Bar y tratamos de compilar Foo.java? La compilación falla con un error como este:

Foo.java:2: cannot find symbol
symbol  : class Baz
location: class Foo
  private Baz baz;
          ^
1 error

Esto tiene sentido si lo piensas. Si Foo.java se refiere a Baz, pero no hay Baz.java (o Baz.class), ¿cómo puede javac saber en qué archivo fuente buscar?

Si, en cambio, le dice a javac que compile Foo.java y Bar.java al mismo tiempo, o incluso si ya había compilado Bar.java (dejando el Baz.class donde javac puede encontrarlo), este error desaparece. Sin embargo, esto hace que tu proceso de construcción se sienta muy poco confiable y escamoso.

Debido a la limitación real, que es más bien "no se refiera a una clase de nivel superior de otro archivo a menos que tenga el mismo nombre que el archivo en el que está o también se está refiriendo a una clase que está en ese mismo archivo que se llama la misma cosa que el archivo "es un poco difícil de seguir, la gente suele ir con la convención mucho más directa (aunque más estricta) de simplemente poner una clase de nivel superior en cada archivo. Esto también es mejor si alguna vez cambia de opinión sobre si una clase debe ser pública o no.

A veces realmente hay una buena razón por la que todos hacen algo de una manera particular.