Apa yang harus digunakan plugin: kait, acara, atau yang lainnya?

Pertimbangkan aplikasi yang memungkinkan plugin bereaksi terhadap aliran programnya.

Saya tahu 2 cara untuk mencapai ini: kait dan acara

1. Kait

Gunakan panggilan untuk mengosongkan fungsi di dalam aliran program utama. Fungsi-fungsi ini dapat ditimpa oleh plugin.

Sebagai contoh, CMS Drupal mengimplementasikan kait yang tersedia untuk modul dan tema. Berikut adalah contoh bagaimana hook diimplementasikan dalam fungsi file_copy .

function file_copy(stdClass $source, $destination = NULL, $replace = FILE_EXISTS_RENAME) {
    // ... [File copying routine]

    // Inform modules that the file has been copied.
    module_invoke_all('file_copy', $file, $source);

    return $file;
    // ...
}

Modul dapat mengimplementasikan modulename_file_copy($file, $source)fungsi yang akan dipanggil oleh module_invoke_allin file_copy. Setelah fungsi ini selesai, file_copyakan melanjutkan eksekusi.

2. Acara

Miliki acara pengiriman aplikasi, yang dapat didengarkan oleh plugin. Setelah menerima acara yang telah dilanggani, sebuah plugin akan mencegat aliran program dan melakukan operasi yang diperlukan.

Misalnya, plugin galeri jQuery Fotorama mengimplementasikan beberapa acara . Sebagai contoh, inilah bagian dari showmetodenya yang memecat fotorama:showacara tersebut.

  that.show = function (options) {
    // ... [show the new frame]

    // [fire the event]
    options.reset || triggerEvent('show', {
      user: options.user,
      time: time
    });

    // ... [do lots of other stuff with navigation bars, etc.]
  };

Sebuah skrip dapat mendengarkan acara ini dan melakukan sesuatu ketika terjadi:

$('.fotorama').on(
  'fotorama:show',
  function (e, fotorama, extra) {
    console.log(e.type + (extra.user ? ' after user’s touch' : ''));
    console.log('transition duration: ' + extra.time);
  }
);

PERTANYAAN

1. Apakah ada cara utama lain untuk menerapkan perilaku plugin semacam itu?

2. Jika tidak, kapan harus menggunakan kait, dan kapan harus menggunakan acara? Mempertimbangkan tujuan akhir adalah membuat kode lebih mudah dikelola dan dibaca, baik dari perspektif aplikasi maupun pengembang plugin?

Perbedaan utama antara kail dan acara adalah kopling longgar versus kopling ketat.

Sebuah kait adalah cara umum untuk menyiarkan bahwa sesuatu telah terjadi. Anda dapat menambahkan kait baru tanpa harus mengkompilasi ulang plugin, dan semua kait mengikuti pola desain umum. Setelah API kait ditetapkan, API tidak berubah sehingga sambungan antara aplikasi dan plugin tidak akan putus.

Acara lebih erat dengan aplikasi. Acara dapat menentukan parameter yang dilampirkan ke acara tersebut, dan jika Anda mengubah parameter tersebut, Anda merusak API dengan plugin yang ada.

Mereka berdua mencapai hasil yang sama. Itu hanya tergantung pada bagaimana Anda ingin memasangkan plugin ke aplikasi.

Hooks dapat menawarkan Anda kopling yang lebih dinamis yang tidak mungkin rusak karena versi baru aplikasi Anda dirilis, tetapi kerugiannya adalah Anda tidak mendapatkan peringatan waktu kompilasi bahwa plugin tidak lagi kompatibel.

Acara menawarkan Anda kemampuan untuk mendapatkan kesalahan waktu kompilasi yang perlu diubah oleh plugin, karena beberapa tanda tangan acara telah berubah.

Anda meminta pendekatan alternatif.

Perintah:

Alih-alih plugin merespons peristiwa yang dipicu. Plugin mendorong objek perintah ke aplikasi. Setiap objek perintah mengimplementasikan antarmuka yang digunakan oleh perintah. Ketika aplikasi perlu menjalankan fitur, ia menjalankan semua perintah untuk fitur itu. Ini sangat mirip acara, kecuali bahwa itu diimplementasikan sebagai objek, bukan fungsi callback.

Makro:

Alih-alih plugin merespons ketika sesuatu terjadi. Plugin secara proaktif menyebabkan sesuatu terjadi. Makro adalah bahasa tingkat tinggi kecil yang berjalan di atas aplikasi dan mengatakan apa yang harus dilakukan.

State Change Listeners:

Peristiwa dipicu oleh aplikasi dengan pemikiran sebelumnya oleh pengembang. Pengembang harus secara sadar menulis kode yang menerbitkan acara tersebut. Sebaliknya, pendekatan alternatif adalah membuat objek secara otomatis disiarkan ketika keadaan internal mereka telah berubah. Entah perubahan properti atau indikator lainnya. Plugin kemudian dapat mendengarkan perubahan keadaan spesifik ini dan bereaksi sesuai itu. Keuntungan dari pendekatan ini adalah bahwa programmer tidak harus ingat untuk menyiarkan acara. Misalnya, mungkin ada objek Dokumen dan pemrogram menetapkan bendera untuk menandai bahwa dokumen tersebut perlu disimpan. Perubahan status ini disiarkan ke plugin mendengarkan, dan mungkin ada plugin yang mengubah judul dokumen untuk menyertakan tanda bintang.

Peristiwa yang pasti, memungkinkan abstraksi yang diperlukan sudah pada tingkat arsitektur.

Jangan berharap bahwa siapa pun yang menulis plugin benar-benar melakukannya seperti yang didokumentasikan atau dengan cara apa pun yang benar. Saya telah memelihara API yang terdokumentasi dengan baik dengan jutaan pengguna dan saya dapat memberi tahu Anda dari pengalaman yang sangat menyakitkan bahwa pada dasarnya tidak ada yang pernah membaca dokumentasi dan hampir tidak ada yang menggunakan API dengan benar.

Ambil contoh berikut dengan pengait: Anda memiliki sistem tempat 20 pengaya berjalan. Salah satu plugin memanggil file_copymetode dengan cara didokumentasikan dan mengharapkan hasil seperti yang didokumentasikan. Tetapi beberapa plugin lain telah mengaitkan fungsi itu dan oleh karena itu salah satu masalah berikut menyebabkan kerusakan atau kegagalan fungsi:

• Fungsi kait hanya macet. Semua plugin lain kacau sekarang, karena mereka tidak bisa lagi file_copy atau fungsinya berbeda dari yang diharapkan.
• Input benar berdasarkan pada dokumentasi, tetapi plugin lain tidak mengharapkannya dan memberikan hasil yang aneh atau macet.
• Panggilan berjalan dengan baik, tetapi hasilnya tidak lagi sesuai dengan dokumentasi sehingga plugin gagal atau macet.

Jika Anda melakukan hal yang sama seperti di atas dengan acara dengan masalah yang sama di dalam plugin itu terjadi hal berikut:

• Fungsi acara plugin X mogok, tetapi semua yang lain berfungsi dengan baik. Tetapi karena plugin tersebut tidak terkait, Anda cukup menonaktifkan plugin yang mogok sementara yang lain terus berfungsi dengan baik.
• Input aneh dapat ditangani dengan benar oleh fungsi Anda dan Anda dapat memeriksa dengan benar semua hal yang mungkin untuk setiap plugin secara terpisah. Pengembang plugin sekarang memiliki cara yang stabil dan dapat diandalkan untuk benar-benar menguji plugin-nya, yang memungkinkan dia untuk memastikan bahwa jika berfungsi untuknya itu akan bekerja untuk semua orang. Jika satu plugin memberikan input yang salah, itu dapat diisolasi ke satu plugin itu.
• Sama-sama hasilnya dapat diperiksa dan didefinisikan dengan benar dalam semua keadaan, sehingga pengembang plugin memiliki jawaban yang stabil dan dapat diandalkan dari fungsi yang dapat dia uji.

Warisan dapat menjadi pilihan.

Selain kait, warisan tidak memerlukan definisi metode tambahan, dan tidak ada kehilangan kinerja untuk memanggil metode kosong jika tidak ada yang terhubung.

Selain acara, pewarisan juga tidak perlu kode tambahan untuk permohonan acara.

Namun, pewarisan bekerja paling baik jika hanya ada satu plugin yang memodifikasi satu jenis perilaku. Jika Anda membutuhkan banyak plugin, yang kedua harus berasal dari yang lain dll, yang tidak sesuai.

Peristiwa pasti. Ini memungkinkan arsitektur Anda menjadi lebih luas.

Bayangkan apa yang akan terjadi jika Anda harus meletakkan plugin Anda ke mesin yang terpisah misalnya. Menggunakan acara - Anda hanya perlu memodifikasi sedikit kedamaian kode untuk membuat acara Anda berbasis jaringan.