Magento 2 - जादू पाने वालों से बचने / उपयोग करने के लिए अच्छा अभ्यास?

21

Varien_Object(M1) और DataObject(M2) पर मैजिक गेटर्स आम बात है, लेकिन Magento 2 के साथ इसका इस्तेमाल करना गलत लगता है।

अच्छा:

पढ़ने / लिखने में आसान

खराब

यह कुंजियों में अंकों का उपयोग करते समय समस्याओं का कारण बनता है (देखें: Magento 2: अलग तरीके से संग्रह का क्षेत्र प्राप्त करें या कस्टम उत्पाद विशेषता का उपयोग करें )
कोड विश्लेषण उपकरण गैर-मौजूदा तरीकों के बारे में शिकायत करते हैं

सवाल

Magento 2 के साथ हमारे पास दो नए तरीके हैं:

getDataByKey($key)
getDataByPath($path)

क्या अभी भी उपयोग करने का कोई अच्छा कारण है getData($key)या कोई जादू पाने वाला है?

संपादित करें:

@Vinai धन्यवाद मैंने @methodविधि का उल्लेख नहीं किया , क्योंकि मेरा दृष्टिकोण काफी अलग था।

यह केवल आईडीई की मदद करता है, लेकिन अन्य चीजों पर कोई प्रभाव नहीं पड़ता है।

उस पर कई mergedf पीआरएस कर रहे हैं करने के लिए कास्टिंग की तरह "सूक्ष्म अनुकूलन" कर रहे हैं (int)के बजाय intval()या सरणी आकार के बाहर छोरों प्राप्त (यहां तक कि छोटे सरणियों के लिए)।

दूसरी ओर हैं

जादुई गेटर्स, जिसका कुछ "ओवरहेड" है जैसा कि मारियस ने वर्णित किया है ...।
```
strtolower(trim(preg_replace('/([A-Z]|[0-9]+)/', "_$1", $name), '_'));
```
getData($key) mehtods को भी 2-3 अतिरिक्त जांच करनी होगी ...
- if ('' === $key) {
- if (strpos($key, '/')) {
- if ($index !== null) {

अपने कोड के लिए वास्तविक तरीकों को पसंद करने के लिए पूरी तरह से सहमत हैं, लेकिन एक ही मामलों में यह संभवतः नहीं है ... जैसे कि आपने एक कस्टम ईवेंट बनाया है ...

$value = $observer->getVar_1();
$value = $observer->getData('var_1');
$value = $observer->getDataByKey('var_1');

3 का उपयोग करना /** @var some $value */मेरे लिए सबसे अच्छा लगता है। (?)

— sv3n
स्रोत

1

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

— लिली बर्गांज़ात

20

उपरोक्त प्रश्न जादू के तरीकों बनाम getDataByKeyया का उपयोग करने के बारे में है getDataByPath। मुझे लगता है कि एक तीसरा विकल्प भी है, और वह है असली गेट्टर और सेटर के तरीकों को लागू करना।

सभी getData*तरीकों में नकारात्मक पक्ष यह है कि उन्हें काम करने के लिए प्रकार के लिए एनोटेट करना होगा।
आमतौर पर यह कॉल के /* @var string $foo */ऊपर एनोटेशन के साथ किया जाता है getData*।
यह थोड़ा बदबूदार है, क्योंकि डेटा के प्रकार को उस वर्ग में घोषित किया जाना चाहिए जिसमें डेटा होता है, न कि उस वर्ग को जो कॉल करता है getData*।
इसका कारण यह है कि यदि डेटा बदलता है, तो क्लास को अपडेट किए जाने की सबसे अधिक संभावना है, सभी getData*कॉल साइट नहीं।
यही कारण है कि मुझे लगता है कि एक्सेसर्स का उपयोग करने की तुलना में वास्तविक विधियां स्थिरता बनाए रखती हैं getData*।

इसलिए मुझे लगता है कि यह स्थिरता और त्वरित कार्यान्वयन (लिखने के लिए कम कोड) के बीच व्यापार से उबता है।

सौभाग्य से, आजकल आईडीई वास्तव में हमारे लिए गेट्टर और सेटर कार्यान्वयन को बनाने में अच्छे हैं, ताकि तर्क वास्तव में किसी भी अधिक लागू न हो।

जादू पाने वालों और बसने वालों के खिलाफ एक और तर्क जो ऊपर के सवाल से गायब है, वह यह है कि उनके लिए प्लगइन्स बनाना संभव नहीं है।

एकमात्र अन्य मूल्य जो मुझे लगता है कि मैं विषय में जोड़ सकता हूं @method, एनोटेशन का उपयोग करने या न करने के कारणों को इकट्ठा करने की कोशिश कर रहा हूं , अगर वास्तविक तरीकों को लागू करना किसी कारण से सवाल से बाहर है।

पेशेवरों

एक @methodएनोटेशन एक असली गेटर और सेटर को लागू करने की तुलना में लिखने के लिए थोड़ा कम कोड है। यह आजकल के बमुश्किल सच है क्योंकि आईडीई एक्सेसरी विधियों को बनाने में अच्छे हैं, इसलिए यह वास्तविक लाभ नहीं है।

विपक्ष

चीजों को गलत करना आसान है।
- टिप्पणियां टिप्पणियां हैं, कोड विकसित होने पर वे आसानी से अप्रचलित हो जाते हैं लेकिन एनोटेशन अपडेट नहीं किए जाते हैं। असली तरीके ज्यादा मजबूत होते हैं।
- एक दुभाषिया त्रुटि के बिना विभिन्न प्रकार के हस्ताक्षर के साथ कई एनोटेशन जोड़ना संभव है - स्थिर कोड विश्लेषण व्यवहार अपरिभाषित है, और इससे सूक्ष्म कीड़े हो सकते हैं जो नीचे ट्रैक करना मुश्किल हैं।
- यदि एक @methodएनोटेशन और एक ही नाम वाली वास्तविक विधि मौजूद है, तो एनोटेशन प्रकार का हस्ताक्षर स्थिर कोड विश्लेषण के दौरान वास्तविक विधि को ओवरराइड करता है, जो कि PHP दुभाषिया के विपरीत है। यह फिर से आसानी से सूक्ष्म कीड़े पैदा कर सकता है।

उपरोक्त कारणों से मैं व्यक्तिगत रूप से @methodएनोटेशन का उपयोग नहीं करता हूं अगर मैं उनसे बच सकता हूं।
ऐसे कोड के लिए जो लंबे समय तक जीने का इरादा है मैं वास्तविक गेट्टर और सेटर विधियों को लागू करता हूं। उन्हें बनाए रखने के लिए IDE को ट्रिगर करने के प्रयास के लिए बनाए रखने योग्य लाभ है।

स्पाइक के दौरान अधिक प्रयोगात्मक कोड के लिए, या किसी मॉड्यूल के सरल कार्यान्वयन विवरण के लिए getData*, मैं विधियों का उपयोग करता हूं , क्योंकि मैं आलसी हूं।

— Vinai
स्रोत

अच्छा सारांश। धन्यवाद विनय जितना मैंने पूछा था उससे कहीं अधिक जवाब।

— sv3n

1

सभी getData*तरीकों में नकारात्मक पक्ष यह है कि उन्हें काम करने के लिए प्रकार के लिए एनोटेट करना होगा।

आमतौर पर यह कॉल के /*@var string $foo */ऊपर एनोटेशन के साथ किया जाता है getData*। यह थोड़ा बदबूदार है, क्योंकि डेटा के प्रकार को उस वर्ग में घोषित किया जाना चाहिए जिसमें डेटा होता है, न कि उस वर्ग को जो गेटटाटा * कहता है।

इसका कारण यह है कि यदि डेटा बदलता है, तो क्लास को अपडेट किए जाने की सबसे अधिक संभावना है, सभी getData*कॉल साइट नहीं। यही कारण है कि मुझे लगता है कि getData * एक्सेसर्स का उपयोग करने की तुलना में वास्तविक विधियां स्थिरता बनाए रखती हैं।

हां यह बदबूदार है, लेकिन (और?) से बचा जा सकता है। मुझे लगता है कि यह बहुत ही सामान्य कोड है और अक्सर सुझाव दिया जाता है:

/** @var Foo $product */
$product = $model->getProduct()
if ($product->getId()) {
    $product->doSomething();
}

समस्याओं आप सिर्फ अनुमान है कि वापसी मूल्य Fooएक कॉल करने योग्य getId()मेथोड के साथ प्रकार है ।

स्थिरता के लिए क्यों नहीं चर प्रकार ग्रहण करते हैं और एक जोड़ते हैं InvalidArgumentException?

$product = $model->getProduct()
if ($product instanceof Foo && $product->getId()) {
    $product->doSomething();
}

यह उस स्थिति में स्थैतिक कोड एनालाइज़ेशन को भी ठीक करता है $model->getProduct()जिसमें अलग-अलग रिटर्न प्रकार होते हैं - जैसे Foo|false। पहले मामले में यह doSomething()संभव पर कॉल करने के बारे में शिकायत करेगा false।

— sv3n
स्रोत