Chronione w interfejsach

Dlaczego wszystkie metody w interfacedefinicji są niejawnie public? Dlaczego nie pozwala na protectedmetodę?

Ponieważ interfejs ma oznaczać „to, co widać spoza klasy”. Nie ma sensu dodawać metod niepublicznych.

Chociaż często przytaczanym powodem jest to, że „interfejsy definiują publiczne API”, myślę, że jest to nadmierne uproszczenie. (I "pachnie" też logiką kolistą.)

Nie byłoby bez sensu posiadanie interfejsów zawierających mieszankę modyfikatorów dostępu; np. częściowo publiczne, a częściowo ograniczone do innych klas w tym samym pakiecie co interfejs. W rzeczywistości w niektórych przypadkach może to być przydatne w dół, IMO.

Właściwie uważam, że częścią rozumowania stojącego za upublicznieniem elementów interfejsu jest to, że upraszcza to język Java :

• Niejawnie publiczne elementy składowe interfejsu są prostsze w obsłudze dla programistów. Ile razy widziałeś kod (klasy), w którym modyfikatory dostępu do metody były wybierane pozornie losowo? Wielu „zwykłych” programistów ma trudności ze zrozumieniem, jak najlepiej zarządzać granicami abstrakcji Javy ¹ . Dodanie publicznego / chronionego / prywatnego pakietu do interfejsów sprawia, że ​​jest to jeszcze trudniejsze.

• Niejawnie publiczne elementy interfejsu upraszczają specyfikację języka ... a tym samym zadanie dla autorów kompilatorów Java i osób, które implementują interfejsy API Reflection.

Myślenie, że „interfejsy definiują publiczne API” jest prawdopodobnie konsekwencją (lub cechą) decyzji dotyczącej projektu uproszczenia języka ... a nie na odwrót. Ale w rzeczywistości te dwa nurty myślenia prawdopodobnie rozwinęły się równolegle w umysłach projektantów Javy.

W każdym razie oficjalna odpowiedź na RFE w JDK-8179193 jasno pokazuje, że zespół projektowy Java zdecydował ^2, że dopuszczenie protectedinterfejsów zwiększa złożoność i przynosi niewielkie realne korzyści. Uznanie dla @skomisa za znalezienie dowodów .

Dowody w RFE rozwiązują problem. To jest oficjalny powód, dla którego nie został dodany.

^{1 - Oczywiście programiści z najwyższej półki nie mają z tym trudności i mogą z zadowoleniem przyjąć bogatszą paletę funkcji kontroli dostępu. Ale co się stanie, gdy ich kod zostanie przekazany komuś innemu w celu utrzymania?}

^{2 - Możesz nie zgadzać się z ich decyzją lub uzasadnieniem, ale to kwestia dyskusyjna.}

Muszę powiedzieć, że to pytanie zostało ponownie otwarte przez wprowadzenie domyślnych metod w Javie 8. Projekt, nad którym obecnie pracuję, jest podobny do podstawowego charakteru interfejsu i ma na celu oderwanie od implementacji.

Jest kilka przypadków, w których mógłbym drastycznie uprościć mój kod za pomocą metody „domyślnej ochrony”. Okazuje się, że to w rzeczywistości nie działa, ponieważ interfejsy nadal są zgodne z logiką Java 7. Zwykła metoda chroniona nie ma większego sensu z powodów wymienionych powyżej; ale jeśli domyślna metoda publiczna wymaga zasobu niskiego poziomu, który prawdopodobnie się nie zmieni i może być dostarczony za pomocą metody chronionej, wydaje mi się, że posiadanie pracy „domyślnej chronionej” nie tylko utrzymałoby czystszy kod, ale także chroniłoby przyszłych użytkowników przed przypadkowe nadużycia.

(To tragicznie nie zmienia faktu, że nadal muszę nadmiernie komplikować swój kod niepotrzebnymi streszczeniami, ale zamierzam złożyć prośbę o funkcję w Oracle).

Ponieważ interfejsy definiują publiczne interfejsy API. Wszystko, co jest chronione, jest szczegółem wewnętrznym, który nie należy do interfejsu.

Możesz używać klas abstrakcyjnych z chronionymi metodami abstrakcyjnymi, ale interfejsy są ograniczone do metod publicznych i publicznych statycznych pól końcowych.

Być może dlatego, że jest to interfejs , czyli po to, aby powiedzieć klientom, co mogą zrobić z instancjami, a nie powiedzieć im, czego nie mogą zrobić.

Jestem głęboko przekonany , że interfejsy powinny umożliwiać metody chronione; kto powiedział, że interfejsy muszą być widoczne dla wszystkich na całym świecie? Jeśli chodzi o twój punkt widzenia, może to zmylić "zwykłych" (czytaj: niekompetentnych) programistów: tak wiele z OOP dotyczy właściwej struktury obiektów, klas, pakietów itp., Jeśli programista ma trudności z wykonaniem tego wszystkiego poprawnie, ma dużo większy problem. Java została stworzona do tego typu rzeczy.

W kilku odpowiedziach stosuje się rozumowanie cykliczne, aby wyjaśnić, dlaczego metody interfejsu nie mogą być chronione: to dlatego, że muszą być publiczne, więc oczywiście nie można ich chronić!

To nic nie wyjaśnia, ale na szczęście ktoś kilka lat temu zgłosił prośbę o ulepszenie metod chronionych w interfejsach jako błąd JDK , co rzuca trochę światła na problem:

Metody chronione w interfejsach: udostępnianie w pakietach

Ponieważ modyfikatory są nieco ograniczone w Javie, sposób udostępniania metod w pakietach jest ograniczony do metod publicznych. Czasami upublicznienie metody jest niebezpieczne, ale musi to być spowodowane brakiem odpowiednich modyfikatorów. Moje rozwiązanie pokonuje to ograniczenie.

Specyfikacja języka Java nie zezwala obecnie na chroniony modyfikator metod interfejsu. Możemy wykorzystać ten fakt i zastosować chronione metody interfejsu dla tej nowej funkcji.

Jeśli metoda interfejsu jest oznaczona jako chroniona, a interfejs jest implementowany przez klasę w innym pakiecie, metoda nie musiałaby być publiczna, ale mogłaby być również prywatna lub przynajmniej chroniona pakietem. Metoda jest widoczna, jakakolwiek klasa deklaruje ją jako i dodatkowo widoczna w pakiecie źródłowym interfejsu (i pakietach podrzędnych?).

W ten sposób moglibyśmy udostępniać pewne metody w dobrze znanych pakietach.

A oto odpowiedź na to żądanie ulepszenia, które zostało zamknięte ze statusem Won't fix:

Ta propozycja jest próbą rozwiązania problemu w sposób, który zwiększa złożoność i powoduje szczególne przypadki, przy niewielkich korzyściach. Typowym sposobem rozwiązania tego problemu jest posiadanie klasy prywatnej, która implementuje interfejs publiczny. Metody implementacji są publiczne, ale znajdują się w klasie prywatnej, więc pozostają prywatne.

Alternatywą dostępną począwszy od Java 9 jest upublicznienie klas i metod, ale w module, który ma kwalifikowany eksport do określonych modułów „zaprzyjaźnionych”, zamiast być eksportowanym do ogółu społeczeństwa.

Tak więc autorytatywne wnioski z tego raportu o błędzie to:

• Obecna sytuacja nie ulegnie zmianie; interfejsy prawdopodobnie nigdy nie będą obsługiwać protectedmetod.
• Uzasadnieniem dla braku obsługi protectedmetod w interfejsach jest to, że „ zwiększa złożoność i specjalne przypadki dla niewielkiego rzeczywistego zysku ”.
• Od wersji Java 9 istnieje alternatywne podejście do zapewniania dostępu do metod na poziomie pakietu. Użyj Java Platform Module System (JPMS), aby „ upublicznić klasy i metody, ale w module, który ma kwalifikowany eksport do określonych modułów„ zaprzyjaźnionych ”, zamiast być eksportowanym do ogółu społeczeństwa ”.

Ponieważ klasa implementująca musi implementować WSZYSTKIE metody zadeklarowane w Twoim interfejsie, co by się stało, gdyby klasa implementująca znajdowała się w innym pakiecie?

Interfejs Jeśli chcesz użyć czegoś takiego, jak opisałeś, kontynuuj z klasami abstrakcyjnymi lub zagnieżdżonymi interfejsami.

Fragment ze stylu kodu o zmiennych interfejsowych, ale nadal ma zastosowanie do metod:

Zmienne interfejsu są niejawnie publiczne, ponieważ interfejsy mają zapewniać interfejs programowania aplikacji (API), który jest w pełni dostępny dla programistów języka Java do odwoływania się i implementacji we własnych aplikacjach. Ponieważ interfejs może być używany w pakietach Java, które różnią się od ich własnych, publiczna widoczność zapewnia, że ​​kod programu ma dostęp do zmiennej.

Deklarowanie wewnętrznych podinterfejsów jest dobrą praktyką, ale technicznie nie można deklarować swoich metod wewnętrznych, tak jak protectedw interfejsie w Javie.

Oczywiście możesz stworzyć inny interfejs do użytku wewnętrznego, który rozszerza interfejs publiczny:

package yourpackage;

public interface PublicInterface {

    public void doThing1();

    public void doThing2();

    public void doThing3();

}

package yourpackage;

interface InternalInterface extends PublicInterface {

    void doAnyInternalThing1();

    void doAnyInternalThing2();

}

Możesz użyć InternalInterfaceinterfejsu wewnątrz pakietu, ale powinieneś zaakceptować dowolny podtyp PublicInterface(w metodach publicznych):

package yourpackage;

public class SomeClass {

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

}

Poza pakietem użytkownicy mogą korzystać PublicInterfacebez problemów.

Zwykle programiści tworzą klasy abstrakcyjne w podobnych sytuacjach. Jednak w tym przypadku tracimy korzyści wynikające z wielokrotnego dziedziczenia.

Jedynym scenariuszem, w którym miałoby to sens, jest ograniczenie widoczności do tego samego pakietu. Wszystkie inne zastosowania protectednie mają zastosowania. W szczególności protectedmetody są często używane w celu zapewnienia dostępu do niektórych szczegółów implementacji niższego poziomu dla potomków. Ale deklarowanie tego w interfejsie nie ma sensu, ponieważ nie ma implementacji niższego poziomu do ujawnienia.

I nawet scenariusz pakietu nie jest tak naprawdę tym, o co chodzi w interfejsach.

Aby osiągnąć to, czego prawdopodobnie chcesz, potrzebujesz dwóch interfejsów, jednego do użytku wewnętrznego i jednego, który udostępniasz w publicznym API. (Z wewnętrzną możliwie, ale niekoniecznie rozszerzającą publiczną.) Lub, jak wskazywali inni, abstrakcyjna superklasa.

Metody chronione są zawsze dostępne dla podklasy tylko wtedy, gdy podklasa rozszerza klasę bazową.

W przypadku interfejsu podklasa nigdy nie rozszerza interfejsu. Implementuje interfejs.

Metody chronione są dostępne za pośrednictwem rozszerzenia, a nie narzędzia .

Interfejsy mają na celu ujawnienie metod światu zewnętrznemu . Zatem metody te są z natury publiczne. Jeśli jednak chcesz wprowadzić abstrakcję w ramach tej samej rodziny klas , możesz stworzyć inny poziom abstrakcji między Twoim interfejsem a klasą implementacji, czyli klasę abstrakcyjną. Przykład przedstawiono poniżej.

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
    }
}