Argumen terakhir dalam metode antarmuka - apa gunanya?

Di Jawa, sangat sah untuk mendefinisikan finalargumen dalam metode antarmuka dan tidak mematuhinya dalam kelas implementasi, misalnya:

public interface Foo {
    public void foo(int bar, final int baz);
}

public class FooImpl implements Foo {

    @Override
    public void foo(final int bar, int baz) {
        ...
    }
}

Dalam contoh di atas, bardan bazmemiliki finaldefinisi yang berlawanan di kelas VS antarmuka.

Dengan cara yang sama, tidak ada finalbatasan yang diberlakukan ketika satu metode kelas memperluas yang lain, baik abstractatau tidak.

Meskipun finalmemiliki beberapa nilai praktis di dalam tubuh metode kelas, apakah ada titik yang menentukan finalparameter metode antarmuka?

Sepertinya tidak ada gunanya. Menurut Spesifikasi Bahasa Jawa 4.12.4 :

Mendeklarasikan variabel final dapat berfungsi sebagai dokumentasi yang bermanfaat bahwa nilainya tidak akan berubah dan dapat membantu menghindari kesalahan pemrograman.

Namun, finalpengubah pada parameter metode tidak disebutkan dalam aturan untuk mencocokkan tanda tangan metode yang diganti, dan itu tidak berpengaruh pada pemanggil, hanya dalam tubuh implementasi. Juga, seperti dicatat oleh Robin dalam komentar, finalpengubah pada parameter metode tidak berpengaruh pada kode byte yang dihasilkan. (Ini tidak benar untuk penggunaan lain dari final.)

Beberapa IDE akan menyalin tanda tangan dari metode abstrak / antarmuka saat memasukkan metode implementasi di sub kelas.

Saya tidak percaya ada bedanya dengan kompiler.

EDIT: Sementara saya percaya ini benar di masa lalu, saya tidak berpikir IDE saat ini melakukan ini lagi.

Anotasi akhir parameter metode selalu hanya relevan dengan implementasi metode tidak pernah ke pemanggil. Oleh karena itu, tidak ada alasan nyata untuk menggunakannya dalam tanda tangan metode antarmuka. Kecuali jika Anda ingin mengikuti standar pengkodean yang konsisten yang sama, yang membutuhkan parameter metode akhir, di semua tanda tangan metode. Maka itu bagus untuk dapat melakukannya.

Pembaruan: Jawaban asli di bawah ditulis tanpa sepenuhnya memahami pertanyaan, dan karena itu tidak secara langsung menjawab pertanyaan tersebut. :)Namun, itu harus informatif bagi mereka yang ingin memahami penggunaan finalkata kunci secara umum .

Adapun pertanyaannya, saya ingin mengutip komentar saya sendiri dari bawah.

Saya percaya Anda tidak dipaksa untuk mengimplementasikan finalitas argumen agar Anda bebas memutuskan apakah itu final atau tidak dalam implementasi Anda sendiri.

Tapi ya, kedengarannya agak aneh bahwa Anda dapat mendeklarasikannya finaldi antarmuka, tetapi memilikinya non-final dalam implementasi. Akan lebih masuk akal jika:

Sebuah. finalkata kunci tidak diizinkan untuk argumen metode antarmuka (abstrak) (tetapi Anda dapat menggunakannya dalam implementasi), atau
b. mendeklarasikan argumen seperti finalpada antarmuka akan memaksanya dinyatakan finaldalam implementasi (tetapi tidak dipaksakan untuk non-final).

Saya dapat memikirkan dua alasan mengapa metode tanda tangan dapat memiliki finalparameter: Kacang dan Objek ( Sebenarnya, keduanya adalah alasan yang sama, tetapi konteks yang sedikit berbeda. )

Benda:

public static void main(String[] args) {
    StringBuilder cookingPot = new StringBuilder("Water ");
    addVegetables(cookingPot);
    addChicken(cookingPot);
    System.out.println(cookingPot.toString());
    // ^--- OUTPUT IS: Water Carrot Broccoli Chicken ChickenBroth 
    //      We forgot to add cauliflower. It went into the wrong pot.
}

private static void addVegetables(StringBuilder cookingPot) {
    cookingPot.append("Carrot ");
    cookingPot.append("Broccoli ");
    cookingPot = new StringBuilder(cookingPot.toString());
    //   ^--- Assignment allowed...
    cookingPot.append("Cauliflower ");
}

private static void addChicken(final StringBuilder cookingPot) {
    cookingPot.append("Chicken ");
    //cookingPot = new StringBuilder(cookingPot.toString());
    //     ^---- COMPILATION ERROR! It is final.
    cookingPot.append("ChickenBroth ");
}

Kata finalkunci memastikan bahwa kami tidak akan secara tidak sengaja membuat panci memasak lokal baru dengan menunjukkan kesalahan kompilasi ketika kami berusaha melakukannya. Ini memastikan kaldu ayam ditambahkan ke panci masak asli kami yang addChickenmetodenya didapat. Bandingkan ini dengan addVegetablestempat kami kehilangan kembang kol karena menambahkan bahwa ke panci memasak lokal baru, bukan pot asli yang didapat.

Kacang: Ini adalah konsep yang sama dengan objek (seperti yang ditunjukkan di atas) . Kacang pada dasarnya ada Objectdi Jawa. Namun, kacang (JavaBeans) digunakan dalam berbagai aplikasi sebagai cara mudah untuk menyimpan dan menyebarkan koleksi data terkait yang telah ditentukan. Sama seperti yang addVegetablesbisa mengacaukan proses memasak dengan membuat panci memasak baru StringBuilderdan membuangnya bersama kembang kol, itu juga bisa melakukan hal yang sama dengan panci memasak JavaBean .

Saya percaya itu mungkin detail yang berlebihan, apakah itu final atau tidak adalah detail implementasi.

(Semacam suka menyatakan metode / anggota dalam antarmuka sebagai publik.)