2009-03-13 20 views
133

Użyłem funkcji refaktoryzacji "pull interface" w Eclipse już dziś, aby stworzyć interfejs oparty na istniejącej klasie. Okno dialogowe zaproponowało utworzenie wszystkich nowych metod nowego interfejsu jako metod "abstrakcyjnych".Dlaczego można zadeklarować metodę interfejsu Java jako abstrakcyjną?

Jakie byłyby tego korzyści?

Pomyślałem, że fakt, że można było zadeklarować metody interfejsu jako abstrakcyjne, był zbędną i nieszkodliwą cechą języka, który nie jest szczególnie zachęcający.

Dlaczego Eclipse miałby wspierać taki styl lub dlaczego ktoś dobrowolnie zdecydowałby się na taki styl?

Wyjaśnienie: Nie pytam, dlaczego metody interfejsu są abstrakcyjne, to oczywiste. Pytam, dlaczego ktoś zdecydowałby się wyraźnie oznaczyć je jako abstrakcyjne, ponieważ jeśli są one w interfejsie, to i tak są abstrakcyjne.

Odpowiedz

140

Zgodnie z Java Language Specification, słowo kluczowe abstract dla interfejsów jest przestarzałe i nie powinno być już używane. (Sekcja 9.1.1.1)

To powiedziawszy, ze skłonnością Javy do kompatybilności wstecznej, naprawdę wątpię, czy kiedykolwiek coś zmieni, czy słowo kluczowe abstract jest obecne.

+1

To było moje zrozumienie (chociaż nie byłem zaznajomiony z konkretną sekcją JLS). Zastanawiam się, dlaczego Eclipse zaoferowałby mi opcję tworzenia znaku obselete ... – Uri

+0

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

+2

tsk tsk ... Bez ostrzeżenia, że ​​jest obselete ... – Uri

9

Zgodnie z metodami JLS w interfejsach są domyślnie abstrakcyjne, więc słowo kluczowe jest zbędne. Wiedząc o tym, nigdy nie użyłbym go do "uniknięcia bałaganu prezentacyjnego".

+0

To powinna być właściwa odpowiedź. Oto zaktualizowany [link] (http://docs.oracle.com/javase/tutorial/java/IandI/abstract.html) - patrz sekcja "Uwaga" – mork

+0

JLS nie mówi, że słowo kluczowe jest przestarzałe dla metod w interfejsach. Mówi: "Zezwala się, ale odradza się, że jest stylem, aby redundantnie określić publiczny i/lub abstrakcyjny modyfikator dla metody zadeklarowanej w interfejsie." [JLS # 9.4] (http://docs.oracle.com/javase/specs/jls/se7/html/jls-9.html#jls-9.4). – EJP

+0

@EJP Nie powiedziałem, że JLS stwierdził, że słowo kluczowe będzie przestarzałe, to była moja osobista opinia;) BTW zauważają, że to słowo kluczowe jest "zbędne", co nie jest takie samo jak przestarzałe, w tym masz rację kierunek. Teraz, gdy wiem, będę edytować odpowiedź, aby to wyjaśnić. – dhiller

38

„beneficjum z tego” (dodawanie streszczenie na temat metod interfejsu oświadczenie) w Eclipse byłby stary kompatybilność problem z jdt eclipse compiler in jdk1.3

Od 1.4, biblioteki JDK nie są już zawierający domyślne metody abstrakcyjne (na abstrakcyjnych klas implementowanie interfejsów).
To oszukiwanie diagnozy kompilatora Eclipse 1.3, ponieważ ich implementacja polega na ich istnieniu.
Należy zauważyć, że Javac 1.3 całkowicie odmówiłby wykonania przeciwko 1.4 bibliotekom (przy użyciu opcji -bootclasspath).

Ponieważ kompilator Eclipse prawdopodobnie będzie w 1.4 poziom zgodności (patrz Workbench>Preferences>Java>Compiler>JDK Compliance) lub wykorzystać co najmniej 1,3 bibliotek klas czy stosując 1,3 trybu zgodności, obecność „streszczenie” nie jest wymagane w większości prądu Zaćmienie projektów.

+3

Dobre znalezisko. Tak więc jest to funkcjonalność do obejścia nie istniejącego już problemu w kompilatorze Eclipse. – jdmichal

+1

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

34

Z Java SE 7 JLS (Specyfikacja języka Java): "Zezwala się, ale można odstroić, aby redundantnie określić publiczny i/lub abstrakcyjny modyfikator dla metody zadeklarowanej w interfejsie."

Dla Java SE 5.0: "Ze względu na kompatybilność ze starszymi wersjami platformy Java dozwolone jest, ale z pewnym zniechęceniem, redundantne określenie abstrakcyjnego modyfikatora dla metod zadeklarowanych w interfejsach."

Powiązane problemy