Плюсы и минусы частных классов пакетов в Java?

Короткий ответ - это немного более широкая форма частного.

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

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

Это редко используется на практике, потому что система пакетов оказывается не очень полезной для такого рода вещей. Вам придется свалить все классы для данного модуля в один и тот же пакет, что для чего-то нетривиального станет немного громоздким. Итак, идея великолепна — сделать метод доступным только для нескольких «близлежащих» классов, как немного более широкий private — но ограничения на то, как вы определяете этот набор классов, означают, что он редко используется/полезен.

Одна приятная особенность package-private заключается в том, что вы можете использовать его для предоставления доступа к методам, которые в противном случае считались бы приватными для классов модульного тестирования. Недостатком, конечно, является то, что другие классы в пакете могут вызывать его, когда на самом деле не должны.

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

В качестве примера вы можете взглянуть на библиотеку, которую я разработал. javadoc содержит только 5 интерфейсов и 12 классов, хотя исходный код содержит намного больше. Но то, что скрыто, — это в основном внутренние слои, которые не предоставляют никакой дополнительной ценности для клиента (обычно скрыты все абстрактные базовые классы).

В JDK также есть много примеров.

Уровень доступа для пакетов более строгий, чем protected: к защищенным атрибутам и методам по-прежнему можно получить доступ, просто создав подкласс класса. Члены Protected предназначены (или могут быть) для наследования, а члены package-private — нет.

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

Хорошими примерами этого являются закрытый для пакета конструктор String и массив символов StringBuilder.value:

/*
* Package private constructor which shares value array for speed.
* this constructor is always expected to be called with share==true.
* a separate constructor is needed because we already have a public
* String(char[]) constructor that makes a copy of the given char[].
*/
String(char[] value, boolean share) {
    // assert share : "unshared not supported";
    this.value = value;
}

Таким образом, классы внутри пакета java.lang могут эффективно создавать новые Strings, если содержимое уже присутствует в char[], без ущерба для безопасности. Вы не можете сделать это из своего приложения, потому что, если бы вы могли, у вас был бы доступ (ссылка) к внутреннему массиву символов String, который является неизменным (отражение не учитывается!).

В StringBuilder (или, скорее, AbstractStringBuilder, откуда берется реализация) массив символов, содержащий текущее значение char[] value, и метод доступа к этому char[] getValue() также являются частными для пакета, поэтому различные служебные методы String, такие как contentEquals(StringBuffer sb) и contentEquals(CharSequence cs), могут использовать это для повышения эффективности и более быстрого сравнения. без раскрытия внутреннего массива символов «миру».

Что касается вопроса «почему это значение по умолчанию», в этом контексте термин «по умолчанию» просто означает отсутствие другого квалификатора. Думаю, они могли бы придумать другое ключевое слово ("пакет" уже занят), но не сделали этого.

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

Другая причина, по которой вы не видели, чтобы он использовался чаще, заключается в том, что люди склонны исключать классы с доступом по умолчанию из своих javadocs.

1 - Зависит от архитектуры. Обычно, если вы пишете код только для себя и в небольших проектах, вы, вероятно, не будете его использовать. В более крупных проектах может быть полезно убедиться, что вы можете контролировать, где и как вызываются определенные методы.

2 - По умолчанию (т.е. не общедоступный/защищенный/частный) не то же самое, что частный - это 4-е состояние. См. раздел управление доступом к Java.

3. Это может облегчить жизнь, когда вы пишете библиотеки, которые вы не хотите, чтобы третьи стороны полагались на то, как вы реализуете базовый код — вы просто делаете общедоступным сам API.

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

Обратите внимание, что когда вы говорите о классах, у вас есть только два варианта:

1. публичные занятия
2. пакетные частные занятия

Понятие «частный класс» бессмысленно. (Зачем делать класс, который нигде не используется?!)

Поэтому, если у вас есть класс для промежуточных операций, который не нужно предоставлять пользователям API, вы должны объявить его как «приватный пакет».

Кроме того, когда вы определяете много классов в одном и том же исходном файле, только один класс может быть общедоступным (его имя соответствует имени файла .java). Если какой-либо другой класс определен в том же файле, он должен быть «приватным для пакета».