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

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

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

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

Не было бы бессмысленным иметь интерфейсы, которые имеют несколько модификаторов доступа; например, частично общедоступный и частично ограниченный другими классами в том же пакете, что и интерфейс. Фактически, в некоторых случаях это может быть полезно, ИМО.

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

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

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

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

Во всяком случае, официальный ответ на RFE в JDK-8179193 проясняет, что команда разработчиков Java решила ^2, что разрешение protectedна использование интерфейсов добавляет сложности, но при этом мало пользы. Престижность @skomisa за обнаружение улик .

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

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

^{2 - Вы можете не согласиться с их решением или заявленной аргументацией, но это спорный вопрос.}

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

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

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

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

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

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

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

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

Это ничего не объясняет, но, к счастью, пару лет назад кто-то поднял запрос на улучшение защищенных методов в интерфейсах как ошибку JDK , которая проливает свет на проблему:

Защищенные методы в интерфейсах: совместное использование пакетов

Поскольку модификаторы в Java немного ограничены, способ совместного использования методов в пакетах ограничен общедоступными методами. Иногда делать метод общедоступным бывает опасно, но это необходимо из-за отсутствия соответствующих модификаторов. Мое решение преодолевает это ограничение.

Спецификация языка java в настоящее время не допускает использования модификатора protected для методов интерфейса. Мы можем воспользоваться этим фактом и использовать методы интерфейса protected для этой новой функции.

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

Таким образом, мы могли использовать определенные методы в хорошо известных пакетах.

И это ответ на запрос на расширение, который был закрыт со статусом Won't fix:

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

Альтернативный вариант, доступный начиная с Java 9, - сделать классы и методы общедоступными, но внутри модуля, который имеет квалифицированный экспорт в определенные «дружественные» модули, а не для широкой публики.

Итак, авторитетные выводы из этого отчета об ошибке:

• Текущая ситуация не изменится; интерфейсы вряд ли когда-либо будут поддерживать protectedметоды.
• Обоснование отказа от поддержки protectedметодов в интерфейсах состоит в том, что это « добавляет сложности и особые случаи для небольшого реального выигрыша ».
• Начиная с Java 9 существует альтернативный подход для предоставления доступа к методам на уровне пакета. Используйте Систему модулей платформы Java (JPMS), чтобы « сделать классы и методы общедоступными, но в пределах модуля, который имеет квалифицированный экспорт в определенные« дружественные »модули вместо экспорта для широкой публики ».

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

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

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

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

Объявление внутренних субинтерфейсов - хорошая практика, но технически вы не можете объявлять свои внутренние методы, как protectedв интерфейсе в Java.

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

package yourpackage;

public interface PublicInterface {

    public void doThing1();

    public void doThing2();

    public void doThing3();

}

package yourpackage;

interface InternalInterface extends PublicInterface {

    void doAnyInternalThing1();

    void doAnyInternalThing2();

}

Вы можете использовать InternalInterfaceинтерфейс внутри пакета, но вы должны принять любой подтип PublicInterface(в общедоступных методах):

package yourpackage;

public class SomeClass {

    public void someMethod(PublicInterface param) {
        if (param instanceof InternalInterface) {
            // run the optimized code
        } else {
            // run the general code
        }
    }

}

Вне пакета пользователи могут использовать PublicInterfaceбез проблем.

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

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

И даже сценарий пакета - это не совсем то, о чем интерфейсы.

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

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

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

Защищенные методы доступны через расширение, а не через реализацию .

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

public interface MyInterface {
    public void publicMethod(); // needs to be public
}

public abstract class MyAbstractClass implements MyInterface {
    @Override
    public void publicMethod() {
        protectedMethod(); // you can call protected method here
        // do other stuff
    }
    protected abstract void protectedMethod(); // can be protected
}

public class MyClass extends MyAbstractClass {
    @Override
    protected void protectedMethod() {
        // implement protected method here, without exposing it as public
    }
}