Подтвердить что ты не робот

Почему Java 8 не разрешает методы, не связанные с общедоступными стандартами?

Возьмем пример:

public interface Testerface {

    default public String example() {
        return "Hello";
    }

}

public class Tester implements Testerface {

    @Override
    public String example() {
        return Testerface.super.example() + " world!";
    }


}

public class Internet {

    public static void main(String[] args) {
        System.out.println(new Tester().example());
    }

}

Достаточно просто напечатать Hello world!. Но скажу, что я делал что-то еще с возвращаемым значением Testerface#example, например, инициализируя файл данных и возвращая чувствительное внутреннее значение, которое не должно покидать класс реализации. Почему Java не разрешает модификаторы доступа по методам интерфейса по умолчанию? Почему они не могут быть защищены/приватными и потенциально повышены подклассом (аналогично тому, как класс, который расширяет родительский класс, может использовать более видимый модификатор для переопределенного метода)?

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

Я читал "Почему "final" не разрешен в методах интерфейса Java 8?, в котором говорится:

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

И мне кажется, что видимость не нарушит этот аспект вообще.

Как и связанный с ним вопрос, поскольку похоже, что проблема была закрыта, авторитетный ответ был бы оценен в этом вопросе, а не на основе мнения.

4b9b3361

Ответ 1

Как мы видели в В чем причина, почему "синхронный" не разрешен в методах интерфейса Java 8? и Почему является "окончательным" не разрешены в методах интерфейса Java 8?, расширение интерфейсов для определения поведения является более тонким, чем может показаться вначале. Оказывается, каждый из возможных модификаторов имеет свою собственную историю; это не просто вопрос слепого копирования из того, как работают классы. (Это, по крайней мере, очевидно, оглядываясь назад, поскольку инструменты для моделирования OO, которые работают для одиночного наследования, не работают автоматически для множественного наследования.)

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

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

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

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

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