Pada mulanya nampaknya kaedah lalai membawa banyak ciri baharu kepada set arahan mesin maya Java. Akhirnya, pembangun perpustakaan akan dapat meningkatkan API tanpa memperkenalkan isu keserasian dengan kod klien. Dengan kaedah lalai, mana-mana kelas yang melaksanakan antara muka perpustakaan secara automatik menyesuaikan diri dengan kaedah lalai yang diperkenalkan oleh antara muka. Sebaik sahaja pengguna mengemas kini kelas yang dia laksanakan, adalah mudah untuk mengatasi kaedah lalai asal dengan kaedah yang lebih bermakna. Lebih baik lagi, pengguna boleh memanggil pelaksanaan lalai antara muka dan menambah logik perniagaan apabila mengatasi kaedah tersebut.
Setakat ini, sangat bagus. Walau bagaimanapun, menambah kaedah lalai semasa mencipta antara muka boleh menjadikan kod Java tidak serasi. Ini boleh difahami dengan mudah daripada contoh di bawah. Kami menganggap bahawa perpustakaan memerlukan salah satu antara mukanya sebagai input:
interface SimpleInput { void foo(); void bar(); } abstract class SimpleInputAdapter implements SimpleInput { @Override public void bar() { // some default behavior ... } }
Sebelum Java 8, sama dengan kaedah di atas untuk menggunakan antara muka dan kelas penyesuai secara bersama, ia adalah kaedah yang sangat biasa dalam Java bahasa pengaturcaraan Corak reka bentuk. Penyesuai ini biasanya disediakan oleh pembekal perpustakaan untuk menyelamatkan pengguna perpustakaan operasi tertentu. Walau bagaimanapun, jika ia disediakan dalam bentuk antara muka, ia sama seperti membenarkan pewarisan berbilang.
Kami selanjutnya menganggap bahawa pengguna menggunakan penyesuai berikut:
class MyInput extends SimpleInputAdapter { @Override public void foo() { // do something ... } @Override public void bar() { super.bar(); // do something additionally ... } }
Dengan pelaksanaan ini, akhirnya kami boleh berinteraksi dengan perpustakaan. Perhatikan cara kami mengatasi kaedah bar dan menambah kefungsian tambahan pada pelaksanaan lalai.
Apakah yang akan berlaku jika perpustakaan ini dialihkan ke Java 8? Pertama, pustaka kemungkinan besar akan menghentikan kelas penyesuai dan menggunakan kaedah lalai untuk menyediakan fungsi ini. Akhirnya, antara muka kelihatan seperti ini:
interface SimpleInput { void foo(); default void bar() { // some default behavior } }
Menggunakan antara muka baharu ini, pengguna boleh mengemas kini kodnya untuk menggunakan kaedah lalai dan bukannya kelas penyesuai asal. Akibat utama menggunakan antara muka dan bukannya kelas penyesuai ialah kelas itu boleh melanjutkan kelas lain dan bukannya penyesuai tertentu. Sekarang mari kita berlatih dan memindahkan kelas MyInput untuk menggunakan kaedah lalai. Memandangkan kami kini boleh melanjutkan kelas lain, kami melanjutkan kelas asas pihak ketiga. Kita tidak perlu mengambil berat tentang peranan kelas asas ini di sini, kita boleh menganggap bahawa ini bermakna untuk fungsi kita.
class MyInput extends ThirdPartyBaseClass implements SimpleInput { @Override public void foo() { // do something ... } @Override public void bar() { SimpleInput.super.bar(); // do something additionally ... } }
Untuk mencapai fungsi yang serupa dengan kelas asal, kami menggunakan sintaks baharu Java 8 untuk memanggil kaedah lalai antara muka yang ditentukan. Pada masa yang sama, alihkan beberapa logik dalam kaedah kami ke kelas asas. Pada ketika ini, anda mungkin menepuk bahu saya dan berkata, ini adalah pemfaktoran semula yang sangat baik!
Kami telah menggunakan perpustakaan ini dengan jayanya. Walau bagaimanapun, penyelenggara perlu menambah antara muka lain untuk menyediakan lebih banyak fungsi. Antara muka ini digantikan dengan antara muka ComplexInput, yang mewarisi daripada antara muka SimpleInput dan menambah kaedah baharu. Oleh kerana kaedah lalai umumnya selamat untuk ditambah, penyelenggara telah mengatasi kaedah lalai SimpleInput untuk menyediakan kaedah lalai yang lebih baik. Lagipun, ini adalah perkara biasa yang perlu dilakukan dengan kelas penyesuai.
interface ComplexInput extends SimpleInput { void qux(); @Override default void bar() { SimpleInput.super.bar(); // so complex, we need to do more ... } }
Ciri-ciri baharu membawa hasil yang begitu baik sehingga orang yang mengekalkan ThirdPartyBaseClass juga memutuskan untuk bergantung pada perpustakaan ini. Untuk melakukan kerja ini, ia melaksanakan antara muka ComplexInput dalam ThirdPartyLibrary.
Tetapi apakah maksud ini untuk kelas MyInput? Untuk melaksanakan antara muka ComplexInput secara tersirat, anda boleh mewarisi kelas ThirdPartyBaseClass, tetapi memanggil kaedah lalai SimpleInput tiba-tiba menjadi tidak sah. Akibatnya, kod pengguna gagal untuk disusun. Panggilan jenis ini kini dilarang kerana Java menganggap ia menyalahi undang-undang untuk memanggil kaedah kelas induk daripada subkelas bukan langsung. Anda hanya boleh memanggil kaedah lalai ini dalam ComplexInput, tetapi ini memerlukan anda untuk melaksanakan antara muka ini secara eksplisit dalam MyInput. Bagi pengguna perpustakaan, perubahan ini tidak dijangka!
Apa yang lebih pelik ialah masa jalan Java tidak mengenakan sekatan sedemikian. Pengesah JVM membenarkan kelas yang disusun untuk memanggil kaedah SimpleInput::foo, walaupun kelas itu mewarisi ThirdPartyBaseClass yang dikemas kini, dengan itu secara tersirat melaksanakan ComplexClass. Sekatan ini hanya wujud dalam pengkompil.
Atas ialah kandungan terperinci Adakah kaedah lalai Java 8 akan memecahkan kod pengguna?. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!