Защищено в интерфейсах

Question

Почему все методы в определении interface неявно public?Почему не разрешен метод protected?

Answer 1

Потому что интерфейс должен означать «то, что вы можете видеть вне класса».Не имеет смысла добавлять закрытые методы.

Answer 2

Хотя часто цитируемая причина в том, что «интерфейсы определяют публичные API», я думаю, что это упрощение. (И это тоже "пахнет" круговой логикой.)

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

• Было бы бессмысленно иметь интерфейсы, которые имеют смесь модификаторов доступа; например частично открытый и частично ограниченный другими классами в том же пакете, что и интерфейс. На самом деле, в некоторых случаях это может быть совершенно полезным, IMO.

На самом деле, я думаю, что часть рассуждений о том, чтобы сделать члены интерфейса неявно публичными, заключается в том, что делает Java проще :

• Неявно члены публичного интерфейса проще для программистов иметь дело. Сколько раз вы видели код (классы), где модификаторы доступа к методу выбирались, казалось бы, случайно? Многим «обычным» программистам трудно понять, как лучше всего управлять границами абстракции Java ¹ . Добавление public / protected / package к интерфейсам делает их еще сложнее.

• Неявно открытые члены интерфейса упрощают спецификацию языка ... и, следовательно, это задача для авторов компиляторов Java и тех, кто реализует API Reflection.

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

---

^{1 - Конечно, программисты-топ-пейнтеры не испытывают затруднений с этими вещами и могут приветствовать более богатую палитру функций контроля доступа. Но что происходит, когда их код передается кому-то другому для поддержки?}

Answer 3

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

Есть несколько случаев, когда я мог бы радикально упростить свой код с помощью метода «по умолчанию защищен». Оказывается, что это на самом деле не работает, поскольку интерфейсы все еще придерживаются логики Java 7. Нормальный защищенный метод не имеет особого смысла по причинам, упомянутым выше; но если общедоступному методу по умолчанию требуется низкоуровневый ресурс, который вряд ли изменится и может быть предоставлен защищенным методом, мне кажется, что работа «по умолчанию защищена» не только поддержит более чистый код, но и защитит будущих пользователей от случайные злоупотребления.

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

Answer 4

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

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

Answer 5

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

Answer 6

I сильно считают, что интерфейсы должны разрешать защищенные методы; кто сказал, что интерфейсы должны быть видны всем в мире? Что касается вашей точки зрения, это может сбить с толку «обычных» (читай: некомпетентных) программистов: большая часть ООП связана с правильной структурой объектов, классов, пакетов и т. Д., Если программисту трудно сделать все это должным образом, у него есть гораздо большая проблема. Ява была построена для такого типа вещей.

Answer 7

Интерфейс предназначен для использования в качестве «контракта» для внешнего мира. Если вы хотите использовать защищенные методы, вам, вероятно, лучше использовать абстрактный класс (если, конечно, он доступен в Java). Wiki

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

Answer 8

Поскольку реализующий класс должен реализовывать ВСЕ методы, объявленные в вашем интерфейсе, что произойдет, если ваш реализующий класс будет в другом пакете?

Answer 9

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

В случае интерфейса подкласс никогда не расширяет интерфейс. Реализует интерфейс.

Защищенные методы доступны через extension , а не через Implement .

Answer 10

Интерфейс Если вы хотите использовать что-то, как вы описали, продолжайте с абстрактными классами или вложенными интерфейсами.

Выдержка из Code Style о переменных интерфейса, но все же применима к методам, хотя:

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