Acara Laravel 5 - Apakah ini mediator atau pengamat?

Saya sedang mendiskusikan sistem acara Laravel dengan pengembang lain hari ini. Dia menyebutkan bahwa pengirim acara Laravel menggunakan pola pengamat.

Saya selalu berpikir itu menerapkan pola mediator karena objek Anda selalu mendengarkan/menembakkan peristiwa melalui objek operator peristiwa, tetapi dokumen mengatakan itu adalah pengamat.

Event::listen('event.name', function ($foo, $bar) {
    //
});

Event::fire("event.name", []);

Bukankah ini pola mediator?


php design-patterns laravel-5 observers mediator
person Moon    schedule 15.02.2016    source sumber

Jawaban (1)


arrow_upward
2
arrow_downward

Saya tidak tahu pasti tentang apa yang sebenarnya dilakukan Laravel dan sebenarnya jika dokumen mengatakan bahwa itu dibangun berdasarkan pola pengamat, saya akan mempercayainya.

Namun pertanyaan Anda adalah tentang seperti apa kodenya dan dari pengalaman saya, saya dapat dengan mudah mengenali pengamat di sini dengan analogi:

  • dengarkan akan serupa dengan berlangganan/lampirkan Pengamat
  • api akan serupa dengan pemberitahuan/pembaruan Pengamat

Bagi saya mediator akan terlihat aneh karena meskipun tujuannya adalah untuk memfasilitasi komunikasi antara beberapa objek, saya tidak melihatnya sebagai cara yang baik untuk mendistribusikan notifikasi. Saya pasti akan bertaruh pada pengamat karena alasan itu.

person floppy12    schedule 15.02.2016
comment
@ floopy12 Tapi tidakkah Anda mendapatkan contoh suatu objek dan kemudian mendengarkannya jika itu adalah pengamat? Dalam hal ini, Anda mendengarkan kelas Event, bukan objek yang Anda minati. Mendengar/menembak tidak berarti ia adalah pengamat. Mediator juga dapat mendengarkan/menembak. - person Moon; 16.02.2016
comment
@Moon Menurut pendapat saya, satu-satunya hal yang penting adalah Anda mendengarkan sesuatu yang lain meskipun itu bukan objek, itu berarti Anda tertarik. Pola Pengamat (atau apa pun) tidak termasuk dalam bahasa atau paradigma apa pun , itu adalah ide konseptual untuk mengungkapkan masalah dan solusi. Penerapannya harus disesuaikan dengan kebutuhan spesifik Anda. Di sini tampaknya lebih merupakan pendekatan fungsional di mana Anda mendengarkan suatu peristiwa dan mengaitkan panggilan balik ke sana daripada implementasi OOP klasik - person floppy12; 16.02.2016
comment
@ floopy12 // Yang saya pahami sepenuhnya. Masalahnya adalah implantasi ini juga menyiratkan kompilasi yang agak longgar karena nama acara bisa apa saja dan Acara bertindak sebagai mediator apakah saya mendengarkan acara tertentu atau tidak. Saya pikir inilah sebabnya beberapa kerangka PHP menyebutnya sebagai mediator, namun Laravel tidak. - person Moon; 16.02.2016
comment
@Moon: Mengenai hal kopling longgar, baik di Mediator dan Observer, objA dan objB tidak berkomunikasi secara langsung (masing-masing melalui Mediator atau suatu peristiwa meskipun dipecat dari objek yang dapat diamati). Kode yang diberikan tidak cukup untuk mengetahui apa yang sebenarnya dilakukan Laravel. Namun, mengingat Mediator memfasilitasi komunikasi antara dua objek lain (atau lebih), di manakah kedua subjek di sini jika Peristiwa mewakili mediator? Selain itu, apakah Event akan menjadi nama yang tepat untuk Mediator? (Mengingat itu adalah nama yang dapat diterima untuk Observable) - person floppy12; 16.02.2016
comment
@ floopy12 // Bukan tidak setuju, tapi juga tidak setuju. Sejauh yang saya pahami dalam buku GOF, para pengamat memang bergantung satu sama lain. Anda memerlukan contoh subjek untuk didengarkan. Saya memahami bahwa implantasinya berubah, tetapi menurut saya niat tidak harus berubah. Dalam kasus khusus ini, tidak ada seorang pun yang benar-benar bergantung satu sama lain. Itu hanya ada di kepala seorang programmer. Saya kira saya menanyakan pertanyaan yang salah di sini karena tidak akan ada jawaban konkrit, tapi opini yang bagus. Saya menghargai pemikiran Anda. - person Moon; 16.02.2016
comment
@Moon : Saya memahami kebingungan Anda dan akan sulit bagi saya untuk menjelaskan situasinya. IMHO, saya melihat di sini Observable (Pemegang Acara atau Acara) dan Pengamat (pemegang fungsi atau fungsi). Kedua entitas dihubungkan oleh string event.name alih-alih berkomunikasi secara eksplisit (fungsi pemanggilan pemegang acara dengan args foo dan bar). Saya pikir niat Pengamat dihormati sepenuhnya. Sebaliknya, Mediator adalah objek ketiga yang menerima Peristiwa di satu sisi dan memanggil fungsi di sisi lain. - person floppy12; 16.02.2016
comment
@Moon : Yang pasti membingungkan Anda adalah bahwa hubungan antara acara dan panggilan balik dilakukan oleh string, bukan objek konkret. Namun ini hanyalah cara untuk mencapai desain yang digabungkan secara lebih longgar dengan menggunakan argumen umum daripada mengandalkan objek. Informasi lebih lanjut tentang en.wikipedia.org/wiki/Loose_coupling - Bagian Metode untuk mengurangi kopling - person floppy12; 16.02.2016