प्रोटोटाइप वंशानुक्रम को लागू करने में पूर्वजों के तरीकों को कैसे लागू किया जाए

जब वंशानुक्रम के साथ काम करते हैं, तो कभी-कभी पूर्वजों की विधि (मूल वर्ग की विधि) तक पहुंच कार्य करने की इच्छा होती है - निर्माणकर्ता (जावास्क्रिप्ट के लिए कक्षा का एनालॉग) या वंशज विधि में, क्योंकि यह है कि एक नया वर्ग इसे ओवरराइड करता है। केवल कोई फ़ंक्शन (विधि) नहीं है, लेकिन पूरी तरह से समझने योग्य संकेतन के साथ ताकि नाम खुद के लिए बोलता है और पूर्वजों की निर्दिष्ट पीढ़ी तक पहुंचता है ("महान-महान-महान नहीं", लेकिन "महान -3 बार")।

मान लीजिए कि प्रोटोटाइप इनहेरिटेंस विधि के आधार पर, जो सबसे अधिक प्रभावी है कि यह विरासत में मिली कक्षाओं की श्रृंखलाओं का वर्णन करते समय न्यूनतम क्रियाएं करता है और साथ ही साथ मूल संचालन और विरासत गुणों का समर्थन करता है: उदाहरण के लिए, कंस्ट्रक्टर । पूर्वज की पहुंच के लिए, वह .सुपरक्लास संपत्ति बनाता है। (वे दावा करते हैं कि क्रॉकफोर्ड द्वारा कक्षाओं के लिए एक आधार दृष्टिकोण के रूप में इसे लोकप्रिय बनाया गया था, कोई लिंक नहीं मिला था, लेकिन यह महत्वपूर्ण है कि विधि को बाहर माना जाता है और किफायती है। लेखक अज्ञात है।)

आरंभ करने के लिए, यहां इस विधि के लिए अपनी संक्षिप्त टिप्पणियों के साथ कोड है।

function inherit2(Inherited, Parent){ //  var F = function(){}; F.prototype = Parent.prototype; (Inherited.prototype = new F()).constructor = Inherited; //    //   ,       Inherited.superclass = Parent.prototype; //  } 

(जो पहले जावास्क्रिप्ट में विरासत के विषय में रुचि रखते थे, निश्चित रूप से उन्हें मान्यता दी।) यह javascript.ru/tutorial/object/inheritance में बहुत विस्तार से जांच की गई थी, और पैतृक तरीकों तक पहुंच की समस्या को भी कवर किया गया था: हमने "चारों ओर" के साथ "खेला"। .constructor "लिंक को स्वयं बंद करके ताकि भविष्य के वर्ग के पास सही .constructor संपत्ति हो। लेकिन, निश्चित रूप से, उन्होंने विरासत में मिली कक्षाओं के बीच संबंधों की शुद्धता खो दी (और यह मौजूद नहीं था, यह भाषा में नहीं था) और मूल वर्ग तक पहुंच के लिए एक "बोनस" .सुपरक्लास संपत्ति बनाने के लिए मजबूर किया गया था।

पैतृक तरीकों की आवश्यकता क्यों है?

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

योजना के अनुसार विरासत में मिली कक्षाओं के लिए A => B => C => c01.MethodX

  function A(){this.xa =1;} function B(){this.xb =1;} function C(){this.xc =1;} A.prototype.MethodX ='protoA'; inherit2(B, A); B.prototype.MethodX ='protoB'; B.prototype.xx ='protoX'; inherit2(C, B); C.prototype.MethodX = 'protoC'; var c01 = new C(); 

हमें पूर्वज विधि तक पहुँचने के ऐसे तरीके मिलते हैं:

 Alert = console.log; Alert(c01.MethodX); //'protoC' //  Alert(c01.constructor.prototype.MethodX); //'protoC' //    Alert(c01.constructor.prototype.superclass.MethodX); //'proto' //   Alert(c01.constructor.prototype.superclass.constructor.superclass.MethodX); //'protoA'. 

(यह कैसे काम करता है यह देखने के लिए, inherit2 के लिए निष्पादन योग्य उदाहरण देखें () (यह फायरबग के साथ देखने के लिए चोट नहीं पहुंचाएगा।)
इस तरह की कॉल का उपयोग करना असुविधाजनक है, लेकिन सहकर्मियों और अनुयायियों को भ्रमित करने के लिए यह सुविधाजनक है: पहले हम .constructor.prototype से गुज़रते हैं , और फिर .superclass के माध्यम से, यह कहने के बजाय कि हम क्या चाहते हैं; हम पूर्वजों की पहुंच की गहराई का संकेत नहीं दे सकते। सभी में, फॉर्म का एक छोटा कार्य आवश्यक है:

 object.ancestor(name, level) - //  /   , 

जिसे सबसे गहरी कक्षा में रखा जाएगा और "अधिलेखित" विधियों (और पड़ोसी तरीकों की ओर कोई भी परेशान नहीं करता है) के साथ नए तरीकों की कार्यक्षमता का विस्तार कर सकता है।

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

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

मैं क्या प्राप्त करना चाहूंगा

c01 ['मेथडएक्स']	c01.ancestor ('MethodX', 0)
c01.constructor.prototype ['MethodX']	c01.ancestor ('MethodX')
c01.constructor.prototype._anc.prototype ['MethodX']	c01.ancestor ('मेथडएक्स', 2)
c01.constructor.prototype._anc.prototype._anc.prototype ['MethodX']	c01.ancestor ('मेथडएक्स', 3)
...

उसी समय, c01.constructor c01._anc हो सकता है, अगर हमने इसे प्रत्येक नए के साथ लिखा है, अर्थात। नए के बजाय एक विशेष फ़ंक्शन बनाएगा ( इस तरह के एक फ़ंक्शन बनाने के लिए कॉल करने की प्रवृत्ति होती है ) () , लेकिन हम किसी वस्तु के निर्माण के संकेतक के रूप में नए को बचाने के लिए ऐसा नहीं करेंगे (अभी के लिए?)।

परिणाम इस तरह के एक समारोह द्वारा प्राप्त किया जाता है:

 function ancestor(name, level, constr){ level = level || (level ==0 ? 0 : 1); var t =this; return level <= 1 ? (level ? constr && constr.prototype[name] || t.constructor.prototype[name] : t[name]) : arguments.callee.call(this , name , level -1 , constr && (constr.prototype._anc || constr.prototype.constructor) || t._anc // ( )    ); } 

Inherit3 () के लिए स्रोत कोड भी ._anc () फ़ंक्शन का उपयोग करने के लिए थोड़ा बदल गया है।

 function inherit3(Inherited, Parent){ var F = function(){}; F.prototype = Parent.prototype; (Inherited.prototype = new F())._anc = Parent; Inherited.prototype.constructor = Inherited; } 

पूर्वजों तक पहुंच का तर्क।

हम विधि की वर्तमान परिभाषा की ओर नहीं रुख करते हैं, लेकिन जो पहले विरासत के स्तर के स्तर पर था।

यदि हमें पद्धति की सटीक परिभाषा नहीं मिलती है, तो प्रोटोटाइप श्रृंखला पिछली पीढ़ी की तुलना में पहले चरणों के स्तर पर उठाए गए मूल तरीकों में से नवीनतम को पुनः प्राप्त करती है।

यदि कोई प्रोटोटाइप नहीं हैं, तो हम फ़ंक्शन के "दयालुता का बम" (एक असंतुष्ट) को प्राप्त करते हैं जब लापता संपत्ति की त्रुटियां उत्पन्न नहीं होनी चाहिए, लेकिन हमारे पास हमेशा श्रृंखला में परिभाषित पहला पहला तरीका होता है। यदि कोई संपत्ति नहीं है, तो हम किसी भी स्तर पर अपरिभाषित हो जाते हैं।

यदि हम एक दयालु बम नहीं चाहते हैं, तो हम कुछ नकली गुणों को लिखते हैं जब संपत्ति constr.prototype._anc के स्थान पर नहीं होती है, उदाहरण के लिए, ( constr.prototype._anc || constr.fail.fail ) या बस ( constr.prototype._anc ) विफल होती है। ।

  function A(){this.prop =1;} function B(){this.prop =1;} function C(){this.prop =1;} A.prototype.protoProp ='protoA'; inherit3(B, A); B.prototype.protoProp ='protoB'; inherit3(C, B); C.prototype.protoProp ='protoC'; var c01 = new C(); A.prototype.ancestor = ancestor; Alert(c01['protoProp'], c01.ancestor('protoProp', 0)) //'protoC protoC' Alert(c01.constructor.prototype.protoProp, c01.ancestor('protoProp')) //'protoC protoC' Alert(c01.ancestor('protoProp', 2) ); //'protoB' Alert(c01.ancestor('protoProp', 3) ); //'protoA' Alert(c01.ancestor('protoProp', 4) ); //'protoA' Alert(c01.ancestor('protoProp', 5) ); //'protoA' Alert(c01.ancestor('protoProp', 6) ); //'protoA' Alert(c01.ancestor('protoProp2', 4) ); //'undefined' 

स्क्रिप्ट देखें, फायरबग में ट्विस्ट - एक डेमो पर (यह एक दया बम के साथ है)।
वंश का प्रोटोटाइप वंशानुक्रम के बाद लिखा जाना आवश्यक है, और कहीं और नहीं - इनहेरिट 2 में प्रोटोटाइप के साथ काम करने का एक परिणाम () । एक सामान्य पूर्वज का प्रोटोटाइप कहीं भी बदल सकता है, जैसा कि सभी विरासत के बाद पूर्वज () विधि को जिम्मेदार ठहराते हुए दिखाया गया है। उदाहरणों में, गुणों का उपयोग हर जगह किया गया था, न कि तरीकों - संक्षिप्तता के लिए, लेकिन प्रारूप में तरीकों को निर्दिष्ट या निष्पादित करने में कोई समस्या नहीं है

 c01.ancestor('protoMethod', 3) //  c01.ancestor('protoMethod', 3)(args) //  

क्या सुधार की जरूरत है?

सब कुछ, लेख का कार्य पूरा हो गया है, क्या मैं सोने जा सकता हूं? नहीं, विकास कभी नहीं रुकता है, और समझदार पाठक को 2 विषम कार्यों और उपयोग की कई स्थितियों को प्राप्त करने के बाद नैतिक संतुष्टि नहीं मिली। इस विधि में क्या भ्रम है कि पूर्वज से वंशज तक प्रोटोटाइप का विस्थापन है। दरअसल, अक्सर वस्तुओं में पहले से ही प्रोटोटाइप होते हैं, उन्हें फिर से लिखे जाने की आवश्यकता नहीं होती है, लेकिन विस्तारित (विस्तारित) होती है, अन्यथा विरासत की तीसरी मंजिल पर हमें समस्याएं मिलती हैं और विधि को बदलने की आवश्यकता होती है।

हमने अपने पाठकों के लिए तुरंत तैयार कोड क्यों नहीं तैयार किया, लेकिन उन्हें अर्द्ध-तैयार उत्पादों पर जाने के लिए मजबूर किया? क्योंकि यह कोड सोच डेवलपर्स के लिए आवश्यक है, उन्हें यह जानने की जरूरत है कि एक्सेस विधि कैसे काम करती है। कंकाल पहले भाग में बनाया गया है, बिना किसी सुंदरियों और अन्य मांस के। कंकाल की संरचना बेहतर देखी जाती है जब उस पर कोई मांस नहीं होता है। हम वांछित सुधार जारी रखते हैं।

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

 extend = function(obj, extObj){ //    if(arguments.length >2) for(var a =1, aL = arguments.length; a < aL; a++) arguments.callee(obj, arguments[a]) else{ for(var i in extObj) obj[i] = extObj[i]; return obj; }; 

यह अच्छा है क्योंकि "मामलों के बीच में" आपको पहले विस्तार करने के लिए कई तर्कों का उपयोग करने की अनुमति देता है। इस बीच, यहां तक ​​कि यह फ़ंक्शन हमें " C.prototyp.protoProp = 'protoC; " लेकिन लिखने की अनुमति नहीं देगा ;

 extend(C.prototype, {protoProp: 'protoC'}); //    . 

ध्यान दें कि .superclass की अब आवश्यकता नहीं है; इसे कोड से बाहर निकाल दिया गया है।

इसके अलावा, वंशानुक्रम की यह विधि इतनी कठोर और किफायती है कि यह निर्माणकर्ताओं को निष्पादित नहीं करती है , इसलिए हम केवल एक निर्माता के गुणों को देख सकते हैं जहां नया किया जाता है - ऑब्जेक्ट c01 में । कक्षाओं के बीच कोई रचनाकार रनटाइम्स नहीं हैं। इस तरह की कठोरता की हमेशा जरूरत नहीं होती है (ओह, हमेशा नहीं)। इसके द्वारा निर्मित कंस्ट्रक्टर्स के गुण मौजूद होते हैं। प्रोपर्टी मौजूद हो सकते हैं और प्रोटोटाइप विरासत में भी भाग ले सकते हैं (वारिस के प्रोटोटाइप की एक संपत्ति हो)।

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

डेवलपर्स और वर्गों (संग्रह) के लिए समान तरीके क्या डेवलपर्स पसंद करते हैं?

एक समान समस्या, निश्चित रूप से, वर्गों और विरासत के कार्यान्वयन के बीच में आई थी, जिसे "मूल वर्ग की कॉलिंग विधियों" शब्दों से पाया जा सकता है।
habrahabr.ru/blogs/javascript/40909

इसने मूल __parent विधि बनाई, जो सुपरक्लास पद्धति के समान कार्य करती है। इसमें, यदि आप पूर्वजों का उल्लेख करते हैं, तो भी कई कॉल का उपयोग करना आवश्यक है।
पुस्तकालय कई और तरीके प्रदान करता है:
मिक्सिन (ए, बी) - प्रोटोटाइप बी के अलावा प्रोटोटाइप ए,
क्लोन () - एक वस्तु का क्लोनिंग,
विस्तार () - हैश एक्सटेंशन; केवल कुछ तर्कों के लिए।

सुपरक्लास ऐसे तरीकों से नहीं जुड़ता है: ["hasOwnProperty", "isPrototypeOf", "propertyIsEnumerable", "toLocaleString", "toString", "valueOf"] एक अच्छा विचार है।

पूर्वजों की पहुंच का एक और उदाहरण (रेजिग से)

Ejohn.org/blog/simple-javascript-inheritance (जॉन रिज़िग द्वारा सरल जावास्क्रिप्ट वंशानुक्रम) में हम _super की उपस्थिति देखते हैं और एक विशेष क्लास कंस्ट्रक्टर के साथ विधि का विस्तार करते हैं जो इस वर्ग समानता पर जोर देता है। यहाँ, विस्तार एक हैश एक्सटेंशन नहीं है, लेकिन " अतिलेखित " लोगों के लिए _super संपत्ति सेट करने के लिए गुणों की एक सूची के माध्यम से स्क्रॉल करने की एक विशेष प्रक्रिया है - एक विधि या संपत्ति जो अगर माता-पिता पर एक पुन: लिखने योग्य विधि पाई जाती है, तो बनाई जाती है। जाहिर है, यह एक अधिक महंगा तंत्र है। पूर्वजों के तरीकों का एक बार उपयोग करने और इसे केवल कॉल करने के बजाय, हम एक "वर्कअराउंड" विधि बनाते हैं, जो हर बार वारिस के निर्माण के लिए, पूर्वजों के तरीकों की पूरी सूची के माध्यम से चल रहा है। यह उचित हो सकता है यदि बहुत सारे संसाधन हैं, तो हम पूर्वजों की ओर रुख करते हैं, जब हम नई कक्षाएं बनाते हैं। सामान्य तौर पर, पूर्वजों का उल्लेख करना कार्यों के विवरण में माना जाता है - एक पूरी तरह से रनटाइम विधि जो प्रभावी होनी चाहिए, इसलिए सीधे लिंक लिखने का दृष्टिकोण कभी-कभी उचित होता है। एक विकल्प के रूप में, हमारे पास .Net के साथ तरीकों की सूची के माध्यम से चलने की किसी भी कीमत के बिना लिंक (ऑब्जेक्ट) के माध्यम से पहुंच है ।

अगली श्रृंखला की सामग्री

जिस नायक ने अकेले चार-सिर वाले प्रतिक्रिया हाइड्रा को भरने का फैसला किया, वह लगभग हरक्यूलिस है, लेकिन हम जानते हैं कि प्रोग्रामर फ्रेम खींचता है। वह सफलतापूर्वक 4 पाई गई समस्याओं पर विचार करता है (1 - कोड एक विधि में परिवर्तित हो जाता है, 2 - वारिस के प्रोटोटाइप का विस्तार जोड़ा जाता है, 3 - मिश्रित विधियों का स्वतंत्र उपयोग संभव है, 4 - विरासत के दौरान कोड लिखने का प्रारूप बेहतर होता है और एक स्ट्रोक के साथ - कोड का एक टुकड़ा - उन्हें हल करता है। यह पता चला कि 5 वीं समस्या एक ही समय में हल नहीं हुई थी, लेकिन चलो इसे लिखित कोड का गैर-अधिभार कहते हैं - भविष्य की छोटी विधि वारिसों के केवल प्रोटोटाइप नहीं बल्कि किसी भी अन्य हैश का विस्तार करने में सक्षम होगी। कोड आसानी से इस लेख में दिए गए स्रोत कोड का अनुमान लगाता है, जो डेवलपर्स को विचारों के विकास का पालन करने और उनके उचित कार्यान्वयन का चयन करने में मदद करेगा। दर्शक जानना चाहेंगे कि यह कैसे हुआ - उदाहरणों के साथ एक फ्रेम-बाय-फ्रेम देखने से उन्हें इसमें मदद मिलेगी। कोड वास्तव में अधिक सुविधाजनक हो जाएगा। हमारे समाचार पत्रों के पन्नों पर हरक्यूलिस के रोमांच का पालन करें।