В Java имя файла должно совпадать с именем public class, содержащимся в этом файле. Почему это ограничение? Какую цель он выполняет?
Почему имена файлов в Java такие же, как и имя открытого класса?
Ответ 1
У Java был интересный подход: когда предоставление программисту выбора может только ухудшить качество программирования, удалите этот выбор.
Они сделали это в нескольких местах. Имена файлов и пакеты наверняка, но также не позволяющие нескольким публичным классам в файле (никогда не хороши), не позволяя вам разделить классы между файлами (черт побери, работать с!) И т.д.
Мне очень жаль, что они не пошли дальше. Нет никаких оснований для публичных переменных: я никогда не нуждался в нем, и я никогда не видел ситуации, когда какой-то умный программист считал, что он нужен, и был прав.
Я также не хотел бы видеть ограничения по размеру метода/класса, но это могло бы стать отрывочным (его можно было легко реализовать с помощью проверок кода, обычно проблема заключается в том, что компаниям, которые нуждаются в наибольшей помощи, те, кто не знает, что им нужно помогите и, следовательно, не используйте такие инструменты, как проверки кода).
Это не то, что важно для большинства небольших команд, но когда ваша команда растет и имеет несколько сайтов с консультантами из Индии, Китая и других других мест по всему миру, вы начнете ценить негибкость.
В ответ на сообщение сеттеров/геттеров:
Java-бобы были мерзостью, созданной Borland, чтобы взломать их графический интерфейс, а затем были переведены на Java.
Ужасная идея - отвлечение от программирования OO - Getters и seters A) показывают слишком много вашей реализации и B) заставляют вас думать оперировать данными другого объекта, а не просить другой объект выполнить операцию для вас. Плохой взлом для людей, которые еще не могут думать в OO.
Иногда бывает необходимо, чтобы геттеры были необходимы, но их нельзя добавлять, если их не считать абсолютно неизбежными.
Сеньоров следует избегать любой ценой. Если вам абсолютно необходимо внешнее изменение состояния после создания объекта, попробуйте использовать шаблон строителя и защитить ваши сеттеры от вызова после выполнения любой операции.
Очевидно, что есть исключения во всем, и многие "Getters" - фактически критическая бизнес-логика объекта, такая как String.length(), которая требовалась бы независимо от того, как была реализована String, и даже не реализована, просто вернув свойство - отличный случае для "Getter", если вы даже хотите это назвать.
Ответ 2
Я собирался сказать, что это просто must. Но я посмотрел на JLS, и это не так уж строго. С точки зрения JLS, компилятору остается выбрать, следует ли устанавливать такое ограничение или нет.
Практически устно - у общих компиляторов это ограничение есть, и, как уже было сказано, намного проще для компилятора найти компилятор или для загрузчика классов, чтобы найти файл класса с таким ограничением на месте.
Ответ 3
Чтобы быть более конкретным, имя файла должно иметь то же имя, что и имя открытого класса в этом файле, что является способом сообщить JVM, что это то, что для вас является точкой входа.
Ответ 4
Это просто соглашение, установленное Sun, создателями Java.
Целью является организация; причина в том, что каждый, кто набирает код на Java, будет иметь последовательный способ именования файлов.
Ответ 5
Каждый открытый класс должен находиться в файле, где FileName соответствует ClassName и пакету, где Packagename представляет структуру Directory, написанную в пунктирной форме (слэши становятся точками, такими как com/example/app становится com.example. приложение).
Это соглашение не является случайным. Компилятор должен иметь возможность находить исходные файлы, и загрузчик классов должен иметь возможность найти реализацию. Соответствие имен пакетов и имен классов делает это очень простым и, что более важно, быстрым.
Это соглашение не применяется к непубличным классам. Это связано с тем, что непубличные классы имеют очень ограниченную видимость и могут использоваться только в пакете, где они определены. Таким образом, в обоих случаях компилятор и среда выполнения уже располагают правильными файлами.
Ответ 6
Q. "Тогда как это работает в случае С++, где нет такого ограничения?"
а. Это не работает. У вас должен быть make файл. Вы не нуждаетесь в нем в Java.
Ответ 7
Это полезно при поиске класса. Предположим, что разрешены разные имена файлов, и если вы создали экземпляр класса, тогда компилятор должен искать класс во всех файлах, а если имена файлов такие же, как и у класса, то производительность поиска и использования класса вырос. Их могут быть и другие причины.
Ответ 8
Пока он не является общедоступным , класс может иметь имя, отличное от имени файла. Класс также может иметь основной метод. Файл класса будет сгенерирован с именем класса, но не с именем исходного файла. Имя класса должно использоваться для его выполнения.
Причина: default class является закрытым пакетом, поэтому javac не должен искать этот исходный файл для компиляции какой-либо другой программы Java из-за пределов пакета.
Ответ 9
Добрый вечер, сэр, Q) Почему public classname должно быть именем java файла? Ответ:
- > , чтобы открыть файл или прочитать файл. Операционная система или любая программе требуется имя файла. - > разработчик использует java-язык. разработчик дает инструкцию компилятору создать файл .class, чтобы он мог быть выполнен позже. - > для создания файла .class, java компилятор должен открыть и прочитать файл java. по этой причине develope дает инструкцию двумя способами 1) непосредственно имя файла. 2) косвенно из другой программы ------------------------------------- 1-й путь) (1) непосредственно имя файла. ------------------------------------- разработчик создает файл PrivateData.java и внутри этого файла создается класс PublicData PrivateData.java ---------------- class PublicData { private int x = 10; int getX() { return x; } public static void main (String args []) { System.out.println( "PublicData выполнено" ); } } --------- компилировать ---------- javac PrivateData.java
DEVELOPER THOUGHT:
now developer gives instruction to compilor to
open and read PrivateData.java file and then create .class file
for all the classes those are inside this file.
COMPILOR BEHAVIOUR:
in the above compilor behaviour is to read all the class declaration those
are inside the PrivateData.java file and convert all those into .class file
so,
OUTPUT:
PublicData.class
file is created by compilor.
-------------------------------------------
2nd way) (2) indirectly from other program
-------------------------------------------
let developer developed below tow java files
(1)PrivateData.java
(2)UsePrivateData.java
PrivateData.java
----------------
class PublicData{
private int x=10;
int getX(){
return x;
}
public static void main(String args[]){
System.out.println("PublicData executed");
}
}
UsePrivateData.java
-------------------
class UsePrivateData{
public static void main(String args[]){
PrivateData pd=new PrivateData();
System.out.println(pd.getX());
}
}
---------
compile
----------
javac UsePrivateData.java
DEVELOPER THOUGHT:
now developer gives instruction to compilor to
open and read UsePrivateData.java file and then create .class file
for all the classes those are inside this file
and
indirectly gives instruction from one of the class/program, like in the
above program is
PrivateData pd=new PrivateData();
here developer give indirect instruction to compilor to create
.class file by reading PrivateData.java
(direct instruction is "javac PrivateData.java")
COMPILOR BEHAVIOUR:
->in the above compilor behaviour is to read all the class declaration those
are inside the UsePrivateData.java file and convert all those into .class file
provided one of the classname is equal to the filename.
->now compilor got one more instruction from the program(indirectly from developer)
instruction is
PrivateData pd=new PrivateData();
now compilor behaviour is different.
i) opens the file PrivateData.java
ii)searches for the class PrivateData in the file PrivateData.java
if found,
create .class file for this class
and
then read all other classes and
create .class file for those.
if not found
donot create .class file for other classes
inside the file
and
raise compilation error like below
-------------------------
UsePrivateData.java:3: error: cannot access PrivateData
PrivateData pd=new PrivateData();
^
bad source file: .\PrivateData.java
file does not contain class PrivateData
Please remove or make sure it appears in the correct
subdirectory of the sourcepath.
1 error
----------------------
OUTPUT:
depends on the above explanation.
WHAT I OBSERVED
------------------------------
->for the indirect instruction
compilor behaviour is to 1st search inside the file for
any classname to be same as the filename.
->at a time computer/os/processor/compilor can execute one
instruction.
let one instruction is to open file and search the class
whose name is equal to the filename
to match this condition probably Sun Micorsystem/Oracle
made a rule that only one public class can be declared
inside file whose name should be equal to filename.
(or)
also , as compilor generates error if classname is not equal
to the fileaname, so Sun Microsystem/Oracle made a rule
for the good sake of developer that public classname should
be equal to the classname and only one public class can reside
inside a java file.
МОЙ ОТВЕТ ПРАВИЛЬНО ИЛИ НЕ Я НЕ ЗНАЮ Я ТОЛЬКО ПОЖАЛУЙСТА, ЧТОБЫ ПРЕДОСТАВИТЬ ПРАВИЛЬНЫЙ ОТВЕТ sir.