Berita dari antara yang tak terduga menyenangkan membangkitkan segala macam kenangan, manis dan tidak begitu. Saya juga mendapatkan artikel ini darinya, dan segera muak dengan nostalgia, dan saya ingin memainkan elipsis yang begitu berat darinya selama tujuh tahun terakhir.
Dephi adalah solusi yang benar-benar brilian. Yah, Anda tahu, seperti The Beatles, sebagai antarmuka komputer grafis dengan kontrol mouse, sebagai mesin pembakaran internal. Solusi cerdik yang telah datang ke dalam kehidupan kita begitu luas sehingga Anda bahkan tidak bisa percaya bahwa itu pernah tidak ada, dan menggambar jendela, kotak centang, dan tombol di Windows bisa sangat menyebalkan.
Bagian dari Delphi yang cerdik adalah VCL - set kotak centang dan tombol yang sama untuk Windows, yang tiba-tiba menjadi sangat mudah dan sederhana untuk saling seret dan jatuh, dan membuat aplikasi Windows yang indah dan tidak biasa.
Dan seperti halnya UI yang layak, ini bekerja, tentu saja, sesuai dengan model acara. OnClick di objek tombol menjelaskan semua yang dilakukan tombol, OnChange saat masuk ke bidang teks, semuanya sama seperti pada orang dewasa. Tapi akhirat - lebih lanjut, sayangnya, belum ada apa-apa.
Tidak ada yang kita tahu sekarang, maksudku. MVC, misalnya - Delphi, menganggapnya terdiri dari satu V, maka semuanya tetap berada di tangan pengembang. Langsung dari OnClick untuk menarik permintaan ke database? Ya silakan Di OnChange, buka file dan coba tuliskan padanya, dan jika file yang ada tidak berubah secara diam-diam dengan sesuatu seperti Pelanggaran Akses Memori - di setiap langkah (namun, itu tidak ada hubungannya dengan Delphi sebagai platform).
Dan saya harus mengatakan bahwa selama bertahun-tahun itu benar-benar bahagia untuk semua orang, dan beberapa masih cukup senang dengannya. Manfaat perpustakaan yang ramping dan indah dari komponen UI segera terlihat, manfaat dari setiap pengontrol dan model menjadi jelas bukan pada tahun pertama pengembangan, atau pada seratus kilobyte pertama dari kode sumber.
Dan bahkan jika sudah menjadi - mudah untuk melupakannya, ada jebakan pikiran di sini, seperti ilusi optik dan suara yang sangat diperdebatkan di Internet. Jadi izinkan saya mencoba untuk melemparkan jembatan kecil dari Delphi ke pemahaman modern tentang UI dan kita bisa mencari tahu apa yang terjadi.
Jadi, ide kuncinya: kami memisahkan presentasi dari data, widget secara terpisah, semua pekerjaan dengan informasi di dalamnya terpisah. Bagaimana terpisah? Katakanlah, tombol masih memiliki tulisan, dan kadang-kadang ikon. Pengguna sendiri dapat mengarahkan prasasti ini ke dalam bidang teks, dan kadang-kadang bidang teks memiliki prasasti lain yang menjelaskan kepada pengguna apa sebenarnya yang ia kendarai. Aturan umum: widget terlibat dalam menampilkan, setidaknya (SIC!) Logika, yang mungkin ada di dalamnya hanya boleh dikaitkan dengan tampilan dan tidak ada yang lain. Katakanlah, jika tombol tidak siap untuk direntangkan bersama dengan prasasti di atasnya - prasasti tersebut harus dipotong entah bagaimana (misalnya, tunjukkan elipsis dan versi lengkap di ToolTip), atau berikan kesalahan ketika mencoba untuk menetapkan nilai lebih dari yang pas (meskipun ini idenya begitu-begitu, kesalahan seperti itu kemungkinan besar akan sudah keluar selama pelaksanaan program, pada saat yang paling tidak tepat).
Bidang input teks dapat menghapus terjemahan carriage dari teks jika itu adalah baris tunggal, tetapi tidak perlu meminta, misalnya, untuk memasukkan hanya angka di dalamnya - ini bukan pekerjaannya. Sama seperti pada penangan klik tombol tidak diperlukan pemeriksaan, tidak ada panggilan ulang, penangan tombol harus menarik kode eksternal, yang sudah bertanggung jawab atas logika UI dan seluruh aplikasi.
Dan jika Anda tinggal di dunia jet baru yang indah, melihat ke bawah pada semua keributan acara OOP ini, maka prinsipnya tetap sama: menekan tombol mengubah kondisinya dengan menambahkan Action yang sesuai, dan kemudian beberapa kode, kode tersebut tidak terkait dengan elemen-elemen UI, lihat Tindakan ini, dan buat kesimpulan yang sesuai, dan ubah status sehingga ada sesuatu untuk ditampilkan di UI kembali.
Yaitu, terlepas dari lingkungan, platform, dan paradigma, elemen-elemen visual itu sendiri membawa fungsionalitas minimum dan logika nol. Mereka menerima informasi dalam bentuk paling umum, jadi jika Anda memiliki TextBox, itu juga Input, itu juga bidang untuk memasukkan teks, dibutuhkan string dan memberikan string. Dan tugas mengubah garis menjadi angka, nama seseorang atau sesuatu yang lebih licik tidak lagi untuk widget.
Nah, kemudian Controller, atau Presenter, memproses hasilnya dan menghasilkan hasilnya. Panggillah dia seperti yang biasa Anda lakukan, hanya saja jangan ada elemen visual apa pun padanya.
Apa untungnya? Saya mendaftar secara berurutan dari yang paling jelas sampai yang paling, menurut saya, yang esensial.
Pertama, usabilitas ulang. Cukup banyak waktu dapat dihabiskan untuk memahami bahwa bidang untuk memasukkan alamat surat, untuk memasukkan nama keluarga, dan untuk memasukkan jumlah, pada kenyataannya, bidang yang sama. Satu dan widget yang sama, dengan serangkaian fitur yang sama yang turun untuk menarik peristiwa input teks atau memperbarui keadaan. Dan hanya logika bekerja dengan teks di dalamnya yang mungkin berbeda. Contoh "bagaimana tidak" dari kehidupan: buat bidang untuk memasukkan sejumlah uang (hingga dua tempat desimal), lalu main-main untuk waktu yang lama, ulangi sehingga kadang-kadang Anda dapat memasukkan jumlah dalam bidang yang sama (hingga 4 tempat desimal) . Istirahatkan dalam proses semua tempat di mana jumlahnya dimasukkan dalam aplikasi, dan perbaiki secara darurat di tengah malam. Ini terlepas dari kenyataan bahwa, menurut logika pekerjaan mereka, mereka memiliki perbedaan di tempat desimal ketiga. Anda dapat menulis puisi tentang bagaimana bidang untuk memasukkan alamat email berubah menjadi bidang untuk memasukkan alamat geografis menggunakan pewarisan dan kata-kata Tuhan.
Kedua: testabilitas. Anda juga dapat menguji UI. Hampir semua UI. Tapi itu akan mahal, dalam hal waktu dan sumber daya yang dihabiskan untuk mengembangkan tes, dan menjalankan tes, dan mereka tidak mungkin diluncurkan di setiap pembangunan kembali, tetapi ketika tes jatuh pada rilis, ini akan menjadi force majeure. Tetapi komponen-komponen UI adalah yang paling berisiko dalam hal kerusakan, mereka pecah, sebagai aturan, paling sering, paling jelas, dan paling menyakitkan. Tetapi kode, yang diambil dari widget itu sendiri, benar-benar dicakup oleh unit test. Dan tes unit jauh lebih murah - lebih mudah untuk menulis, dan Anda dapat menjalankannya secara harfiah setelah perubahan apa pun, dan selalu memastikan bahwa tidak ada yang rusak.
Dan ketiga, yang paling penting, menurut saya. Menggambar sepotong UI bersama dengan logika sebagai satu potong sangat sulit untuk mengalahkan kemalasan dan berpikir lebih dalam tentang cara kerjanya. Untuk menyelesaikan skenario kecuali idealnya positif, ketika pengguna memasukkan persis apa yang diharapkan darinya, melakukan persis apa yang diminta, dan menerima persis apa yang diinginkannya. Pemrogram suci yang sama itu “semuanya bekerja untuk saya”.
Pemisahan bagian visual dan bagian logis membuat Anda berpikir, pertama, bagaimana bagian visual bekerja: apa yang masuk ke dalamnya, apa yang keluar, apa yang terjadi jika sesuatu yang tidak diharapkan masuk atau keluar tidak berhasil. Dan menulis logika secara terpisah dari kontrol memaksa Anda untuk menulisnya dalam beberapa kasus, yaitu, sesuai dengan skenario yang memungkinkan untuk menggunakan aplikasi tertentu di tempat tertentu, termasuk memproses kesalahan yang muncul di sini, dan membantu pengguna dalam kesulitan yang ia alami di sini. Ya, tidak selalu, atau lebih tepatnya tidak dalam segala hal, solusi secara umum lebih baik daripada solusi yang dirancang untuk kasus tertentu.
Untuk meringkas. Anda dapat menulis dalam Delph, atau aplikasi untuk iOS, menyiksa web yang sudah lama menderita karena semacam-ada-0, atau memukau beberapa permainan mikrokontroler dengan Python, jika kode Anda telah melampaui rumus "satu cetakan, satu permintaan, satu hasil" - Saya akan memberitahu Anda Saya sangat merekomendasikan memisahkan widget dari logika pekerjaan mereka, dan kemudian ada kemungkinan ada lebih sedikit lalat di cutlets Anda. Dan terlepas dari kesempurnaan awal yang jelas dari keunggulan solusi semacam itu, semakin Anda bekerja dengannya, semakin banyak keunggulan ini akan muncul untuk Anda.