Sekarang tidak semua deklarasi metode dalam Java Interface adalah abstrak publik, haruskah metode tersebut dideklarasikan dengan pengubah ini?

Dimulai dengan Java 8, defaultmetode diperkenalkan ke antarmuka. Secara efektif, ini berarti bahwa tidak semua metode dalam suatu interfaceare abstract.

Dimulai dengan Java 9 (mungkin), privatemetode akan diizinkan. Ini berarti bahwa tidak semua metode di dalam interfaceadalah public abstract.

Pertanyaan "Haruskah metode dalam antarmuka Java dideklarasikan dengan atau tanpa publicpengubah akses?" ditanya di Stack Overflow di /programming/161633/should-methods-in-a-java-interface-be-declared-with-or-without-a-public-access-m

Di sana, sebagian besar jawaban berpendapat bahwa public abstracttidak boleh digunakan karena tidak ada metode dalam interfacedapat apa pun selain public abstract. Tidak lagi demikian.

Jadi, mengingat fitur antarmuka baru ini, haruskah public abstractkata kunci digunakan dalam deklarasi metode antarmuka Java?

Dalam lingkungan spesifik saya, kami akan memiliki orang-orang yang berpengalaman insinyur perangkat lunak, tetapi tidak berpengalaman di Jawa, membaca kode Java dari waktu ke waktu. Saya merasa bahwa meninggalkan public abstractkata kunci sekarang akan menciptakan titik kebingungan tambahan bagi mereka yang tidak terbiasa dengan sejarah tentang bagaimana antarmuka memiliki aturan yang berbeda untuk menggunakan kata kunci ini.

— David Campbell
sumber

apakah Anda memeriksa Java 8 JLS? Bagian yang sama seperti pada jawaban yang diterima lama di SO menunjukkan bahwa pengenalan metode default tidak mengubah rekomendasi sebelumnya yang didasarkan pada pertimbangan redundansi yang sama: "Metode antarmuka yang tidak memiliki defaultpengubah atau staticpengubah secara implisit abstract... Itu diizinkan, tetapi berkecil hati karena masalah gaya, untuk menentukan secara berlebihan abstractpengubah untuk deklarasi metode seperti itu. " Mengapa Anda berharap bahwa segala sesuatu harus berubah?

— nyamuk

Saya pikir hal-hal mungkin berubah karena kondisi untuk suatu metode secara implisit abstractmenjadi semakin berbelit-belit. Di Java 9, kalimat yang sama mungkin, "Metode antarmuka yang tidak memiliki defaultpengubah atau staticpengubah atau privatepengubah secara abstrak ..." Selain itu, argumen tambahan untuk tidak secara eksplisit menggunakan kata kunci, yaitu, bahwa semua metode antarmuka public abstract, sekarang diperdebatkan.

— David Campbell

TBH Saya tidak mengerti alasan di balik metode "default", dan bahkan metode statis menjangkau di luar ruang lingkup apa yang biasanya dimaksudkan untuk dilakukan oleh antarmuka. Antarmuka tidak seharusnya dibebani dengan konkret. Itu sebabnya mereka adalah tipe yang berguna untuk referensi.

— Trixie Wolf

Metode standar @TrixieWolf memungkinkan antarmuka untuk berkembang. Sebelumnya, dan tidak seperti kelas, menambahkan metode akan merusak setiap implementasi; sekarang, Anda dapat mengembangkan antarmuka selama Anda memiliki calon bawaan yang baik. Pertimbangkan penambahan streamuntuk java.util.Collection, atau Map.getOrDefault(). Alternatifnya adalah membuat sub-antarmuka baru, dan membuat semua orang downcast, seperti Graphics2D, dan tidak ada yang menikmatinya!

— SusanW

Jawaban:

Untuk memperluas jawaban StackOverflow:

The publicakses pengubah tidak diperlukan karena

Setiap deklarasi metode dalam tubuh antarmuka secara implisit bersifat publik (§6.6). Itu diizinkan, tetapi berkecil hati karena masalah gaya, untuk secara berlebihan menentukan pengubah publik untuk deklarasi metode dalam antarmuka. ( Bagian 9.4 )
The abstractakses pengubah tidak diperlukan karena

Metode default adalah metode yang dideklarasikan dalam antarmuka dengan pengubah default; -nya tubuh selalu diwakili oleh blok .

Dan...

Metode antarmuka yang tidak memiliki pengubah standar atau pengubah statis secara implisit abstrak , sehingga tubuhnya diwakili oleh tanda titik koma , bukan blok.

Karena metode default memiliki badan, dan yang tidak bersifat abstrak, dan setiap deklarasi metode pada antarmuka bersifat publik, Anda tidak perlu menentukan kata kunci mana pun.

Salah satu komentar pada jawaban mengatakan:

Jangan membuat mereka berpikir! Saya selalu menambahkan abstrak publik sebelumnya, meskipun gaya polisi, karena itu membuat semuanya jelas dan mengingatkan pembaca. Sekarang saya dibenarkan karena Java 8 dan 9 menyulitkan (user949300)

Sebuah komentar pada pertanyaan StackOverflow (terpilih 18 kali) membantah ini:

Ini buruk karena menuliskannya sebagai publik menyiratkan bahwa itu bisa non-publik (Pacerier)

Implikasi kode, terutama antarmuka, adalah penting.

— Greg Burghardt
sumber

Komentar yang Anda kutip dari StackOverflow sekarang kedaluwarsa. Mengatakan bahwa menambahkan pengubah publik adalah tulisan yang buruk karena itu menyiratkan hal itu dapat non-publik bertentangan. Metode ini bisa bersifat non-publik.

— David Campbell

@ DavidVampbell: Yah, saya pikir pertanyaan ini mungkin lebih baik ditanyakan setelah Java 9 keluar. :) Spesifikasi Java yang saat ini belum difinalisasi mungkin menjawab pertanyaan ini.

— Greg Burghardt

Bukankah kurangnya implikasi pernyataan blok cukup? Apakah Anda akan menyatakannya extends Objectmeskipun tersirat?

Jika pengembang tidak memahami redundansi, kemungkinan mereka mungkin tidak sepenuhnya memahami konsep di balik fitur bahasa , yang merupakan masalah yang lebih besar daripada bingung tentang pengubah.

Pengembang harus memahami bahwa tujuan antarmuka adalah untuk membuat kontrak yang menentukan bagaimana klien dapat berinteraksi dengan suatu objek. Ini menyarankan metode apa pun dalam antarmuka yang digunakan untuk interaksi objek harus diekspos kepada klien.

Jika Anda mendeklarasikan metode pribadi, Anda secara eksplisit menyatakan bahwa metode ini tidak dimaksudkan untuk dipanggil oleh klien, yang dalam hal antarmuka adalah sesuatu yang tidak dapat dengan mudah disimpulkan.

— Vince Emigh
sumber

Jangan membuat mereka berpikir! Saya selalu menambahkan public abstractsebelumnya, terlepas dari gaya polisi, karena itu membuat semuanya menjadi jelas dan mengingatkan pembaca. Sekarang saya dibenarkan karena Java 8 dan 9 menyulitkan hal-hal :-). Java sudah banyak yang mubazir.

— user949300

@ user949300 Apakah Anda juga menambahkan extends Objectke setiap kelas yang langsung berasal Object? Ini adalah informasi yang harus diketahui oleh pengembang, itulah sebabnya disimpulkan. Semakin sedikit informasi yang tidak berguna di layar, semakin mudah untuk memproses informasi penting. Semoga saya sudah meyakinkan Anda untuk datang ke sisi gelap (mengerti? Karena hal-hal implisit tidak dapat dilihat). Jika tidak, itu layak dicoba haha. Pada akhirnya, tergantung pada apa yang membuat kode lebih mudah dikelola untuk pengembang

— Vince Emigh

@ user949300 Dengan melakukan ini, Anda cenderung membuat kebingungan tentang apa artinya ketika metode antarmuka tidak mengandung deklarasi ini. yaitu jika ada pengembang yang mempelajari java dengan melihat kode Anda, Anda berpotensi tertatih-tatih memahami sintaks deklarasi antarmuka.

— JimmyJames

Vince, tidak, saya tidak akan memperpanjang Object, meskipun saya tidak cocok ketika saya melihat kode yang melakukannya. @ JimmyJames, jika ada yang konsisten menambahkan abstrak publik ke item yang demikian, saya tidak melihat adanya kebingungan. Apakah saya melewatkan sesuatu? OTOH, saya melihat maksud Anda tentang kekacauan. Sebagai contoh, saya tidak menambahkan finalargumen metode sebelum kecuali sesuatu yang lucu mengharuskannya (seperti kelas dalam anonim dll ...)

— user949300

@ user949300 Maksudnya jika seorang pengguna telah terpapar dengan kurangnya pengubah dan alasan di baliknya, mereka mungkin mempertanyakan mengapa pengubah ada di sana ketika mereka melihatnya, membuat mereka beranggapan mungkin ada alasan sebenarnya di baliknya selain sekadar eksplisit. . Saya tidak akan melempar korek api jika melihat extends Object, tetapi pasti akan menaikkan bendera dan membuat saya mempertanyakan mengapa. Seperti yang saya sebutkan di posting, melakukan hal-hal seperti itu dapat menyiratkan bahwa pengembang mungkin memiliki kesalahpahaman tentang cara kerja sesuatu (mungkin tidak tahu bahwa semua objek sudah diperluas Object, maka ekstensi eksplisit)

— Vince Emigh