Какая польза от защиты на уровне пакетов в Java?

Question

Я знаю, как работает защита на уровне пакетов в Java. Я читаю много кода (включая множество материалов с открытым исходным кодом), и никто, кажется, не использует его. Мне кажется, что весь уровень защиты слегка неисправен (в любой день недели у меня будет встроенный c #).

Существуют ли какие-либо законные случаи использования в реальном мире, которые обычно используются?

Edit: Слишком поздно после того, как я задал этот вопрос, я понял, что забыл исключить "стандартный" шаблон классов реализации, защищенных пакетами, возможно, предоставляя реализации открытых интерфейсов. Каждый использует их, как было отмечено несколько раз в ответах. Я все еще думаю, что есть много хороших ответов на этот вопрос.

Answer 1

Я знаю ветеранов Java от 5 до 10 лет, которые не понимают, что protected подразумевает частный доступ к пакету. Только для меня это делает пакетную приватность ужасной языковой особенностью. Лично я не думаю, что есть какая-либо оправданная причина использовать пакет в любом случае. Давайте рассмотрим варианты использования:

• Пакет частных классов: используйте внутренние классы. Другой автор предположил, что есть (небольшое) снижение производительности для внутренних классов по сравнению с закрытыми классами пакета, но для меня это не является хорошей причиной плохого дизайна. Пакетные частные и внутренние классы я считаю подробностями реализации , и поэтому я думаю, что лучше "скрыть" их как внутренние классы;
• Пакет личных данных членов: я не вижу причин для этого вообще; и
• Пакетные приватные методы: они в значительной степени эквивалентны дружественным методам C ++. У друзей C ++ был один хороший смысл, и он заключался в том, чтобы экстернализировать перегрузку операторов вне класса, что позволяло первому аргументу быть чем-то отличным от самого класса. В Java нет такого варианта использования, который просто завершает инкапсуляцию и абстракцию.

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

И нет абсолютно никакого способа предотвратить это.

C # имеет лучшую систему доступа, поскольку защищенный не подразумевает внутренний доступ. Но я считаю это - наряду с изменяемым классом Date - довольно большими недостатками.

Answer 2

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

Аналогией могут быть "дружественные" методы в C ++.

Answer 3

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

На мой взгляд, это базовый механизм защиты, и иерархия защиты была бы хорошей особенностью.

Answer 4

«Я знаю, как работает защита на уровне пакетов в Java ... и, похоже, никто не использует ее».

Что они используют?

Они делают все свои уроки публичными?

Принцип Бремени принимает две формы.

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

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

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

Бремя создания или изменения любой программной системы зависит от количества созданных или измененных программных единиц.

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

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

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

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

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

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

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

Тем не менее, вы упоминаете, что это не используется в коде, который вы читаете.

Звучит ... странно.

Answer 5

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

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

Защита пакета позволяет вам экспортировать только несколько классов из вашего пакета, оставляя остальные в секрете.

Теоретически это отличная идея, на практике вы почти никогда ее не видите.