Политика в отношении пакетов Java

Question

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

Сначала пакеты кажутся иерархическими, но это не так. source

Представьте, что у меня есть API, определенный с его классами в foo.bar, только те классы, которые нужны клиенту API, становятся открытыми.Затем у меня есть другой пакет с некоторыми внутренними объектами, которые мне нужны в API, определенном по адресу foo.bar.pojos, эти классы должны быть общедоступными, чтобы к ним мог обращаться foo.bar, но это означает, что клиент API также может получить к ним доступ, если пакетfoo.bar.pojos импортируется.

Какая общая политика пакета должна соблюдаться?

Answer 1

Я видел два способа сделать это.

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

Второй состоит в том, чтобы доставить один jar, но имеет хорошую документацию, позволяющую узнать, что является внутренним, а что нет.Текстовая документация может объяснить, как использовать API (и, следовательно, избегать разговоров о внутренностях).А в javadoc можно указать, что класс предназначен для внутреннего использования и поэтому может быть изменен.

Answer 2

Да, пакеты Java не дают достаточного контроля над вашими зависимостями.Классический способ справиться с этим - поместить внешние API в один пакет, а внутренние классы реализации - в другой, и полагаться на здравый смысл людей, чтобы избежать создания зависимостей от последнего.

С Maven и OSGI у вас есть дополнительный механизм для управления зависимостями между модулями / пакетами пакетов.В случае OSGI вы можете явно объявить некоторые пакеты как не экспортируемые, а среда разработки с учетом OSGI предотвратит создание вредных зависимостей.Поддержка модулей в Maven слабее, но, по крайней мере, она контролирует циклы зависимостей.

Наконец, вы можете использовать пользовательские правила PMD для обеспечения соблюдения соглашений о модульности вашего проекта ... таким же образом, как существуют правила для предотвращения зависимости от Java"com.sun. *" дерево пакетов.

Answer 3

Это беспорядок.

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

Вам может понравиться OSGi, которая имеет (и применяет) концепцию закрытых пакетов. Они не экспортируются во внешний мир.