घटनाओं की सदस्यता के लिए एक वैकल्पिक दृष्टिकोण, या EventObject वास्तव में आवश्यक है?

सारांश

इस लेख का उद्देश्य घटना वितरण प्रणाली के विवरण पर एक अलग दृष्टिकोण से देखने का प्रयास है।

इस लेखन के समय, अधिकांश प्रमुख php चौखटे एक EventObject के विवरण के आधार पर एक घटना प्रणाली को लागू करते हैं ।

यह php में मानक बन गया है, जिसकी पुष्टि हाल ही में psr / event-dispatcher मानक को अपनाने से हुई है।

लेकिन यह पता चला है कि घटना वस्तु का वर्णन श्रोता को विकसित करने में बहुत कम मदद करता है। बिल्ली के नीचे विवरण के लिए।

क्या समस्या है

आइए उन लोगों की भूमिकाओं और लक्ष्यों को देखें जो विकास में EventObject का उपयोग करते हैं।

1. एक डेवलपर (ए) जो एक घटना उत्पन्न करके अपनी प्रक्रिया में तीसरे पक्ष के निर्देशों को इंजेक्ट करने की क्षमता देता है।

   
   

   डेवलपर एक इंटरफेस के माध्यम से EventObject या उसके हस्ताक्षर का वर्णन करता है।

   
   

   EventObject का वर्णन करते समय, डेवलपर का लक्ष्य अन्य डेवलपर्स को डेटा ऑब्जेक्ट का विवरण देना है, और कुछ उपयोग के मामलों में, इस ऑब्जेक्ट के माध्यम से मुख्य थ्रेड के साथ बातचीत के तंत्र का वर्णन करना है।

   
   

2. डेवलपर (बी) जो "श्रोता" का वर्णन करता है।

   
   

   डेवलपर निर्दिष्ट घटना के लिए सदस्यता लेता है। ज्यादातर मामलों में, श्रोता विवरण को कॉल करने योग्य प्रकार को संतुष्ट करना चाहिए।

   
   

   उसी समय, डेवलपर श्रोता के वर्गों या तरीकों के नामकरण में शर्मीली नहीं है। लेकिन कन्वेंशन द्वारा अधिक प्रतिबंध है कि हैंडलर को एक तर्क के रूप में एक EventObject प्राप्त होता है।

   
   

जब psr / event-dispatcher को वर्किंग ग्रुप द्वारा अपनाया गया था , तो इवेंट डिस्ट्रीब्यूशन सिस्टम का उपयोग करने के कई विकल्पों का विश्लेषण किया गया था।

Psr मानक में निम्नलिखित उपयोग के मामलों का उल्लेख है:

1. एक तरफ़ा सूचना - "अगर आपने रुचि ली तो मैंने कुछ किया"
2. वस्तु सुधार - "यहाँ एक बात है, कृपया इसे बदलने से पहले मैं इसके साथ कुछ करूँ"
3. संग्रह - "मुझे अपनी सभी चीजें दें ताकि मैं इस सूची के साथ कुछ कर सकूं"
4. वैकल्पिक श्रृंखला - "यहाँ बात है, आप में से सबसे पहले इसके साथ सामना करने के लिए, इसे करें, फिर रुकें"

उसी समय, कार्य समूह ने इवेंट डिस्ट्रीब्यूशन सिस्टम के समान उपयोग के लिए कई प्रश्न उठाए, इस तथ्य से संबंधित है कि उपयोग के प्रत्येक मामलों में "अनिश्चितता" है जो डिस्पैचर ऑब्जेक्ट के कार्यान्वयन पर निर्भर करता है।

डेवलपर (बी) के लिए ऊपर वर्णित भूमिकाओं में, यह समझने का कोई सुविधाजनक और पठनीय तरीका नहीं है कि डेवलपर सिस्टम (ए) द्वारा ईवेंट सिस्टम का उपयोग करने के लिए कौन से विकल्प चुने गए थे। डेवलपर को हमेशा EventObject के न केवल विवरण कोड में देखना होगा , बल्कि उस कोड में भी जहां यह घटना उत्पन्न होती है।

नतीजतन, हस्ताक्षर ईवेंट ऑब्जेक्ट का विवरण है, जो डेवलपर (बी) के काम को सुविधाजनक बनाने के लिए डिज़ाइन किया गया है। यह काम अच्छा नहीं करता है।

एक अन्य समस्या हमेशा एक अलग वस्तु की उचित उपस्थिति नहीं है, जो अतिरिक्त रूप से सिस्टम में पहले से वर्णित संस्थाओं का वर्णन करती है।

namespace MyApp\Customer\Events; use MyApp\Customer\CustomerNameInterface; use MyFramevork\Event\SomeEventInterface; class CustomerNameChangedEvent implements SomeEventInterface { /** *     * @return int */ public function getCustomerId(): int; /** *    */ public function getCustomerName(): CustomerNameInterface; } 

उपरोक्त उदाहरण में, System में पहले से ही CustomerNameInterface ऑब्जेक्ट का वर्णन किया गया है।

यह नई अवधारणाओं की अत्यधिक शुरूआत की याद दिलाता है। आखिरकार, जब हमें किसी विधि को लागू करने की आवश्यकता होती है, उदाहरण के लिए, क्लाइंट के नाम परिवर्तन लॉग में लिखना हम विधि तर्कों को एक अलग इकाई में संयोजित नहीं करते हैं, हम फॉर्म की एक विधि के मानक विवरण का उपयोग करते हैं:

  function writeToLogCustomerNameChange( int $customerId, CustomerNameInterface $customerName ) { // ... } 

परिणामस्वरूप, हम निम्नलिखित समस्याएं देखते हैं:

1. बुरा श्रोता कोड हस्ताक्षर
2. डिस्पैचर अनिश्चितता
3. वापसी प्रकार अनिश्चितता
4. कुछ अतिरिक्त संस्थाओं का परिचय जैसे कि SomeEventObject

आइए इसे अलग नजरिए से देखें

यदि समस्याओं में से एक श्रोता का खराब विवरण है, तो आइए घटना वितरण प्रणाली को घटना वस्तु के विवरण से नहीं, बल्कि श्रोता के वर्णन से देखें।

डेवलपर (ए) वर्णन करता है कि श्रोता का वर्णन कैसे किया जाना चाहिए।

  namespace MyApp\Customer\Events; interface CustomerNameChangedListener { public function onCustomerNameChange( int $customerId, CustomerNameInterface $customerName ); } 

उत्कृष्ट डेवलपर (ए) तीसरे पक्ष के डेवलपर्स के लिए श्रोता और प्रेषित डेटा का विवरण देने में सक्षम था।

एक श्रोता को लिखते समय, डेवलपर (बी) के ग्राहक पर्यावरण के प्रकारों को लागू वातावरण में टाइप करते हैं और IDE अपनी कक्षा में श्रोता विधि का विवरण जोड़ सकते हैं। कोड पूरा होना शानदार है।

आइए नए श्रोता विधि हस्ताक्षर पर एक नज़र डालें। यहां तक ​​कि एक त्वरित नज़र यह समझने के लिए पर्याप्त है कि उपयोग की जाने वाली घटना वितरण प्रणाली का संस्करण है: "एक तरफ़ा अधिसूचना।"

इनपुट डेटा को संदर्भ द्वारा प्रेषित नहीं किया जाता है, जिसका अर्थ है कि उन्हें किसी भी तरह से संशोधित करने का कोई तरीका नहीं है ताकि परिवर्तन मुख्य धारा में आए। अनुपलब्ध रिटर्न मान; मुख्य सूत्र से कोई प्रतिक्रिया नहीं।

अन्य उपयोग मामलों के बारे में क्या? आइए घटना श्रोता इंटरफेस के विवरण के साथ खेलते हैं।

  namespace MyApp\Customer\Events; interface CustomerNameChangedListener { public function onCustomerNameChange( int $customerId, CustomerNameInterface $customerName ): CustomerNameInterface; } 

रिटर्न वैल्यू के लिए एक आवश्यकता थी, जिसका अर्थ है कि श्रोता एक अलग मान लौटा सकता है (यदि इसकी आवश्यकता नहीं है) यदि यह निर्दिष्ट इंटरफ़ेस से मेल खाता है मामले का उपयोग करें: "वस्तु सुधार"।

  namespace MyApp\Customer\Events; interface CustomerNameChangedListener { /** * @return ItemInterface[] */ public function onCustomerNameChange( int $customerId, CustomerNameInterface $customerName ): array; } 

एक निश्चित प्रकार के वापसी मूल्य के लिए एक आवश्यकता थी जिसके द्वारा यह समझा जा सकता है कि यह संग्रह का एक तत्व है। मामले का उपयोग करें: "संग्रह"।

  namespace MyApp\Customer\Events; interface CustomerNameChangedListener { public function onCustomerNameChange( int $customerId, CustomerNameInterface $customerName ): VoteInterface; } 

मामले का उपयोग करें: "वैकल्पिक श्रृंखला, मतदान।"

  namespace MyFramework\Events; interface EventControllInterface { public function stopPropagation(); } 

  namespace MyApp\Customer\Events; interface CustomerNameChangedListener { public function onCustomerNameChange( int $customerId, CustomerNameInterface $customerName, EventControllInterface &$eventControll ); } 

चर्चा के बिना, घटनाओं के प्रचार को रोकना अच्छा या बुरा है।

यह विकल्प स्पष्ट रूप से पढ़ा जाता है, मुख्य सूत्र श्रोता को घटना को रोकने का अवसर प्रदान करता है।

इसलिए, यदि हम श्रोता के विवरण के लिए आगे बढ़ते हैं, तो हम उन्हें विकसित करते समय श्रोता विधियों के बेहतर पठनीय हस्ताक्षर प्राप्त करते हैं।

इसके अतिरिक्त, हमारे पास मुख्य सूत्र को स्पष्ट रूप से इंगित करने का अवसर है:

1. आने वाले डेटा में परिवर्तन की स्वीकार्यता
2. आने वाले प्रकारों के अलावा अन्य प्रकार
3. किसी वस्तु का स्पष्ट हस्तांतरण जिसके साथ किसी घटना के प्रसार को रोकना है

इवेंट सब्सक्रिप्शन कैसे लागू करें

विकल्प अलग हो सकते हैं। सभी विकल्पों की सामान्य समझ इस तथ्य से नीचे आती है कि हमें किसी भी तरह से लिस्टेनप्रोविडर ऑब्जेक्ट को सूचित करने की आवश्यकता है (वह वस्तु जो घटना की सदस्यता लेने का अवसर प्रदान करती है), जो कि विशिष्ट इंटरफ़ेस से संबंधित है।

आप एक उदाहरण के रूप में कॉल किए गए प्रकार के लिए पारित वस्तु के रूपांतरण पर विचार कर सकते हैं। यह समझा जाना चाहिए कि अतिरिक्त मेटा-जानकारी प्राप्त करने के लिए कई विकल्प हो सकते हैं:

1. उदाहरण के रूप में, स्पष्ट रूप से पारित किया जा सकता है
2. श्रोता इंटरफेस के एनोटेशन में संग्रहीत किया जा सकता है
3. आप घटनाओं के नाम के रूप में श्रोता इंटरफ़ेस के नाम का उपयोग कर सकते हैं

सदस्यता कार्यान्वयन उदाहरण

  namespace MyFramework\Events; class ListenerProvider { private $handlerAssociation = []; public function addHandlerAssociation( string $handlerInterfaceName, string $handlerMethodName, string $eventName ) { $this->handlerAssociation[$handlerInterfaceName] = [ 'methodName' => $handlerMethodName, 'eventName' => $eventName ]; } public function addHandler(object $handler) { $hasAssociation = false; foreach( $this->handlerAssociation as $handlerInterfaceName => $handlerMetaData ) { if ( $handler interfaceof $handlerInterfaceName ) { $methodName = $handlerMetaData['methodName']; $eventName = $handlerMetaData['eventName']; $this->addListener($eventName, [$handler, $methodName]); $hasAssociation = true; } } if ( !$hasAssociation ) { throw new \Exception('Unknown handler object'); } } } 

हम सदस्यता ऑब्जेक्ट के लिए एक कॉन्फ़िगरेशन विधि जोड़ते हैं, जो प्रत्येक श्रोता इंटरफ़ेस के लिए अपने मेटाडेटा का वर्णन करता है, जैसे कि तथाकथित विधि और घटना का नाम।

इस डेटा के अनुसार, सदस्यता के समय, हम पास किए गए $ हैंडलर को कॉल करने योग्य वस्तु में बदल देते हैं, जो कि विधि को इंगित करता है।

यदि आप देखते हैं, तो कोड का अर्थ है कि एक $ हैंडलर ऑब्जेक्ट कई ईवेंट श्रोता इंटरफेस को लागू कर सकता है और उनमें से प्रत्येक के लिए सदस्यता ली जाएगी। यह कई घटनाओं के लिए एक वस्तु की बड़े पैमाने पर सदस्यता के लिए SubscriberInterface का एक एनालॉग है। जैसा कि आप देख सकते हैं, उपरोक्त कार्यान्वयन में addSubscriber(SubscriberInterface $subscriber) रूप में एक अलग तंत्र की आवश्यकता नहीं है addSubscriber(SubscriberInterface $subscriber) यह बॉक्स से बाहर काम करने के लिए निकला।

डिस्पैचर

काश, वर्णित दृष्टिकोण psr / event-dispatcher मानक के रूप में स्वीकार किए गए इंटरफ़ेस के लिए काउंटर चलाता है

चूंकि हमें डिस्पैचर के लिए किसी वस्तु को पास करने की आवश्यकता नहीं है। हां, आप चीनी जैसी वस्तु पास कर सकते हैं:

  class Event { public function __construct(string $eventName, ...$arguments) { // ... } public function getEventName(): string { // ... } public function getArguments(): array { // ... } } 

और psr इंटरफ़ेस पर एक ईवेंट बनाते समय इसका उपयोग करें, लेकिन यह केवल सादा बदसूरत है।

एक अच्छे तरीके से, डिस्पैचर इंटरफ़ेस इस तरह बेहतर होगा:

  interface EventDispatcherInterface { public function dispatch(string $eventName, ...$arguments); public function dispatchStopabled(string $eventName, ...$arguments); } 

दो विधियाँ क्यों? सभी उपयोग के मामलों को एक ही कार्यान्वयन में संयोजित करना मुश्किल है। प्रत्येक उपयोग के मामले के लिए अपनी खुद की विधि को जोड़ना बेहतर है, डिस्पैचर ने श्रोताओं से लौटाए गए मूल्यों को कैसे संसाधित करेगा, इसकी स्पष्ट व्याख्या की है।

वह सब है। इस समुदाय के साथ चर्चा करना दिलचस्प होगा कि वर्णित दृष्टिकोण को जीवन का अधिकार है या नहीं।