Magento के 2 वर्गों बनाम प्लगइन्स को फिर से लिखना

Question

Magento 2 में Magento 1 के विपरीत प्लगइन्स / अवरोधन / अवरोधकों की अवधारणा है ।
ये पहले की तरह हर सार्वजनिक विधि के लिए घटना के बाद है। जो अच्छा है। एक विधि की कार्यक्षमता को बदलने के लिए
आप aroundप्लगइन का उपयोग भी कर सकते हैं ।
लेकिन Magento 2 अभी भी M1 तरीके से अधिक या कम वर्गों को फिर से लिखने की संभावना प्रदान करता है।
मैं कुछ उदाहरणों को देखना चाहूंगा जहां पुन: लिखने की कक्षाएं प्लगइन्स का उपयोग करने के बजाय जाने का तरीका हैं।
मुझे पता है कि यह तब उपयोगी है जब आप एक कोर संरक्षित विधि के व्यवहार को बदलना चाहते हैं, लेकिन क्या ऐसे अन्य मामले हैं जहां एक पुनर्लेखन की सिफारिश की जाती है या आवश्यकता होती है?

Comments

संबंधित: magento.stackexchange.com/questions/93932/…

— रोबी एवरिल

Answer 1

एक प्लगइन के बजाय एक पुनर्लेखन का उपयोग करने का स्पष्ट कारण यह है कि जब आपको ओवरराइड करने की आवश्यकता होती है निजी, संरक्षित या अंतिम तरीकों ।

लेकिन निम्नलिखित परिदृश्यों पर भी विचार करें।

पहला परिदृश्य (पूर्ण क्रम क्रम):

जब आप प्लगइन्स से पहले अपने कोड को चलाना चाहते हैं, तो रिवाइट्स उपयोगी हो सकते हैं । मुझे पता है कि आप इसे प्लगइन सेट करके कर सकते हैं sortOrder, लेकिन आप यह सुनिश्चित नहीं कर सकते कि आपका कोड हमेशा पहला होगा जब कोई व्यक्ति (आप नहीं) 3 पार्टी घटकों को स्थापित करने जा रहा है।

दूसरा परिदृश्य (कोड बाहर करें):

यदि आपको किसी विधि में कोड के एक टुकड़े को बाहर करने या फिर से लिखने की आवश्यकता है , तो एक प्लगइन एक उप-इष्टतम तरीका हो सकता है। मुझे पता है कि आप एक aroundप्लगइन का उपयोग कर सकते हैं और कॉल करने से बच सकते हैं proceed, लेकिन यह स्टैक में अन्य प्लगइन्स को तोड़ सकता है।

तीसरा परिदृश्य (कोड शैली):

जब आपको किसी व्यवहार को फिर से लिखने की आवश्यकता हो, तो आपको राइटर्स का उपयोग करना चाहिए आउटपुट संशोधित करने या कोड को पहले / बाद में चलाने के ।

एक प्लगइन, हमेशा अन्य मॉड्यूल को तोड़ने से बचने के लिए मूल कोड चलाना चाहिए ।

मेरा निष्कर्ष:

यदि आप एक कोर विधि को ब्लैक बॉक्स के रूप में मान सकते हैं एक इनपुट और एक आउटपुट के साथ हैं और आप इसके आंतरिक तंत्र के बारे में अज्ञेय हैं, तो एक प्लगइन सबसे अच्छा विकल्प हो सकता है।

यदि आपको एक आंतरिक व्यवहार बदलने की आवश्यकता है , तो एक फिर से लिखना सबसे अच्छा विकल्प हो सकता है।

Comments

1 परिदृश्य थोड़ा या गलत है (मुझे लगता है कि यह केवल शब्दांकन है) वास्तविक विधि कोड से पहले या आस-पास प्लग इन चलता है (या चला सकता है)।

— डेविड वेरहोलन

हां, मेरा कहना सही नहीं था। मेरी बात वास्तविक पद्धति के सापेक्ष क्रमबद्ध क्रम के बारे में थी।

— फीनिक्स128_रीकॉर्डो

Answer 2

महान सवाल है, मैंने खुद से दूसरे दिन भी यही बात पूछी है और यहाँ मैं जो लेकर आया हूँ:

• सबसे पहले, प्लगइन्स का उपयोग अंतिम तरीकों के लिए नहीं किया जा सकता है, अंतिम वर्गों और वर्गों पर निर्भरता इंजेक्शन के बिना बनाया गया है मुझे लगता है कि यह एक बहुत ही विशिष्ट मामला है, लेकिन यह एक ऐसा मामला है जहां आप प्लगइन्स का उपयोग नहीं कर सकते हैं
• दूसरा, आपको एक प्लगइन की परिभाषा को ध्यान में रखना होगा। इसका उपयोग विधि स्तर पर काम करने के लिए किया जाता है जबकि वरीयताओं का उपयोग पूरे वर्ग स्तर पर काम करने के लिए किया जाता है। यह सभी के लिए स्पष्ट नहीं है इसलिए इसे ध्यान में रखना अच्छा है।
• अंत में, और मुझे लगता है कि सबसे महत्वपूर्ण है, ऐसा लगता है कि प्लगइन्स का उपयोग केवल Magento वर्ग के भीतर किसी भी सार्वजनिक विधि के व्यवहार को बढ़ाने के लिए किया जा सकता है । इस प्रकार ऐसा लगता है कि आप संरक्षित / निजी विधियों के साथ प्लगइन्स का उपयोग नहीं कर सकते हैं ।

स्रोत: मैगनेटो यू फंडामेंटल कोर्स

Comments

ठीक है। अच्छे कारण हैं। मैं नहीं जानता कि दूसरे बिंदु के बारे में क्या कहना है। यदि आप एक ही वर्ग से बहुत सारे सार्वजनिक तरीकों को प्लगइन करना चाहते हैं, तो मुझे लगता है कि सबसे सुरक्षित तरीका एक एकल वर्ग बनाना है जो उन सभी के लिए एक प्लगइन के रूप में कार्य करता है। (मेरी राय)। मैं यह देखने के लिए 2-3 दिन छोड़ दूंगा कि क्या कोई अन्य कारणों के साथ आता है। अगर नहीं .... चेकमार्क आपका है।

— मेरियस

@ आप बिल्कुल सही फिर से हो सकते हैं: दूसरा बिंदु। कुछ कारणों से मैंने सोचा था कि आपको हर उस विधि के लिए कई प्लगइन फाइलें बनानी होंगी, जिन्हें आप प्लगइन करना चाहते थे, लेकिन मुझे लगता है कि पर्यवेक्षक ऐसा करते हैं, न कि प्लगइन्स। यदि अधिक लोग यह देखने के लिए उत्तर देते हैं कि क्या अधिक कारण (गैर स्पष्ट) है तो यह अच्छा होगा।

— राफेल डिजिटल पियानोवाद

एक अतिरिक्त के रूप में @ मर्म: क्योंकि प्लगइन्स डोमेन विशिष्ट होना चाहिए, मुझे लगता है कि कम से कम एक कक्षा में कई प्लगइन्स को परिभाषित करने के लिए यह सबसे अच्छा अभ्यास होना चाहिए, अगर वे एक ही सुविधा के कार्यान्वयन हैं। एक पुनर्लेखन के साथ, आपके पास यह विकल्प नहीं होता है क्योंकि आप हमेशा एक पूरी कक्षा बदलते हैं। इसलिए मुझे लगता है कि कम से कम फिर से लिखने की कोशिश करने का एक कारण होगा

— डेविड वेरहोलन

@DavidVerholen। मैं पूरी तरह सहमत हूँ। लेकिन मैं प्लगइन्स के बजाय फिर से लिखने के कारणों का कारण पूछ रहा था।

— मेरियस

हां मुझे लगता है कि यह प्लगइन्स का उपयोग करने का एक कारण हो सकता है क्योंकि आप फ़ीचर विशिष्ट प्लगइन वर्गों को परिभाषित कर सकते हैं, जबकि एक पुनर्लेखन केवल एक बार किया जा सकता है

— डेविड वेरहोलन