Munculnya Kotlin adalah bonus penting bagi pengembang. Bahasa tingkat tinggi yang berintegrasi mulus dengan Java sangat memperluas kemampuan programmer. Namun, dalam bahasa apa pun kita terus-menerus menghadapi beberapa masalah, yang, sebaliknya, membuat batasan, dan Kotlin, tentu saja, tidak terkecuali. Kami akan membicarakannya hari ini.
Kotlin sangat antusias tentang komunitas, karena bahasa pemrograman baru sangat menyederhanakan penulisan kode, menggantikan Java. Ini terutama terlihat pada Android, di mana versi baru Java muncul, dengan kata lain, "dengan derit". Banyak perangkat diperbarui dengan penundaan lama, bahkan lebih - mereka tidak menerima pembaruan firmware sama sekali. Dalam kasus terbaik, dukungan untuk perangkat berakhir sekitar 2 tahun setelah dirilis, yang menjanjikan satu, maksimum dua pembaruan sistem. Namun, orang terus menggunakan perangkat, yang berarti pengembang harus bergantung pada (sejauh ini) Android 8 terbaru, dan Android 5, atau bahkan versi sebelumnya, di mana tentu saja tidak hanya yang terbaru, tetapi bahkan implementasi Java saat ini. Sebagai referensi, sekarang total pangsa Android 7 dan 8 - versi di mana Java 8 didukung oleh pustaka sistem - adalah 42,9%, sisanya adalah Java 7.
Beberapa orang mungkin mengatakan bahwa Java sudah usang. Namun ada juga yang berpendapat bahwa Java adalah bahasa yang “baik” dan tidak boleh disentuh. Ini seperti GCD (faktor umum terbesar) dalam matematika. Ini berisi serangkaian fungsi pria, dan bagi mereka yang membutuhkan fitur tambahan hari ini, tersedia bahasa khusus yang sudah berfungsi di atas JVM. Cukup banyak dari bahasa-bahasa ini yang telah dikembangbiakkan: Scala, Clojure, JRuby, Jython, Groovy, dan lainnya, kurang dikenal. Namun, Kotlin memiliki sejumlah keunggulan. Bahasa ini membuat programmer lebih bebas: ini memungkinkan Anda untuk menggunakan fragmen yang sudah jadi di Jawa secara bersamaan, menggabungkan kode lama dan baru.
Tetapi dengan semua kelebihan dari bahasa baru, yang kami tidak pernah sangkal, selama proses pengembangan beberapa kelemahan ditemukan di dalamnya. Dan hari ini akan menarik untuk mendengar pendapat rekan kerja tentang apakah mereka mengganggu pekerjaan dengan cara yang sama seperti kita.
Tidak bisa menyembunyikan pertunjukan?
Paket, seperti biasa, adalah cara yang cukup umum untuk mengatur kelas berdasarkan namespace. Tetapi nilai tambah mereka tidak hanya ini, di Jawa mereka juga bertindak sebagai sarana untuk membatasi visibilitas kelas dan anggota mereka.
Biarkan saya mengingatkan Anda bahwa di Jawa ada 4 kategori berbeda yang memungkinkan Anda untuk membedakan antara visibilitas. Hanya ada dua dari mereka untuk kelas - mereka terlihat baik di dalam paket (paket pribadi) atau benar-benar terbuka (umum). Tetapi metode atau bidang sudah dapat dibuat pribadi (tidak akan dapat diakses di luar kelas) hanya terlihat oleh paket (paket pribadi), dapat dibuat sehingga metode ini juga terlihat oleh ahli waris, baik dalam paketnya dan di luar paket (dilindungi), dan Anda juga dapat membuatnya terlihat oleh semua orang (publik).
Java 9 memperkenalkan kemampuan untuk memecah kode menjadi modul, dan sekarang dimungkinkan untuk membuat beberapa bagian dari kode terlihat di mana-mana di dalam modul, tetapi tidak dari luar. Dan ternyata sangat berguna untuk membangun API yang masuk akal.
Singkatnya, opsi di Jawa lebih dari cukup. Tetapi di Kotlin karena alasan tertentu mereka membatasi diri untuk memperkenalkan visibilitas publik dan pribadi, serta visibilitas bagi ahli waris. Selain itu, mereka memperkenalkan perbedaan dengan modul, tetapi menjadi tidak mungkin untuk membedakan akses ke metode dan kelas dengan paket. Modul tidak lagi merupakan konstruksi bahasa itu sendiri, dan cukup sering orang memahami hal-hal yang sangat berbeda dengan istilah ini. Kotlin secara resmi mendefinisikan modul sebagai "satu
set file Kotlin yang dikompilasi bersama ."
Tangkapannya adalah bahwa modul, sebagai suatu peraturan, mengarah pada biaya sumber daya tambahan. Pada saat yang sama, jika Anda membuat paket terpisah dan menempatkan kelas di dalamnya dengan fungsi yang hanya terlihat dalam paket ini, tidak ada masalah, karena semua paket akan dikompilasi bersama dan tidak ada sumber daya tambahan yang diperlukan.
Ini terutama diucapkan jika, misalnya, Anda mengumpulkan proyek di Gradle, seperti biasa, aplikasi Android dirakit. Modul biasanya dibuat relatif besar sehingga merupakan unit fungsional yang lengkap. Dalam satu modul, metode tidak dapat dibuat terlihat oleh satu dan tidak terlihat oleh kelas lain. Dan jika kita ingin membuat penampilan metode lebih terperinci, masalah muncul.
Di sini, saya langsung ingin mengingat kembali paket-paket itu, karena di Kotlin esensi ini belum hilang, tetapi sayangnya, itu tidak mempengaruhi visibilitas. Tentu saja, Anda selalu dapat membuat lebih banyak modul, tetapi, mengingat fitur Gradle, ini tidak rasional: kecepatan build akan berkurang. Ya, dimungkinkan untuk menempatkan kelas dalam satu file, tetapi dalam kasus proyek besar, file tersebut akan menjadi sangat “berat”. Oleh karena itu, saya ingin mendapatkan cara lain untuk menyembunyikan metode, misalnya, dimodelkan di Jawa.
Jangan memprosesnya ... bahkan jika itu perlu
Yang kedua agak kontroversial (karena beberapa menganggap penggunaannya sebagai berita buruk), namun minusnya adalah tidak adanya pengecualian yang diperiksa. Alat-alat ini ada di Jawa, tetapi Kotlin memutuskan untuk tidak mengimplementasikannya.
Dokumentasi resmi memiliki contoh tentang antarmuka yang dapat ditambahkan. Anda dapat melampirkan string ke Appendable, dan karena string dapat terhubung ke objek yang terkait dengan I / O, misalnya, saat menulis ke file atau ke jaringan, Anda berpotensi mendapatkan IOException saat memanggil metode antarmuka. Dan kasus-kasus seperti itu membuat penggunaan pengecualian yang diperiksa tidak nyaman.
Pembuat bahasa menjelaskan argumen mereka sebagai berikut: jika kita menggunakan StringBuilder, mengaksesnya melalui Appendable, ternyata kita perlu menangani IOException, bahkan jika Anda yakin itu tidak dapat terjadi pada prinsipnya:
Appendable log = new StringBuilder(); try { log.append(message); } catch (IOException e) {
Jalan keluar dari situasi: pengecualiannya adalah "tertangkap", tetapi mereka tidak melakukan apa-apa dengannya, yang tentu saja tidak baik. Namun, muncul pertanyaan: jika kita jelas bekerja dengan StringBuilder melalui antarmuka Appendable - mengapa tidak berinteraksi langsung dengan StringBuilder? Ada perbedaan penting: ketika bekerja dengan Appendable, jika kita tidak tahu implementasi spesifik apa yang ada di bawahnya, pengecualian input / output menjadi sangat mungkin, tetapi StringBuilder tidak akan memberikannya secara tepat, dan metode yang sesuai dinyatakan di dalamnya, meskipun mereka mengimplementasikan antarmuka. Jadi contohnya cukup ketat ...
Sangat menarik bahwa penulis dokumentasi merujuk pada Bab 77 di Java Efektif, yang menyatakan bahwa pengecualian tidak dapat ditangkap dan diabaikan. Tetapi hanya dalam bab-bab selanjutnya tertulis bahwa pengecualian yang diperiksa dapat dan harus digunakan jika dilakukan dengan bijak. Jika dikutip secara selektif, sudut pandang apa pun dapat dibenarkan.
Akibatnya, pengembang Kotlin membuatnya sehingga, pada dasarnya, semua metode berpotensi membuang semacam pengecualian. Tapi lalu di mana alat untuk menangani kesalahan dalam bahasa baru? Bagaimana sekarang memahami di mana pengecualian mungkin muncul? Pada tingkat bahasa, sayangnya, kami tidak menemukan bantuan dalam masalah ini, dan bahkan dengan kode sumber (yang jauh dari selalu tersedia tanpa mempertimbangkan berbagai trik), sulit untuk memahami apa yang harus dilakukan dalam setiap situasi tertentu.
Jika Anda mengajukan pertanyaan kepada pengembang, mereka hanya mengangkat bahu dan mengatakan bahwa
dalam bahasa lain tidak ada pengecualian yang diperiksa dan tidak ada , mereka juga membuat program yang besar dan andal. Tetapi mereka juga berhasil ditulis dalam bahasa yang tidak berhasil, ini bukan argumen. Di StackOverflow, mereka mengatakan kepada pertanyaan serupa bahwa "
Anda perlu membaca dokumentasi " - jawaban yang bagus, sangat nyaman dalam situasi seperti itu. Hanya dokumentasi yang mungkin tidak ada, mungkin tidak lengkap atau ketinggalan jaman - kompiler tidak memeriksanya. Akhirnya, Anda mungkin tidak menemukan jawabannya.
Ya, memang benar bahwa mengecek pengecualian dapat menyebabkan API tidak nyaman. Ketika memeriksa pengecualian jelas-jelas berlebihan sehingga kompiler "puas", Anda harus menulis coba ... tangkap dan sebenarnya hanya membuat kode sampah, karena tidak ada yang dilakukan saat memproses pengecualian ini. Dan fakta bahwa tidak nyaman untuk menggunakannya dalam kode fungsional juga benar. Tetapi pengecualian yang diperiksa hanyalah alat yang dapat digunakan dengan kompeten, jika perlu.
Tidak jelas mengapa bahasa mengambil kesempatan ini, jika filosofi Kotlin adalah untuk mempercayai lebih banyak alat kepada programmer (setidaknya, menurut kami), dan jika pembuat kode dapat dengan tepat menggambarkan di mana akan ada pengecualian, mengapa tidak percaya padanya? Ambil operator kelebihan beban yang sama yang dihapus dari Jawa, karena mereka dapat menyebabkan munculnya API dengan tindakan yang tidak jelas - ini untuk melindungi programmer dari diri mereka sendiri. Sebaliknya, Kotlin memiliki kemampuan untuk membebani operator dan melakukan banyak hal lainnya - jadi mengapa tidak ada pengecualian yang diperiksa? Mungkinkah pencipta melakukannya karena memang tidak seperti di Jawa?
Kami sedang menunggu perubahan ...
Maksimum yang dapat kita andalkan di Android adalah Java 7 atau Java 8 (tetapi dengan beberapa batasan dan peringatan), sementara Java 11 sudah mendekati. Menggunakan Kotlin, pemrograman pada Android jauh lebih mudah, jumlah baris teks berkurang .
Orang hanya bisa berharap bahwa pengembang akan melengkapi bahasa yang sangat berguna ini dengan fitur-fitur yang tidak tersedia saat ini karena alasan yang jelas. Mungkin di versi mendatang akan ada alat baru untuk menganalisis pengecualian di IDE, serta kategori privasi baru. Tapi, ternyata, inilah kasus terbaik di masa depan yang jauh, karena pengembang bahasa bahkan belum menyuarakan janji.