Недавно я обсуждал в своем проекте модификатор частной видимости пакета.
“Подождите, что такое package-private в Java? ” Его также иногда называют default или без модификатора . Это когда класс или метод не имеют никакого модификатора. Например:
class SomeObject {
void doSomething() {
...
}
}
Более подробная информация приведена в Java tutorial .
Его не следует использовать без очень-очень конкретной причины. Вы либо выбираете между общедоступным, частным или защищенным.
Есть причины, по которым я до сих пор слышал от разных людей:
- Но мне это нужно для тестирования метода в моем объекте!
- Но лучше максимально ограничить доступ к Объекту! Доступ к нему получают только классы с тем же пакетом.
- У меня есть библиотека с большим количеством пользователей, и я хочу скрыть от них детали реализации!
Но мне это нужно для тестирования метода в моем объекте!
Не делайте package-private только для того, чтобы протестировать этот очень важный метод. Это одно из частых заблуждений, которые я наблюдаю. Люди, как правило, каким-то образом получают доступ к этой частной логике, просто немного расслабляют ее, а затем проводят грязное тестирование! Есть лучший способ. Сначала вам нужно понять, что, вероятно, что-то не так с вашим дизайном, если есть какая-то скрытая функциональность, которую трудно протестировать. Это означает, что это идеальный кандидат для рефакторинга! Просто извлеките эту логику во внутренний класс с помощью четко определенных методов API и протестируйте их.
Но лучше максимально ограничить доступ к Объекту! Доступ к нему получают только классы с тем же пакетом.
Официальная документация Oracle гласит: Используйте наиболее строгий уровень доступа, который имеет смысл для конкретного участника. Используйте private, если у вас нет веских причин этого не делать. Я полностью согласен с этим утверждением, только если мы исключим package-private из этого списка. Жизнь вашего проекта будет намного проще, если все будет публичным/частным. Одним из наиболее частых рефакторингов в больших кодовых базах является Переместить файл/Класс . При большом количестве package-private доступа это сразу же станет раздражать. Почему бы тогда не обнародовать их? В конце оба public и package-private предоставляют API вашего класса. Независимо от того, что в последнем случае он ограничен пакетом, это все равно API, о котором вы должны заботиться.
- Тесты. Это относительно новая тенденция – не писать модификаторы доступа для тестового кода. В любом случае модификаторы вносят некоторый шум в код, и видимость доступа имеет значение не столько в тестах, сколько в производственном коде. Меньше печатать – лучше!
- Вы поддерживаете библиотеку с большим количеством пользователей. Если только ваша библиотека не должна быть совместима с java 8 или менее! В противном случае я рекомендую использовать JPMS (Project Jigsaw) в ваших приложениях, что даст вам гораздо лучший контроль над вашими открытыми API и внутренней реализацией по сравнению с package-private
Итак, как вы можете видеть в 2019 году (скоро 2020 год!) существует не так много причин для использования package-private visibility.
Оригинал: “https://dev.to/cauchypeano/why-you-should-avoid-package-private-scope-in-java-anl”