Pourquoi un fichier source Java porte-t-il le nom de la classe publique qu'il contient?

Je suis un débutant qui apprend Java. En Java, chaque fichier source doit contenir une classe publique et ce fichier source doit avoir le même nom que cette classe publique. De plus, aucun fichier source ne peut contenir deux classes publiques. Pourquoi cette restriction?

java language-design

— utilisateur
source

Sans les détails, il s'agit d'un artefact de conception historique de la façon dont Java a été conçu. Les langages conçus plus récemment, comme C #, bien que similaires à Java, n'ont pas cette restriction.

— gahooa

N'est-ce pas pour faire appliquer les meilleures pratiques? Je pensais que c'était la seule raison. En C #, vous n'avez pas cette restriction au niveau technique, mais StyleCop se plaindra toujours si le nom de fichier et le nom de classe ne correspondent pas ou si vous avez plusieurs classes dans le même fichier. Visual Studio encourage également fortement la relation classe-fichier (pensez aux diagrammes de classe qui créent des fichiers pour vous, ou lorsque vous renommez le fichier .cs, Visual Studio vous demande si vous souhaitez également refactoriser le nom de la classe).

— Arseni Mourzenko

Dans un langage compilé à l'ancienne, l'éditeur de liens trouve toutes les références et symboles externes. Mais Java n'est pas lié - vous pouvez charger des jars au moment de l'exécution si vous le souhaitez. Sans étape de lien, essayer de mapper des noms de classe à des emplacements dans le chemin de classe est beaucoup plus rapide si vous savez quel nom de fichier rechercher.

— Paul Tomblin

@gahooa ce n'est pas un artefact de conception, c'est une décision délibérée de conception. Cela rend beaucoup de choses beaucoup plus faciles.

Et l'utilisation de grep ?

— utilisateur

Réponses:

Dans l'une de ses newsletters pour spécialistes Java, Heinz Kabutz fouille dans les spécifications du langage Oak . Il écrit:

Pourquoi chaque classe publique est-elle dans un fichier séparé? (Section 1)

C'est une question que l'on m'a souvent posée lors de mes cours. Jusqu'à présent, je n'ai pas eu de bonne réponse à cette question. Dans la section 1, nous lisons: "Bien que chaque unité de compilation Oak puisse contenir plusieurs classes ou interfaces, au plus une classe ou interface par unité de compilation peut être publique".

Dans la barre latérale, il explique pourquoi: "Cette restriction n'est pas encore appliquée par le compilateur, bien qu'elle soit nécessaire pour une importation efficace des packages"

C'est assez évident - comme la plupart des choses sont une fois que vous connaissez les raisons de conception - le compilateur devrait faire un passage supplémentaire à travers toutes les unités de compilation (fichiers .java) pour comprendre quelles classes étaient où, et cela rendrait la compilation encore plus lente .

http://www.javaspecialists.eu/archive/Issue055.html

— Landei
source

Pour rendre la compilation légèrement plus rapide? Vraiment? Pas parce que cela rend votre code beaucoup plus organisé? Je doute fortement que ce soit la bonne réponse.

— BlueRaja - Danny Pflughoeft

@ BlueRaja-DannyPflughoeft En 1998, je suis sûr que cela a fait une bien plus grande différence

— TheLQ

Raisons auxquelles je peux penser

Rend la recherche d'autres classes un peu plus facile pour le compilateur au début car il n'a pas à rechercher tous les milliers de fichiers de classe potentiellement pour une classe publique aléatoire, il peut simplement aller dans le fichier.
- Cela n'a probablement plus d'importance mais vient de commencer la première convention qui n'a jamais changé
Lors de la compilation, une modification d'un fichier affecte uniquement ce fichier. S'il y a plusieurs classes, tout doit être recompilé
Meilleure pratique - Avoir plusieurs classes publiques dans le même fichier rend les choses confuses. Le but des fichiers est d'organiser le code source, le but des dossiers est d'organiser les fichiers. Si toutes les classes d'un package particulier se trouvent dans un seul super fichier de 100 Mo, vous avez perdu tous les avantages et aucun avantage des fichiers (en plus d'ajouter beaucoup de maux de tête lors de l'édition)

— TheLQ
source

Les classes et les interfaces ne représentent pas nécessairement le niveau de subdivision le plus naturel pour le code source. Il n'est pas pratique d'avoir plusieurs milliers de lignes de code glommées dans un seul fichier, mais il en va de même pour le fait d'avoir 100 lignes de contenu "réel" (à l'exclusion des commentaires ou des directives de compilation dupliquées) réparties entre une douzaine de fichiers source. Je me demande comment cela fonctionnerait si un fichier nommé pour le type devait soit contenir la définition ou bien identifier le fichier qui fait?

— supercat