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

Чому всі методи у interfaceвизначенні неявно public? Чому він не дозволяє protectedметод?

Тому що інтерфейс повинен означати "те, що ви можете бачити поза класом". Не було б сенсу додавати непублічні методи.

Хоча часто цитується причина в тому, що "інтерфейси визначають загальнодоступні API", я вважаю, що це надмірне спрощення. (І це "пахне" круговою логікою.)

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

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

• Члени учасників публічного інтерфейсу простіші для програмістів. Скільки разів ви бачили код (класи), де модифікатори доступу методу вибиралися, здавалося б, випадковим чином? Багато "звичайних" програмістів мають труднощі зрозуміти, як найкраще керувати межами абстракції Java ¹ . Додавання загальнодоступних / захищених / приватних пакетів до інтерфейсів робить їх ще складніше.

• Члени учасників загальнодоступного інтерфейсу спрощують специфікацію мови ... і, отже, завдання для письменників-компіляторів Java та людей, які реалізують API відбиття.

Думка про те, що "інтерфейси визначають загальнодоступні API", можливо, є наслідком (або характеристикою) спрощення дизайнерського рішення щодо спрощення мови ... не навпаки. Але насправді два напрямки думки, ймовірно, розвивалися паралельно у свідомості дизайнерів Java.

У будь-якому випадку з офіційної відповіді на RFE в JDK-8179193 чітко видно, що команда дизайнерів Java вирішила ^2, що дозволити protectedвикористання інтерфейсів додає складності для малої реальної вигоди. Кудос до @skomisa для пошуку доказів .

Докази в RFE вирішують це питання. Це є офіційною причиною, чому цього не було додано.

^{1 - Зрозуміло, програмісти з вищою зброєю не мають труднощів з цими речами, і вони можуть вітати більш багату палітру функцій контролю доступу. Але що відбувається, коли їх код передають комусь іншому для підтримки?}

^{2 - Ви можете не погодитися з їх рішенням або викладеними ними міркуваннями, але це суперечка.}

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

Є кілька випадків, коли я міг різко спростити свій код методом "захищений за замовчуванням". Виявляється, це насправді не працює, оскільки інтерфейси все ще дотримуються логіки Java 7. Звичайні захищені методи особливо не мають сенсу з вищезазначених причин; але якщо загальнодоступний загальнодоступний метод вимагає ресурсу низького рівня, який, швидше за все, не зміниться і може бути забезпечений захищеним методом, мені здається, що робота "захищена за замовчуванням" не тільки підтримуватиме чистіший код, але захистить майбутніх користувачів від випадкові зловживання.

(Це трагічно не змінює того факту, що мені все-таки потрібно надмірно ускладнювати свій код інакше непотрібними рефератами; але я маю намір вносити запит на функцію в Oracle.)

Оскільки інтерфейси визначають загальнодоступні API. Все, що захищено, - це внутрішня деталь, яка не належить до інтерфейсу.

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

Можливо, тому, що це інтерфейс , тобто він є, щоб сказати клієнтам, що вони можуть робити з екземплярами, а не говорити їм, що вони не можуть зробити.

Я сильно вважаю, що інтерфейси повинні дозволяти захищені методи; хто сказав, що інтерфейси повинні бути видимими для всіх у всьому світі? Щодо вашої точки зору, що це може заплутати "звичайних" (читайте: некомпетентних) програмістів: стільки OOP - це належне структурування об'єктів, класів, пакетів тощо. Якщо програмісту важко робити все, що належним чином, у нього є набагато більша проблема. Java була побудована для такого типу речей.

Кілька відповідей тут використовують кругові міркування, щоб пояснити, чому методи інтерфейсу не можуть бути захищені: це тому, що вони повинні бути відкритими, тому очевидно, що їх не можна захистити!

Це нічого не пояснює, але, на щастя, хтось підняв запит на вдосконалення захищених методів в інтерфейсах як помилка JDK пару років тому, що прояснює проблему:

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

Оскільки модифікатори в Java трохи обмежені, спосіб спільного використання методів між пакетами обмежений лише публічними методами. Іноді небезпечно оприлюднювати метод, але це потрібно через відсутність належних модифікаторів. Моє рішення долає це обмеження.

Спеціалізація мови java наразі не дозволяє захищений модифікатор методів інтерфейсу. Ми можемо скористатися цим фактом і використовувати захищені для інтерфейсу методи для цієї нової функції.

Якщо метод інтерфейсу позначений захищеним, а інтерфейс реалізований класом в іншому пакеті, метод не повинен бути загальнодоступним, але також може бути приватним або принаймні захищеним пакетом. Метод видно, що колись клас оголошує його таким, що він є, і додатково видимим у вихідному пакеті інтерфейсу (та підпакетів?).

Таким чином ми могли б поділитися певними методами у добре відомих пакетах.

І це відповідь на той запит на покращення, який закрився статусом 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
    }
}