Membedakan Delegasi dan Peristiwa
Pengembang yang baru menggunakan platform .NET Core sering kesulitan saat memutuskan antara desain berdasarkan delegates dan desain berdasarkan events. Pilihan delegasi atau peristiwa sering kali sulit, karena dua fitur bahasa tersebut serupa. Peristiwa bahkan dibangun menggunakan dukungan bahasa untuk delegasi.
Keduanya menawarkan skenario pengikatan terlambat: mereka mengaktifkan skenario di mana komponen berkomunikasi dengan memanggil metode yang hanya diketahui pada waktu proses. Keduanya mendukung metode pelanggan tunggal dan beberapa. Anda mungkin menemukan ini disebut sebagai dukungan singlecast dan multicast. Keduanya mendukung sintaks serupa untuk menambahkan dan menghapus handler. Terakhir, menaikkan peristiwa dan memanggil delegasi menggunakan sintaks panggilan metode yang sama persis. Keduanya bahkan mendukung sintaks metode Invoke() yang sama untuk digunakan dengan operator ?..
Dengan semua kesamaan tersebut, mudah untuk mengalami kesulitan menentukan kapan harus menggunakan yang mana.
Mendengarkan Peristiwa bersifat Opsional
Pertimbangan terpenting dalam menentukan fitur bahasa mana yang akan digunakan adalah apakah harus ada pelanggan yang terlampir atau tidak. Jika kode Anda harus memanggil kode yang disediakan oleh pelanggan, Anda harus menggunakan desain berdasarkan delegasi saat Anda perlu menerapkan panggilan balik. Jika kode Anda dapat menyelesaikan semua pekerjaannya tanpa memanggil pelanggan apa pun, Anda harus menggunakan desain berdasarkan peristiwa.
Pertimbangkan contoh yang dibuat selama bagian ini. Kode yang Anda buat menggunakan List.Sort() harus diberi fungsi pembanding untuk mengurutkan elemen dengan benar. Kueri LINQ harus disediakan dengan delegasi untuk menentukan elemen apa yang akan dikembalikan. Keduanya menggunakan desain yang dibangun dengan delegasi.
Pertimbangkan peristiwa Progress. Ini melaporkan kemajuan pada tugas.
Tugas terus dilanjutkan apakah ada listener atau tidak.
FileSearcher adalah contoh lain. Ini masih akan mencari dan menemukan semua file yang dicari, bahkan tanpa pelanggan peristiwa yang terlampir.
Kontrol UX masih berfungsi dengan benar, bahkan saat tidak ada pelanggan yang mendengarkan peristiwa. Keduanya menggunakan desain berdasarkan peristiwa.
Nilai Pengembalian Memerlukan Delegasi
Pertimbangan lain adalah prototipe metode yang Anda inginkan untuk metode delegasi Anda. Seperti yang telah Anda lihat, delegasi yang digunakan untuk peristiwa semuanya memiliki jenis pengembalian yang batal. Anda juga telah melihat bahwa ada idiom untuk membuat penanganan aktivitas yang meneruskan informasi kembali ke sumber peristiwa melalui memodifikasi properti objek argumen peristiwa. Meskipun idiom ini berfungsi, idiom ini tidak alami seperti mengembalikan nilai dari metode.
Perhatikan bahwa kedua heuristik ini mungkin sering ada: Jika metode delegasi Anda mengembalikan nilai, kemungkinan akan berdampak pada algoritma dalam beberapa cara.
Peristiwa Memiliki Pemanggilan Privat
Kelas selain yang berisi peristiwa hanya dapat menambahkan dan menghapus listener peristiwa; hanya kelas yang berisi peristiwa yang dapat memanggil peristiwa. Acara biasanya anggota kelas publik. Sebagai perbandingan, delegasi sering diteruskan sebagai parameter dan disimpan sebagai anggota kelas privat, jika mereka disimpan sama sekali.
Listener Peristiwa Sering Memiliki Masa Pakai yang Lebih Lama
Pendengar peristiwa memiliki masa pakai yang lebih lama adalah pembenaran yang sedikit lebih lemah. Namun, Anda mungkin menemukan bahwa desain berbasis peristiwa lebih alami saat sumber peristiwa akan meningkatkan peristiwa dalam jangka waktu yang lama. Anda dapat melihat contoh desain berbasis peristiwa untuk kontrol UX pada banyak sistem. Setelah Anda berlangganan acara, sumber peristiwa dapat memunculkan peristiwa sepanjang masa pakai program. (Anda dapat berhenti berlangganan dari peristiwa saat Anda tidak lagi membutuhkannya.)
Berbeda dengan banyak desain berbasis delegasi, di mana delegasi digunakan sebagai argumen untuk metode, dan delegasi tidak digunakan setelah metode tersebut kembali.
Evaluasi Dengan Hati-hati
Pertimbangan di atas bukanlah aturan yang sulit dan cepat. Sebaliknya, mereka mewakili panduan yang dapat membantu Anda memutuskan pilihan mana yang terbaik untuk penggunaan khusus Anda. Karena mirip, Anda bahkan dapat membuat prototipe keduanya, dan mempertimbangkan mana yang lebih alami untuk dikerjakan. Keduanya menangani skenario pengikatan terlambat dengan baik. Gunakan salah satu yang mengkomunikasikan desain Anda dengan terbaik.
