Teraz, gdy nie wszystkie deklaracje metod w interfejsie Java są publicznie abstrakcyjne, czy metody powinny być deklarowane za pomocą tych modyfikatorów?

14

Począwszy od Java 8, defaultmetody zostały wprowadzone do interfejsów. W efekcie oznacza to, że nie wszystkie metody interfacesą abstract.

Począwszy od Java 9 (być może), privatemetody będą dozwolone. Oznacza to, że nie wszystkie metody interfacesą public abstract.

Pytanie „Czy metody w interfejsie Java powinny być deklarowane z publicmodyfikatorem dostępu lub bez niego ?” został zapytany w Stack Overflow na /programming/161633/should-methods-in-a-java-interface-be-declared-with-or-without-a-public-access-m

Tam większość odpowiedzi twierdziła, że public abstractnie należy ich używać, ponieważ żadna metoda w nie interfacemoże być inna niż public abstract. Tak już nie jest.

Czy w związku z tymi nowymi funkcjami interfejsów należy public abstractużywać słów kluczowych w deklaracji metody interfejsu Java?

W moim specyficznym środowisku będziemy mieć ludzi, którzy są doświadczonymi inżynierami oprogramowania, ale nie mają doświadczenia w Javie, od czasu do czasu czytając kod Java. Wydaje mi się, że pominięcie public abstractsłów kluczowych stworzy dodatkowy zamieszanie dla osób, które nie są zaznajomione z historią tego, jak interfejsy mają różne reguły korzystania z tych słów kluczowych.

java coding-style interfaces coding-standards keywords David Campbell
źródło
5
sprawdziłeś JLS Java 8? Ta sama sekcja, co w starej zaakceptowanej odpowiedzi w SO, sugeruje, że wprowadzenie metod domyślnych nie zmieniło wcześniejszej rekomendacji opartej na tych samych względach dotyczących redundancji: „Metoda interfejsu bez defaultmodyfikatora lub staticmodyfikatora jest domyślnie abstract... Jest dozwolona, ​​ale odradzane ze względu na styl, aby nadmiarowo określać abstractmodyfikator takiej deklaracji metody. ” Dlaczego oczekujesz, że wszystko się zmieni?
komar
3
Pomyślałem, że wszystko może się zmienić, ponieważ warunki niejawnej metody abstractstają się coraz bardziej skomplikowane. W Javie 9 to samo zdanie może brzmieć: „Metoda interfejsu pozbawiona defaultmodyfikatora lub staticmodyfikatora lub privatemodyfikatora jest domyślnie abstrakcyjna ...” Ponadto dodatkowe argumenty przemawiające za tym, aby nie używać słów kluczowych, a mianowicie, że wszystkie metody interfejsu są public abstract, są teraz dyskusyjne.
David Campbell,
TBH Nie rozumiem uzasadnienia metod „domyślnych”, a nawet metody statyczne wykraczają poza zakres tego, do czego zwykle służą interfejsy. Interfejsy nie powinny być obciążone konkrecją. Dlatego są przydatnymi typami referencji.
Trixie Wolf
1
Domyślne metody @TrixieWolf umożliwiają ewolucję interfejsów. Wcześniej, w przeciwieństwie do klas, dodanie metody zepsułoby każdą implementację; teraz możesz rozwinąć interfejs, o ile masz dobrego domyślnego kandydata. Rozważyć dodanie streamdo java.util.Collectionlub Map.getOrDefault(). Alternatywą jest stworzenie nowego pod-interfejsu i zachęcenie wszystkich do spowolnienia, takich jak Graphics2D, i nikomu się to nie podobało!
SusanW,

Odpowiedzi:

2

Aby rozwinąć odpowiedź StackOverflow:

  1. publicModyfikator dostępu nie jest potrzebna, ponieważ

    Każda deklaracja metody w treści interfejsu jest domyślnie jawna (§6.6). Dozwolone, ale odradzane ze względu na styl, nadmiarowe określanie publicznego modyfikatora deklaracji metody w interfejsie. ( Sekcja 9.4 )

  2. abstractModyfikator dostępu nie jest potrzebna, ponieważ

    Metoda domyślna to metoda zadeklarowana w interfejsie z domyślnym modyfikatorem; jego ciało jest zawsze reprezentowane przez blok .

    I...

    Metoda interfejsu bez domyślnego modyfikatora lub modyfikatora statycznego jest domyślnie abstrakcyjna , więc jego ciało jest reprezentowane przez średnik , a nie blok.

Biorąc pod uwagę, że metody domyślne mają treść, a te, które nie są z natury abstrakcyjne, a każda deklaracja metody w interfejsie jest z natury jawna, nie trzeba określać żadnego słowa kluczowego.

Jeden z komentarzy do odpowiedzi brzmiał:

Nie każ im myśleć! Zawsze dodawałem publicznie streszczenie, pomimo stylu policyjnego, ponieważ wszystko to wyjaśniło i przypomniało czytelnikowi. Teraz jestem potwierdzony, ponieważ Java 8 i 9 komplikują sprawy (user949300)

Komentarz do pytania StackOverflow (głosowany w górę 18 razy) obala to:

Jest źle, ponieważ pisanie go jako publicznego sugeruje, że może być niepubliczne (Pacerier)

Znaczenie implikacji kodu, zwłaszcza interfejsów, jest ważne.

Greg Burghardt
źródło
Komentarz cytowany przez StackOverflow jest teraz nieaktualny. Mówienie, że dodanie publicznego modyfikatora jest złym pisaniem, ponieważ sugeruje, że może być niepubliczne, jest sprzeczne. Metoda może być niepubliczna.
David Campbell
@DavidCampbell: Cóż, myślę, że lepiej zadać to pytanie, kiedy pojawi się Java 9. :) Specyfikacja Java, która ma zostać ukończona, może odpowiedzieć na to pytanie.
Greg Burghardt
1

Czy nie wystarczy brak implikacji instrukcji blokowej? Czy zadeklarowałbyś, extends Objectchoć jest to dorozumiane?

Jeśli programista nie zrozumie redundancji, istnieje duże prawdopodobieństwo , że nie w pełni zrozumieją koncepcję funkcji językowej , co stanowi jeszcze większy problem niż dezorientacja w zakresie modyfikatorów.

Deweloper musi zrozumieć, że celem interfejsu jest utworzenie umowy określającej sposób interakcji klienta z obiektem. Sugeruje to, że każda metoda interfejsu używana do interakcji z obiektami powinna być dostępna dla klientów.

Jeśli deklarujesz metodę jako prywatną, wyraźnie stwierdzasz, że metoda ta nie powinna być wywoływana przez klientów, co w przypadku interfejsów jest czymś, czego nie można łatwo wywnioskować.

Vince Emigh
źródło
2
Nie każ im myśleć! Zawsze dodawałem public abstractwcześniej, pomimo stylu policji, bo to wszystko wyjaśniło i przypomniało czytelnikowi. Teraz jestem usprawiedliwiony, ponieważ Java 8 i 9 komplikują rzeczy :-). Java jest już dużo redundantna.
user949300
1
@ user949300 Czy dodałbyś także extends Objectdo każdej klasy, z której bezpośrednio pochodzi Object? Są to informacje, o których deweloper powinien już wiedzieć, i dlatego są one wywnioskowane. Im mniej bezużyteczne informacje na ekranie, tym łatwiej jest przetwarzać ważne informacje. Mam nadzieję, że przekonałem cię do przejścia na ciemną stronę (rozumiesz? Bo nie można zobaczyć ukrytych rzeczy). Jeśli nie, warto było spróbować haha. Ostatecznie sprowadza się to do tego, co ułatwia zarządzanie kodem dla programisty
Vince Emigh
@ user949300 W ten sposób istnieje większe prawdopodobieństwo, że wprowadzisz zamieszanie co do tego, co oznacza, że ​​metody interfejsu nie zawierają tych deklaracji. tzn. jeśli są jacyś programiści uczący się języka Java, patrząc na twój kod, potencjalnie masz problem z ich zrozumieniem składni deklaracji interfejsu.
JimmyJames,
Vince, nie, nie rozszerzałbym Objecta, chociaż nie rzucam się na niego, gdy widzę kod, który to robi. @JimmyJames, jeśli ktoś konsekwentnie dodaje publiczne streszczenie do przedmiotów, które są takie, nie widzę żadnych nieporozumień. Czy coś brakuje? OTOH, rozumiem twój punkt na bałaganie. Na przykład nie dodam finalargumentów metody przed, chyba że wymaga tego coś zabawnego (jak anonimowa klasa wewnętrzna itp.)
user949300,
@ user949300 Miał na myśli, że jeśli użytkownik był już narażony na brak modyfikatorów i powód tego, może zapytać, dlaczego modyfikatory są tam, kiedy je widzą, co oznacza, że ​​zakładają, że może istnieć rzeczywisty powód inny niż tylko jawne . Nie rzuciłbym się na niego, gdybym to zobaczył extends Object, ale na pewno podniosłoby flagę i skłoniło mnie do pytania, dlaczego. Jak wspomniałem w poście, robienie takich rzeczy może sugerować, że deweloper może mieć niezrozumienie tego, jak coś działa (może nie wiedzieć, że wszystkie obiekty już się rozszerzają Object, stąd wyraźne rozszerzenie)
Vince Emigh