Pourquoi Java nous permet-il de compiler une classe avec un nom différent du nom du fichier ?

Question

J'ai un fichier Test.java et le code suivant à l'intérieur.

public class Abcd
{
        //some code here

}

La classe ne se compile pas, mais lorsque je supprime l'élément public il compile correctement.

Quelle est la raison pour laquelle Java nous permet de compiler un nom de classe qui est différent du nom du fichier lorsqu'il n'est pas public.

Je sais que c'est une question de débutant, mais je n'arrive pas à trouver une bonne explication.

Answer 1

La raison en est qu'il est possible d'avoir plus d'une classe de premier niveau par .java fichier.

De nombreuses classes, telles que les récepteurs d'événements, ne sont utilisées que localement et les premières versions de Java ne prenaient pas en charge les classes imbriquées. Sans cet assouplissement de la règle "nom de fichier = nom de classe", chacune de ces classes aurait nécessité son propre fichier, avec pour résultat inévitable une prolifération sans fin de petits fichiers .java et l'éparpillement du code étroitement couplé.

Dès que Java a introduit les classes imbriquées, l'importance de cette règle a considérablement diminué. Aujourd'hui, on peut parcourir des centaines de fichiers Java sans jamais tomber sur un seul qui en tire parti.

Answer 2

La raison est la même que pour les plaques de porte. Si une personne réside officiellement dans le bureau (déclaré public), son nom doit figurer sur la plaque de porte. Comme "Alex Jones" ou "Détective Colombo". Si une personne ne fait que visiter la pièce, parler à un fonctionnaire ou nettoyer le sol, son nom ne doit pas être officiellement inscrit sur la porte. Au lieu de cela, la porte peut indiquer "Services publics" ou "Salle de réunion".

Answer 3

La spécification Java stipule qu'il ne peut y avoir qu'une seule classe publique par fichier. Dans ce cas, le nom de la classe doit correspondre au nom du fichier. Toutes les classes non publiques peuvent porter n'importe quel nom, quel que soit le nom du fichier.

Answer 4

Je pense que les autoriser est une condition préalable à l'existence de classes imbriquées. Les classes anonymes, en particulier, réduisent considérablement le nombre de fichiers .java requis. Sans ce support, vous auriez besoin de nombreuses implémentations d'interfaces à méthode unique dans leurs propres fichiers séparés de la classe principale dans laquelle elles sont utilisées. (Je pense en particulier aux auditeurs d'action).

Il existe une bonne explication de toutes les classes imbriquées dans le document Classes imbriquées Tutoriel Java sur le site web d'Oracle, qui contient des exemples de chacun d'entre eux. Il explique également pourquoi ils sont utiles, ce que je vais citer :

Pourquoi utiliser des classes imbriquées ?

Les raisons qui justifient l'utilisation de classes imbriquées sont notamment les suivantes :

• Il s'agit d'un moyen de regrouper logiquement les classes qui ne sont utilisées qu'à un seul endroit. : Si une classe n'est utile qu'à une seule autre classe, il est logique de l'intégrer à cette dernière et de les garder ensemble. L'imbrication de ces "classes d'aide" permet de rationaliser leur package.

• Il augmente l'encapsulation : Considérons deux classes de premier niveau, A et B, où B a besoin d'accéder à des membres de A qui, autrement, seraient déclarés privés. En cachant la classe B dans la classe A, les membres de A peuvent être A peuvent être déclarés privés et B peut y accéder. En outre, B lui-même peut être cachée du monde extérieur.

• Elle peut conduire à un code plus lisible et plus facile à maintenir. : L'imbrication de petites classes dans des classes de niveau supérieur permet de rapprocher le code de l'endroit où il est utilisé. utilisé.

(souligné par moi)

Je ne connais pas bien la spécification Java des premiers jours, mais une recherche rapide montre que les classes internes ont été ajoutées dans Java 1.1.

Answer 5

Je vois les choses dans l'autre sens. L'état naturel des choses serait que le programmeur choisisse à la fois le nom de la classe et le nom du fichier indépendamment l'un de l'autre. Probablement pour simplifier la recherche de classes publiques en dehors d'un paquetage lors de la compilation, il existe une restriction spéciale selon laquelle une classe publique doit se trouver dans un fichier portant le nom correspondant.