"संयुक्त" गेट्टर / सेटर वीएस व्यक्तिगत तरीकों के क्या फायदे हैं?

Question

इसे मैं "संयुक्त" गेट्टर / सेटर विधि (jQuery से) कहता हूं:

var foo = $("<div>This is my HTML</div>"),
    myText;

myText = foo.text(); // myHTML now equals "This is my HTML" (Getter)
foo.text("This is a new value"); // The text now equals "This is a new value")

यह अलग (सैद्धांतिक) तरीकों के साथ एक ही तर्क है:

var foo = $("<div>This is my HTML</div>"),
    myText;

myText = foo.getText(); // myHTML now equals "This is my HTML" (Getter)
foo.setText("This is a new value"); // The text now equals "This is a new value")

मेरा प्रश्न:

जब jQuery जैसी लाइब्रेरी डिजाइन करते हैं, तो आप पहले मार्ग पर जाने का फैसला क्यों करेंगे और दूसरा नहीं? क्या दूसरा दृष्टिकोण स्पष्ट नहीं है और एक नज़र में समझना आसान है?

Comments

मार्टिन फाउलर इस बात का प्रशंसक नहीं है कि वह "ओवरलोडेड गेटटर सेटर

— vaughandroid

मुझे गेट / सेट स्प्लिट मेथड पसंद है (यह सोचकर कोड अधिक "स्पष्ट" हो गया), लेकिन मैं इन दिनों ओवरलोडेड गेटर / सेटर पैटर्न को अधिक आकर्षक पा रहा हूं। यह कोड को क्लीनर बना सकता है। मैंने मिस्टर फाउलर के समझौते को पसंद करते हुए कभी खुद को नहीं पाया। यह मुझे लगता है कि यह दोनों दुनिया का सबसे बुरा है।

— ब्रायन नॉब्लुच

मार्टिन फाउलर के खिलाफ एकमात्र वास्तविक तर्क यह है कि जब एक तर्क में 'गेट्टर' गुजरता है, तो उस स्थिति में यह पाठक को भ्रमित करता है कि यह एक गेट्टर की तरह नहीं दिखता है। अब तक, मैंने निष्कर्ष निकाला है कि यदि आप उस कन्वेंशन से चिपके रहते हैं, जिसमें गेट्टर कोई तर्क नहीं देता है, और सेटर एक लेता है, तो, स्पष्ट एपीआई टिप्पणियों के साथ, jQuery / कोणीय दृष्टिकोण बस ठीक होना चाहिए। अभी के लिए।

— zumalifeguard

Answer 1

विशुद्ध रूप से यहां अटकलें लगाई जा रही हैं, लेकिन मैं jQuery डेवलपर्स पर विश्वास करना चाहूंगा, जिन्होंने jQuery को संरचित करने में बहुत कार्यात्मक शैली का उपयोग किया है, स्पष्ट रूप से कार्यात्मक प्रतिमान की ओर झुकाव है।

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

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

ऐसा इसलिए होगा क्योंकि मेरा मानना ​​है कि jQuery डेवलपर्स ने ऐसा किया है और सामान्य तौर पर यह है कि कोई व्यक्ति इस दृष्टिकोण को क्यों ले सकता है।

Comments

सहमत, प्लस मैं जेएस आकार को जितना संभव हो उतना कम करने की इच्छा जोड़ूंगा।

— मैट एस

-1 अनिवार्य / क्रिया और कार्यात्मक / अंतर्निहित बिंदु के लिए।

@MattFenwick का मतलब यह नहीं है कि क्या आप यह कह रहे हैं कि यह असत्य है कि कार्यात्मक प्रतिमान का निहितार्थ की ओर झुकाव होता है, जहां अनिवार्य प्रतिमान की खोजकर्ता के प्रति झुकाव होता है? मैं यह नहीं कह रहा हूं कि बेहतर है, बस यह कि एक या दूसरे को इस्तेमाल किया जा सकता है जो आपको स्वचालित रूप से उस तरह से दूसरे के विपरीत काम करने का कारण होगा (यह या तो समान रूप से जाता है)

— जिमी हॉफ

@ जिमी कोई समस्या नहीं; मेरी बात बस इतनी सी थी कि मेरे अनुभव में, मैंने एफपी / अनिवार्य के लिए ऑर्थोगोनल होने के लिए निहितार्थ / खोजकर्ता को पाया है।

@MattFenwick हो सकता है, लेकिन मैं उस प्रकार के इंफेक्शन से अलग कहूंगा, जो बहुत सारे निहितार्थ की अनुमति देता है और एचएम प्रकार प्रणाली के लिए सामान्य है, अन्य भाषाओं में एफपी भाषाओं के लिए सामान्य रूप से निहितार्थ की ओर झुकाव है, साथ ही साथ सभी ऑपरेटरों-जैसे-कार्य जहां फ़ंक्शन का एक स्पष्ट नाम नहीं है, बस एक प्रतीक है जिसे आप सीखना चाहते हैं और स्पष्ट रूप से जानते हैं, या डीयू के बजाय सदस्य अर्थ और स्थान के निहित ज्ञान की आवश्यकता वाली सूचियों या ट्यूपल्स का सामान्य उपयोग करते हैं (यह सोचते हैं कि लेखक मोनाद कैसे काम करता है)। मैं एकल अक्षर पैरामीटर नामों की समानता भी देख सकता हूं, लेकिन आप सही हो सकते हैं

— जिमी होफा

Answer 2

फार्म

foo.text("This is a new value"); 

कई चीजों का अर्थ लगा सकता है। आमतौर पर, यह एक fooवस्तु का सुझाव देता है , जिसमें textएक स्ट्रिंग को स्वीकार करने की एक विधि है , जो कुछ करता है । इसका कोई निहितार्थ नहीं है कि यह एक संपत्ति है।

कई भाषाओं में, इसे संक्षिप्त रूप माना जा सकता है

var result = foo.text("This is a new value"); 

जहां परिणाम को छोड़ दिया गया है। इसलिए यह दृष्टिकोण एक संपत्ति (एक कोड पठनीयता बिंदु से) को सेट करने के लिए एक प्रभावी तरीका होने के लिए बहुत अस्पष्ट है।

Comments

यह एक उत्कृष्ट मुद्दा है! जब मैं जावास्क्रिप्ट पढ़ता हूं तो मैं अपने FP के चश्मे पर रखता हूं और चीजें अलग-अलग दिखती हैं इसलिए मैंने इस बारे में सोचा भी नहीं था, लेकिन अगर मैंने C # में इस तरह का कोड देखा तो मुझे बिल्कुल प्रतिक्रिया होगी कि आपका "Wth इस विधि को करता है" ?? "।

— जिमी हॉफ

Answer 3

यह थोड़ा अटकलबाजी है, लेकिन यहां मेरा शॉट है।

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

फंक्शनल लैंगेज में डिक्लेक्टिव सिंटैक्स पर जोर दिया जाता है। यह आदेशों की तरह एक तथ्य के बयान की तरह पढ़ना पसंद करता है। उदाहरण

var eligible = customers.where(c => c.age > 30);

जिसे "योग्य ग्राहक के रूप में पढ़ा जा सकता है, जिनकी आयु 30 वर्ष से अधिक है"। विवश होकर, अनिवार्य भाषा आज्ञा के अनुक्रम की तरह पढ़ी जाती है

for (customer in customers)
    if (customer.age > 30)
        eligible.add(customer)

इसे "प्रत्येक ग्राहक की जांच करें, और यदि उनकी उम्र 30 वर्ष से अधिक है, तो उन्हें योग्य संग्रह में जोड़ें"

आ setऔर एक getऑपरेशन को जोड़ने से jQuery को एक अनिवार्य पुस्तकालय जैसा महसूस होगा। आप निम्नलिखित कथनों को पढ़ने के तरीके में बाधा डाल सकते हैं

// The element tag have an html of <p>hello</p>
$("#element").html("<p>hello</p>"); 

// content represent the html of the element tag
var content = $("#element").html();


//Imperative style

// Set the element tag to an inner html of <p>hello</p>
$("#element").setHtml("<p>hello</p>");

//Get the html of #element, and put it in the content variable
var content = $("#element").getHtml();

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

Answer 4

यह कुछ और गुणों की तरह व्यवहार करता है , जो केवल हाल ही में जावास्क्रिप्ट के लिए पेश किए गए थे, और इसलिए व्यापक रूप से अभी तक उपयोग नहीं किए गए हैं, विशेष रूप से jQuery जैसी पुस्तकालयों में जो ब्राउज़र असंगतताओं को दूर करने में मदद करने के लिए हैं।

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

चूंकि आपने केवल फायदे के लिए कहा था, इसलिए मैं नुकसान को कवर नहीं करूंगा।