Что цель определить пакет в файле Java?

В большом приложении у вас обязательно должны быть два файла с именами в точности то же самое (java.util.Date и java.sql.Date), особенно когда вы начинаете добавлять сторонние jar-файлы. Таким образом, вы можете использовать пакеты для обеспечения уникальности.

Наиболее важно, на мой взгляд, упаковка разбивает проекты на значимые сегменты. Итак, мой пакет SQL имеет связанный с sql код, а мой пакет регистратора обрабатывает ведение журнала.

Это позволяет составлять программу из нескольких различных программ / компонентов / библиотек, так что их имена классов не будут конфликтовать, а компоненты легче организовать. См. http://java.sun.com/docs/books/tutorial/java/package/index.html

В Java принято называть пакеты как обратные доменные имена. Например, если домен вашей компании - «initech.com» и вы создаете программу под названием «Gizmo», к именам пакетов обычно добавляется префикс com.initech.gizmo с подпакетами для различных компонентов программы.

Пакеты важны для обеспечения гибкости разделения классов. Их можно использовать для:

• разделения проектов
• разделения модулей
• разделения уровней приложений (бизнес, сеть, dao)
• дальнейшего более тонкого разделения кода

Например

com.mycompany.thisproject .thismodule.web

Может указывать на веб-уровень некоторого модуля.

В дополнение к пространству имен, упомянутому в других ответах, вы можете ограничить доступ к методам и полям на основе области, объявленной для этого члена. Члены с областью видимости public свободно доступны, для ограничения доступа вы обычно определяете их как private (т.е. скрытые вне класса). Вы также можете использовать protected область, чтобы ограничить доступ к типу и его дочерним элементам. Существует также область действия по умолчанию (элемент без квалификатора имеет область по умолчанию), которая позволяет дочерним типам и типам в одном пакете получить доступ к члену. Это может быть эффективным способом совместного использования полей и методов, не делая их слишком общедоступными, и может помочь в тестировании.

Например, приведенный ниже метод будет виден всем другим членам того же пакета.

public class Foo {
    int doSomething() {
        return 1;
    }
}

Для тестирования вы можете определить другой тип в том же пакете (но, вероятно, в другом исходном местоположении), этот тип сможет получить доступ к методу.

public class FooTest {
    @Test
    int testDoSomething() {
        Foo foo = new Foo();
        assertEquals(1, foo.doSomething());
    }
}

также, если я решу принять это, как следует ли их сгруппировать?

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

Еще одна важная особенность пакетов - это элемент protected для управления доступом.

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

Java очень точна в своей реализации. На самом деле это не оставляет места для обмана.

Если бы все использовали один и тот же пакет, им пришлось бы найти какой-то «всемирный» способ гарантировать, что никакие два имени класса никогда не конфликтуют.

Это позволяет каждому по отдельности. когда-либо написанный класс помещается в свое собственное «Место», на которое вам не нужно смотреть, если вы этого не хотите.

У вас могут быть разные объекты «Точки», определенные в 4 разных местах вашей системы, но ваш класс будет использовать только тот, который вы ожидаете (потому что вы импортируете его).

Они гарантируют, что у каждого есть собственное пространство, - это использовать ваш обратный домен, поэтому мой - «tv.kress.bill». Я владею этим доменом - на самом деле я делю его со своим братом tv.kress.doug, и, хотя у нас один и тот же домен, мы можем ' У них есть коллизия.

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

Системы, в которых нет такого разделения, кажутся действительно ненадежными. мне сейчас. Я мог бы использовать их, чтобы собрать сценарий для чего-то личного, но мне было бы неудобно разрабатывать что-то большое без строгой упаковки.

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

Ответ, конечно же, заключается в том, что пакеты обеспечивают организацию. Часть программы, которая взаимодействует с базой данных, отличается от той части программы, которая отображает пользовательский интерфейс для пользователя, поэтому они будут в разных пакетах.

Как и каталоги, она также предоставляет способ разрешения конфликтов имен . У вас может быть файл temp.txt в паре разных каталогов точно так же, как у вас может быть два класса, которые появляются в разных пакетах. Это становится важным (1) когда вы начинаете комбинировать код с другими людьми в Интернете или (2) даже понимаете, как Java '

From the Wikipedia page on the topic:

"A Java package is a mechanism for organizing Java classes into namespaces similar to the modules of Modula. Java packages can be stored in compressed files called JAR files, allowing classes to download faster as a group rather than one at a time. Programmers also typically use packages to organize classes belonging to the same category or providing similar functionality."