Подтвердить что ты не робот

Почему в источниках Java есть так много папок внутри друг друга?

Каждый раз, когда я смотрю на какой-либо исходный код Java, я нахожусь в серфинге в папке с папкой, в которой есть папка, в которой есть папка и т.д. Почему Java требует столько вложенных папок, которые не имеют в них ничего другого, кроме новая подпапка?

Например: https://github.com/halfninja/android-dragcontrol3d/tree/master/src/uk/co/halfninja/android Это, вероятно, не самый худший пример, но есть две папки "uk" и "co", которые просто не имеют смысла. Я вижу это только в источниках Java!

И, например, minicraft: http://www.ludumdare.com/compo/ludum-dare-22/?action=preview&uid=398

import com.mojang.ld22.gfx.Font;
import com.mojang.ld22.gfx.Screen;
import com.mojang.ld22.gfx.SpriteSheet;

Почему бы просто не написать:

import gfx.Font;
import gfx.Screen;
import gfx.SpriteSheet;

Это намного чище.

(Я никогда не программировал на Java.)

4b9b3361

ОТВЕТЫ

Ответ 1

Они предназначены для предотвращения конфликтов с другими банками. Имея что-то вроде URL-адреса компании в имени пакета, он может быть достаточно уникальным, чтобы не конфликтовать с кем-то другим пакетом и классами.

Ваш пример хороший, так как кажется разумным представить себе двух людей, которые думают использовать "gfx" в качестве имени пакета и с такими классами, как "Шрифт" или "Спрайт". Теперь, если вы хотите использовать оба из них, как вы могли с тех пор, как имя пакета и класса было бы именем?

Ответ 2

Ваш путь чище, но он полагает, что никто в мире никогда не собирается создавать пакет под названием gfx, что является довольно слабым предположением. Добавив ваше обратное доменное имя, вы создадите уникальное пространство имен, которое позволяет избежать конфликтов.

Это идеально сочетается с "культурой обмена", которая пронизывает Java-программирование, в котором приложения обычно объединяют большие библиотеки из многих источников.

Ответ 3

В Java соглашение должно указывать ваши пакеты (которые соответствуют структуре папок, содержащих ваш код), с информацией, идентифицирующей вашу организацию (обычно включая TLD и название компании) и проектом (который может добавить несколько других разделов).

Более конкретным, таким образом, также уменьшается вероятность того, что пространства имен случайно столкнутся с eachother.

Ответ 4

Это всего лишь организационная техника для предотвращения конфликтов пространства имен. Ничего больше или меньше. Имена пакетов Java соответствуют базовой структуре каталогов, поэтому там будет отражен любой организационный шаблон на уровне пакета. Для команд типично начинать имена своих пакетов с указанием названия организации и воска. Это просто соглашение, но оно укоренилось и должно сопровождаться отсутствием очень веской причины.

Ответ 5

Все о Пространства имен. С помощью "Пространства имен" вы можете создать 2 класса с тем же именем, которые находятся в разных пакетах/папках. Эта логика пространства имен также может использоваться для создания "Привилегий доступа" и т.д. Ниже приведены некоторые ссылки:

1) Namespace 2) Java-пакет 3) Соглашения об именах пакетов Java

EDIT: предположим, что вы создаете новый проект и используете 2 фреймворка с открытым исходным кодом от компаний/организаций - comA и comB. Кроме того, предположим, что comA и comB создали класс в своих проектах с тем же именем класса. Теперь, с соглашениями об именах пакетов Java, у нас есть com.comA.SomeClass и com.comB.SomeClass. Вы можете импортировать и использовать оба класса в своем классе, не имея конфликта. Это простой пример. Существуют другие виды использования этого соглашения об именах.

Ответ 6

Если вы хотите поделиться кодами со всеми остальными, но используйте общие имена без конфликтов. его рассмотренная надлежащая практика включает ваше доменное имя (назад)

Каждый напишет пакет под названием gfx.Font, вы не сможете использовать более одной версии в одном приложении.

Возможно, вы почувствуете, что ваш код не будет использоваться совместно с миром (или даже не должен быть общим). В этом случае структура сокращенного пакета может быть проще.

Если вы используете среду IDE, она хорошо скрывает длинные структуры пакетов, поэтому вам не нужно беспокоиться об этом.

Ответ 7

Java ничего не требует: вы можете просто поместить все свои классы в пакет по умолчанию и уйти. Но для серьезных проектов такая организация не только мудрая, но и обязательная. Часть com.mojang.ld22 - это просто соглашение:

  • com = либо это, либо org, java/javax для официальных пакетов
  • mojang = вторая часть название компании
  • ld22 = третья часть - это имя приложения

Ответ 8

Это связано с рекомендуемой структурой упаковки. В больших проектах используется так много пакетов/библиотек и чтобы не помещать исходные файлы в одну папку с другой библиотекой, программисты помещают свои исходные коды в уникальные папки. Поскольку сайты уникальны, конвенция использует структуру упаковки, которая выглядит как структура папок веб-сайтов.