Java arayüzü yöntemini neden soyut olarak bildirelim?


143

Mevcut bir sınıfa dayalı bir arayüz oluşturmak için bugün Eclipse'nin "pull interface" refactoring özelliğini kullandım. İletişim kutusu, yeni arabirimin tüm yeni yöntemlerini "soyut" yöntem olarak oluşturmayı teklif etti.

Bunun yararı ne olurdu?

Arayüz yöntemlerini soyut olarak ilan etmenize izin verilmesinin, dilin özellikle teşvik edilmeyen gereksiz ve zararsız bir özelliği olduğunu düşündüm.

Eclipse neden böyle bir stili desteklesin, ya da neden biri bunu gönüllü olarak yapmayı seçsin?

Açıklama: Arayüz yöntemlerinin neden soyut olduğunu sormuyorum, bu açıktır. Birini neden soyut olarak işaretlemeyi seçtiğini soruyorum, çünkü eğer bir arayüzdeyse, yine de soyutturlar.

Yanıtlar:


146

Göre Java Dil Şartname , abstractarabirimler için anahtar kelime eskimiş ve artık kullanılmalıdır. (Bölüm 9.1.1.1)

Bununla birlikte, Java'nın geriye dönük uyumluluk eğilimi ile, abstractanahtar kelimenin mevcut olup olmadığını hiç değiştirmeyeceğinden şüpheliyim .


1
Bu benim anlayışımdı (belirli JLS bölümüne aşina olmasam da). Eclipse'in neden obselete işareti oluşturma seçeneği sunduğunu merak ediyorum ...
Uri

Beni yakaladın. Birisi bir yerde istenen bir "özellik" olduğuna karar verdi ve koymak. Bilirsiniz, bu
wily

18
Her ne kadar bu en iyi yanıt olsa da, Spesifikasyonun yanlış bölümüne atıfta bulunur; 9.1.1.1, abstractanahtar kelimeyi üyelerine değil, arayüzün kendisinin beyanına ilişkin olarak tanımlamaktadır . @ Will'in aşağıdaki cevabı doğrudur ve geçerli bağlantı kaynakları da içerir.
Shaggy Frog

39

Tutulmada "faydası" (arabirim yöntemleri bildirimi üzerine özet ekleyerek) jdk1.3 jdt eclipse derleyici ile eski bir uyumluluk sorunu olurdu

1.4'ten bu yana, jdk kütüphaneleri artık varsayılan soyut yöntemler içermemektedir (arabirimleri uygulayan soyut sınıflarda).
Bu, Eclipse 1.3 derleyici teşhisini kandırıyor çünkü uygulamaları varlıklarına dayanıyor.
Javac 1.3'ün 1.4 kitaplığa karşı (-bootclasspath seçeneği kullanılarak) çalışmayı tamamen reddedeceğini unutmayın.

Eclipse derleyicisinin 1.4 uyumluluk düzeyinde olması (bkz. Workbench>Preferences>Java>Compiler>JDK Compliance) Veya 1.3 uyumluluk modu kullanılıyorsa en az 1.3 sınıf kitaplığı kullanması muhtemel olduğundan , mevcut tutulma projelerinin çoğunda "özet" bulunması gerekmez.


3
İyi bulmak. Bu nedenle, Eclipse derleyicisinde artık var olmayan bir soruna geçici bir çözüm bulmak işlevseldir.
jdmichal

1
@jdmichal: ve aynı zamanda Uri'nin sorusuna daha doğru bir cevap.
VonC

39

Gönderen Java SE 7 JLS (Java Dil Özellikleri): "gereksiz yere bir yöntem için halkı ve / veya soyut değiştirici belirtmek için, izin verilen, ancak stil meselesi olarak önerilmez bir arayüzde ilan etti."

İçin Java SE 5.0 : "Java platformunun eski sürümleri ile uyumluluk için, izin verilen ancak stil meselesi olarak, cesaretini, yedekli yöntemleri için soyut değiştirici arayüzlerinde ilan belirtmek için."


9

JLS'ye göre arayüzlerdeki yöntemler varsayılan olarak soyuttur, bu nedenle anahtar kelime gereksizdir. Bunu bilerek, asla "sunum karmaşasından kaçınmak" için kullanmazdım.


Bu doğru cevap olmalı. İşte güncellenmiş bir bağlantı - bkz. "Not" bölümü
mork

JLS, anahtar kelimenin arabirimlerdeki yöntemler için kullanılmadığını söylemez. "Bir arabirimde bildirilen bir yöntemin genel ve / veya soyut değiştiricisini gereksiz olarak belirtmesine izin verilir, ancak bir stil meselesi olarak önerilmez." JLS # 9.4 .
Lorne

@EJP JLS, anahtar kelimenin eski olacağını belirtti, bu benim kişisel görüşüm değildi;) BTW, bu anahtar kelimenin "gereksiz" olduğunu ve bu gereksiz olanla aynı olmadığını belirtiyorlar, bu tabii ki haklısın . Şimdi bunu netleştirmek için cevabı düzenleyeceğimi biliyorum.
Daniel Hiller
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.