Po co deklarować metodę interfejsu Java jako abstrakcyjną?

143

Użyłem dziś funkcji refaktoryzacji „pull interface” Eclipse, aby stworzyć interfejs oparty na istniejącej klasie. W oknie dialogowym można było utworzyć wszystkie nowe metody nowego interfejsu jako metody „abstrakcyjne”.

Jaka byłaby z tego korzyść?

Pomyślałem, że to, że wolno ci deklarować metody interfejsu jako abstrakcyjne, jest zbyteczną i nieszkodliwą cechą języka, która nie jest szczególnie zalecana.

Dlaczego Eclipse miałby wspierać taki styl lub dlaczego ktoś miałby to zrobić dobrowolnie?

Wyjaśnienie: nie pytam, dlaczego metody interfejsu są abstrakcyjne, to oczywiste. Pytam, dlaczego ktoś miałby wyraźnie oznaczyć je jako abstrakcyjne, skoro jeśli są w interfejsie, i tak są abstrakcyjne.

— Uri
źródło

146

Według języka Java Specification The abstractkluczowe dla interfejsów jest przestarzała i nie powinny być dłużej stosowane. (Sekcja 9.1.1.1)

To powiedziawszy, biorąc pod uwagę skłonność Javy do wstecznej kompatybilności, naprawdę wątpię, czy kiedykolwiek będzie miało znaczenie, czy abstractsłowo kluczowe jest obecne.

— jdmichal
źródło

1

To było moje zrozumienie (chociaż nie znałem konkretnej sekcji JLS). Zastanawiam się, dlaczego Eclipse oferuje mi opcję tworzenia przestarzałego oznaczenia ...

— Uri

Masz mnie. Ktoś gdzieś musiał zdecydować, że to pożądana "funkcja" i umieścić ją. Wiesz, jeden z tych przebiegłych typów open-source :)

— jdmichal

18

Chociaż jest to najwyżej oceniana odpowiedź, odnosi się do niewłaściwej sekcji Specyfikacji; 9.1.1.1 opisuje abstractsłowo kluczowe w deklaracji samego interfejsu, a nie na jego elementach członkowskich. Odpowiedź @ Will poniżej jest poprawna i zawiera również prawidłowe źródła linków.

— Shaggy Frog

39

"Korzyści z tego" (dodanie abstraktu do deklaracji metod interfejsu) w eclipse byłoby starym problemem ze zgodnością z kompilatorem jdt eclipse w jdk1.3

Od wersji 1.4 biblioteki jdk nie zawierają już domyślnych metod abstrakcyjnych (w klasach abstrakcyjnych implementujących interfejsy).
Jest to oszukanie diagnozy kompilatora Eclipse 1.3, ponieważ ich implementacja opiera się na ich istnieniu.
Zauważ, że Javac 1.3 całkowicie odmówiłby działania na bibliotekach 1.4 (używając opcji -bootclasspath).

Ponieważ kompilator Eclipse prawdopodobnie będzie na poziomie zgodności 1.4 (zobacz Workbench>Preferences>Java>Compiler>JDK Compliance) lub użyje bibliotek klas co najmniej 1.3, jeśli używany jest tryb zgodności 1.3, obecność „abstrakcji” nie jest wymagana w większości obecnych projektów Eclipse.

— VonC
źródło

3

Dobre znalezisko. Zatem funkcjonalność polega na obejściu nieistniejącego już problemu w kompilatorze Eclipse.

— jdmichal

1

@jdmichal: dokładnie i jest to również dokładniejsza odpowiedź na pytanie Uri.

— VonC

39

Z Java SE 7 JLS (specyfikacja języka Java): „Jest dozwolone, ale ze względu na styl odradzane, nadmiarowe określanie modyfikatora publicznego i / lub abstrakcyjnego dla metody zadeklarowanej w interfejsie”.

W przypadku języka Java SE 5.0 : „W celu zapewnienia zgodności ze starszymi wersjami platformy Java, ze względu na styl, dozwolone jest, ale odradzane, nadmiarowe określanie modyfikatora abstrakcyjnego dla metod zadeklarowanych w interfejsach”.

— Będzie
źródło

9

Według JLS metody w interfejsach są domyślnie abstrakcyjne, więc słowo kluczowe jest redundantne. Wiedząc o tym, nigdy nie użyłbym go, aby „uniknąć bałaganu prezentacyjnego”.

— Daniel Hiller
źródło

To powinna być właściwa odpowiedź. Oto zaktualizowany link - zobacz sekcję "uwaga"

— mork

JLS nie mówi, że słowo kluczowe jest przestarzałe dla metod w interfejsach. Mówi: „Jest dozwolone, ale ze względu na styl odradzane, redundantne określanie publicznych i / lub abstrakcyjnych modyfikatorów dla metody zadeklarowanej w interfejsie”. JLS # 9.4 .

— Markiz Lorne

@EJP Nie powiedziałem, że JLS stwierdził, że słowo kluczowe będzie przestarzałe, to była moja osobista opinia;) Przy okazji zauważają, że to słowo kluczowe jest "zbędne", co nie jest tym samym, co przestarzałe, w tym oczywiście masz rację . Teraz, gdy wiem, że poprawię odpowiedź, aby to wyjaśnić.

— Daniel Hiller,