Pourquoi chaque classe publique se trouve-t-elle dans un fichier séparé ?

Question

J'ai récemment commencé à apprendre Java et j'ai trouvé très étrange que chaque classe Java doive être déclarée dans un fichier séparé. Je suis un programmeur C# et C# n'impose pas une telle restriction.

Pourquoi Java fait-il cela ? Y a-t-il eu des considérations de conception ?

Modifier (sur la base de quelques réponses) :

Pourquoi Java ne supprime-t-il pas cette restriction maintenant, à l'ère des IDE ? Cela ne cassera aucun code existant (ou si ?).

Answer 1

Je viens de prendre une solution C# et j'ai fait exactement cela (supprimer tous les fichiers qui contenaient plusieurs classes publiques) et je les ai réparties dans des fichiers individuels, ce qui m'a rendu la vie beaucoup plus facile.

Si vous avez plusieurs classes publiques dans un fichier, vous avez quelques problèmes :

1. Comment nommez-vous le fichier ? Une des classes publiques ? Un autre nom ? Les gens ont suffisamment de problèmes liés à la mauvaise organisation du code de la solution et aux conventions de dénomination des fichiers pour avoir un problème supplémentaire.

2. De même, lorsque vous naviguez dans l'explorateur de fichiers/projets, il est bon que les choses ne soient pas cachées. Par exemple, vous voyez un fichier et vous vous rendez compte qu'il y a 200 classes toutes mélangées ensemble. Si vous avez un fichier, une classe, vous pouvez mieux organiser vos tests et avoir une idée de la structure et de la complexité d'une solution.

Je pense que Java a raison.

Answer 2

Selon le Spécification du langage Java, troisième édition :

Cette restriction implique qu'il doit y avoir au maximum un tel type par unité de compilation. Cette restriction permet à un compilateur du langage de programmation Java ou à une implémentation de la machine virtuelle Java de trouver facilement une classe nommée dans un paquetage. ; par exemple, le code source d'un type public wet.sprocket.Toad se trouverait dans un fichier Toad.java dans le répertoire wet/sprocket, et le code objet correspondant se trouverait dans le fichier Toad.class dans le même répertoire.

C'est moi qui souligne.

Il semble qu'ils voulaient essentiellement traduire le séparateur de répertoire du système d'exploitation en points pour les espaces de noms, et vice versa.

Donc oui, c'était une sorte de considération de conception.

Answer 3

De Penser en Java

Il ne peut y avoir qu'une seule classe publique par unité de compilation (fichier).
L'idée est que chaque unité de compilation a une seule interface publique représentée par cette classe publique . Il peut avoir autant de classes "amies" de soutien que vous le souhaitez. Si vous avez plus d'une classe publique dans une unité de compilation, le compilateur vous donnera un message d'erreur.

---

Desde el spécification (7.2.6)

Lorsque les paquets sont stockés dans un système de fichiers (?7.2.1), le système hôte peut choisir pour appliquer la restriction selon laquelle il s'agit d'une erreur de compilation si un type n'est pas trouvé dans un fichier sous un nom composé du nom du type et d'une extension (telle que .java ou .jav) si l'une des conditions suivantes est remplie :

• Le type est référencé par le code dans d'autres unités de compilation du paquet dans lequel le type est déclaré.
• Le type est déclaré public (et est donc potentiellement accessible depuis le code d'autres paquets).
• Cette restriction implique qu'il doit y avoir au maximum un tel type par unité de compilation.
• Ce site permet à un compilateur du langage de programmation Java ou à une implémentation de la machine virtuelle Java de trouver facilement une classe nommée dans un paquetage. ; par exemple, le code source d'un type public wet.sprocket.Toad se trouverait dans un fichier Toad.java dans le répertoire wet/sprocket, et le code objet correspondant se trouverait dans le fichier Toad.class dans le même répertoire.

En bref, il s'agit peut-être de trouver des classes sans devoir tout charger dans le classpath.

Edit : "peut choisir" semble laisser la possibilité de no suivre cette restriction, et le sens de "peut" est probablement celui décrit dans RFC 2119 (c'est-à-dire "facultatif")
En pratique, cependant, cette règle est appliquée dans tant de plates-formes et utilisée par tant d'outils et d'IDE que je ne vois aucun "système hôte" choisir de no appliquer cette restriction.

---

De " Il était une fois un chêne ... "

C'est assez évident, comme la plupart des choses, une fois que l'on connaît les raisons de leur conception. le compilateur devrait effectuer un passage supplémentaire par toutes les unités de compilation (fichiers .java) pour déterminer quelles classes se trouvent à quel endroit, ce qui rendrait la compilation encore plus lente.

(Note :

el Spécification du langage Oak pour Oak version 0.2 (document postcript) : Chêne était le nom original de ce qui est maintenant communément appelé Java, et ce manuel est le plus ancien manuel disponible pour Oak (c'est-à-dire Java).
Pour en savoir plus sur les origines de Java, veuillez consulter le site suivant le projet vert y Technologie Java(TM) : Une histoire ancienne
)

Answer 4

C'est juste pour éviter toute confusion dans le sens où Java a été créé dans un souci de simplicité du point de vue du développeur. Vos classes "primaires" sont vos classes publiques et elles sont faciles à trouver (par un humain) si elles se trouvent dans un fichier portant le même nom et dans un répertoire spécifié par le package de la classe.

Vous devez vous rappeler que le langage Java a été développé au milieu des années 90, à l'époque où les IDE ne faisaient pas de la navigation et de la recherche dans le code un jeu d'enfant. .

Answer 5

Si une classe n'est utilisée que par une seule autre classe, faites-en une classe interne privée. De cette façon, vous avez vos multiples classes dans un seul fichier.

Si une classe est utilisée par plusieurs autres classes, laquelle de ces classes placeriez-vous dans le même fichier ? Toutes les trois ? Vous finiriez par avoir toutes vos classes dans un seul fichier...