Java: déclarations de classes multiples dans un fichier

Question

En Java, vous pouvez définir plusieurs haut niveau des classes dans un seul fichier, à condition que plus d'un de ces est public (voir JLS §7.6). Voir ci-dessous par exemple.

1. Est-il un bon nom pour cette technique (analogue inner, nested, anonymous)?

2. JL dit, le système peut appliquer la restriction que ces classes secondaires ne peuvent pas être referred to by code in other compilation units of the package, par exemple, ils ne peuvent pas être traités comme des colis-privé. Est-ce vraiment quelque chose qui change entre les implémentations Java?

par exemple, PublicClass.java:

package com.example.multiple;

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

class PrivateImpl {
    int implementationData;
}

Answer 1

javac n'est pas activement l'interdire, mais il a une limitation qui signifie en gros que vous ne voudrais jamais de se référer à un haut-niveau de la classe à partir d'un autre fichier, sauf si il a le même nom que le fichier est en.

Supposons que vous avez deux fichiers Foo.java et Bar.java.

Foo.java contient:

• public class Foo

Bar.java contient:

• public class Bar
• classe Baz

Disons aussi que toutes les classes sont dans le même package (et les fichiers sont dans le même répertoire).

Ce qui se passe si Foo.java se réfère à Baz, mais pas la Barre et nous essayons de compiler Foo.java? La compilation échoue avec un message d'erreur comme ceci:

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

Cela a un sens si vous pensez à ce sujet. Si Foo.java se réfère à Baz, mais il n'y a pas de Baz.java (ou Baz.class), comment peut-javac savoir ce fichier source pour look?

Si vous au lieu de dire javac pour compiler Foo.java et Bar.java en même temps, ou même si vous avez déjà compilé Bar.java (en laissant le Baz.class où javac pouvez le trouver) ce message d'erreur disparaît. Cela rend votre processus de construction de sens très fiable et squameuse, cependant.

Parce que la vraie limitation, qui est plus proche de "ne pas se référer à un haut-niveau de la classe à partir d'un autre fichier, sauf si il a le même nom que le fichier c'est ou vous êtes également en se référant à une classe qui est dans le même fichier nommé la même chose que le fichier" est assez difficile à suivre, les gens vont habituellement avec le plus simple (plus strict) de la convention de simplement mettre un haut-niveau de la classe dans chaque fichier. C'est mieux aussi si jamais vous changez d'avis quant à savoir si une classe doit être publique ou non.

Parfois, il y a vraiment une bonne raison pourquoi tout le monde fait quelque chose d'une manière particulière.

Answer 2

Mon nom suggéré pour cette technique serait "désordre". Sérieusement, je ne pense pas que ce soit une bonne idée - j'utiliserais plutôt un type imbriqué dans cette situation. Ensuite, il est toujours facile de prédire le fichier source dans lequel il se trouve.

Quant à savoir si cela change réellement entre les implémentations - j'en doute fortement, mais si vous évitez de le faire en premier lieu, vous n'aurez jamais besoin de faire attention :)

Answer 3

Je crois que vous appelez PrivateImpl il est: un non-public top-level class. Vous pouvez également déclarer non-public top-level interfaces .

par exemple, ailleurs sur DONC: Non-public de haut niveau de classe vs statique de la classe imbriquée

Comme pour les changements de comportement entre les versions, il y a eu cette discussion à propos de quelque chose qui "a parfaitement fonctionné" dans 1.2.2. mais arrêté de travailler en 1.4 dans le soleil du forum: Compilateur Java - impossible de déclarer un non publique de haut niveau des classes dans un fichier.

Answer 4

1.Est-il un bon nom pour cette technique (analogue à l'intérieur, imbriqués anonyme)?

Multi-classe unique fichier de démonstration.

2.JL dit, le système peut appliquer la restriction que ces classes secondaires ne peuvent pas être visées par le code dans d'autres unités de compilation du paquet, par exemple, ils ne peuvent pas être traités comme des colis-privé. Est-ce vraiment quelque chose qui change entre les implémentations Java?

Je ne suis pas au courant de tout ce qui n'a pas cette restriction - tous les fichier de base de compilateurs ne vous permet pas de consulter le code source des classes dans des fichiers qui ne sont pas le même nom que le nom de la classe. ( si vous compilez un multi-fichier de classe, et de mettre les classes sur le chemin de classe, puis tout le compilateur va les trouver )