10
votes

Pourquoi les classes compilent pour .class mais l'interface ne signifie pas .Interface

Y a-t-il une raison spécifique pour laquelle les interfaces ne sont pas compilées dans MyInterface.java compilée dans un fichier .interface? Mais n'importe quelle classe est compilée dans un fichier .class.!


2 commentaires

Pour la même raison qu'un objet java.lang.class peut représenter une classe, une interface, un type d'annotation ou un type d'énum.


Et le nom du fichier est toujours ".java" quel que soit le type de classe.


6 Réponses :


3
votes

en Java, vous avez des fichiers source, appelés .java et binaires appelés .Class. C'est juste un choix de nommage.

Aussi pour les classes Java et l'interface ne diffèrent pas autant (une classe contient simplement de nombreuses informations supplémentaires telles que les organes de méthodes).


1 commentaires

Pourquoi je dis que c'est que pendant que nous allons par réflexion basé sur une extension de fichier, il sera clairement distinguable. Son aspect de celui-ci. Quoi qu'il en soit, ma question reste toujours, les personnes qui ont développé Java (Previoulsy Oak) ne veulent-elles pas distinguer en fonction du système de fichiers?



6
votes

la la représentation physique de l'octet-code sur le système de fichiers n'a pas d'importance.

C'est la la réalisation logique (que ce soit la classe ou l'interface) qui compte.


1 commentaires

La bonne réponse, je pense - de ce que je me souviens de la spécification de langue Java, la manière dont la sortie du compilateur est stockée sur le système de fichiers ne fait pas partie de la définition de la langue. C'est juste une convention commune. Mais les fichiers de classe pourraient être écrits directement dans une base de données géniale.



6
votes

Java traite des interfaces presque comme des classes, par exemple, partager la même espace de noms (vous ne pouvez pas avoir une interface qui a le même nom que de classe) et une interface compilée est presque identique à une classe abstraite compilée.

Donc, cela n'aurait aucun sens de les stocker dans un format différent ou avec une extension de fichier différente. Au contraire, cela rendrait beaucoup de choses plus difficiles. Par exemple, lorsque vous chargez une classe ou une interface par nom (class.forname ("my.class.name")) Java ne sais pas s'il s'agit d'une classe ou d'une interface. S'il y aurait deux extensions différentes, Java aurait essayé de trouver un fichier "My / Classe / nom.class", puis "Mon / Classe / Nom.Interface", au lieu de n'essayer que le premier.


3 commentaires

Lors de la chargement de la chargeur de classe, sachez si sa classe ou une iterface.Il peut avoir des surcharges de DifferNT Tow Difface pour charger les fichiers.OOt concept que vous voyez :)


Je trouve cette étrange "interface compilée est presque identique à une classe abstraite compilée"? Les classes abstraites peuvent avoir des variables, des définitions de la méthode, etc.


Classe.Fornom () Vous ne pouvez pas savoir si l'argument est une classe ou une interface, lorsque vous n'avez donné que le nom comme chaîne. Sinon, vous auriez besoin d'une autre méthode d'interfaces (ou d'un paramètre indiquant le chargeur de classes à charger, ou une classe spéciale pour les interfaces). Bien sûr, Java aurait pu être conçu pour gérer des interfaces complètement différentes que des classes. Mais pourquoi le rendre compliqué s'il y a une solution plus facile?



4
votes

C'est la façon dont les concepteurs de langue ont décidé.

C'est logique de plusieurs manières:

  • .Class est un sous-produit que vous ne voyez pas ou ne manipule normalement pas à la main.
  • Les extensions moins différentes d'un programme utilisent, plus il est facile de maintenir.
  • Dans de nombreux cas, il n'y a pas de distinction dans le code entre une classe et une interface, il est donc logique que les fichiers binaires se ressemblent.

    Franchement, je ne peux pas penser à une bonne raison d'avoir différentes extensions pour les classes et interfaces compilées. Pourquoi serait-il important de distinguer entre eux?


1 commentaires

@ Eli, c'est juste le doute que j'ai eu parce que le tout premier moment je vois un fichier .Class je suppose que c'est une classe (juste mon mauvais avis peut être)



1
votes

C'est juste un choix qu'ils ont fait. Je ne me dérangerais pas à ce sujet. C'est un fichier binaire quand même. Une façon de penser est "Même c'est une interface, elle est toujours dans un fichier.java".


0 commentaires

16
votes

Parce que le point est d'indiquer que le fichier est code d'octet Java (et .Class a été l'extension choisi pour cela), pas la construction de langues spécifique.


0 commentaires