🦐 🤪 🔥 प्रोटोकॉल ओरिएंटेड प्रोग्रामिंग, भाग 3 🏈 ⏫ 👩🏾‍🚒

प्रोटोकॉल उन्मुख प्रोग्रामिंग पर अंतिम लेख।

इस भाग में, हम देखेंगे कि सामान्य प्रकार के चर कैसे संग्रहीत और प्रतिलिपि किए जाते हैं और उनके साथ प्रेषण विधि कैसे काम करती है।

अनसर्डेड संस्करण

protocol Drawable { func draw() } func drawACopy(local: Drawable) { local.draw() } let line = Line() drawACopy(line) let point = Point() drawACopy(point)

बहुत ही सरल कोड। drawACopy ड्रा करने योग्य प्रकार का एक पैरामीटर लेता है और इसकी ड्रा विधि कहता है - वह सब।

सामान्यीकृत संस्करण

आइए ऊपर दिए गए कोड के सामान्यीकृत संस्करण को देखें:

 func drawACopy<T: Drawable>(local: T) { local.draw() } ...

लगता है कुछ भी नहीं बदला है। हम अभी भी केवल drawACopy संस्करण के रूप में drawACopy फ़ंक्शन को कॉल कर सकते हैं, और अधिक कुछ नहीं, लेकिन हुड के तहत हमेशा की तरह सबसे दिलचस्प।
सामान्यीकृत कोड में दो महत्वपूर्ण विशेषताएं हैं:

स्थैतिक बहुरूपता (पैरामीट्रिक के रूप में भी जाना जाता है)
कॉल के संदर्भ में परिभाषित और अद्वितीय प्रकार (सामान्य प्रकार टी को संकलन समय पर परिभाषित किया गया है)

एक उदाहरण के साथ इस पर विचार करें:

 func foo<T: Drawable>(local: T) { bar(local) } func bar<T: Drawable>(local: T) { ... } let point = Point(...) foo(point)

सबसे दिलचस्प हिस्सा तब शुरू होता है जब हम foo फ़ंक्शन कहते हैं। कंपाइलर बिल्कुल वैरिएबल point के प्रकार को जानता है - यह सिर्फ पॉइंट है। इसके अलावा, T: foo फंक्शन में ड्रॉएबल टाइप को कंपाइलर द्वारा उस समय से खुलकर देखा जा सकता है, जब हम इस फंक्शन के लिए जाने जाने वाले पॉइंट टाइप का वैरिएबल पास करते हैं: T = प्वाइंट। सभी प्रकार के संकलन समय पर जाने जाते हैं और कंपाइलर अपने सभी अद्भुत अनुकूलन कर सकता है - सबसे महत्वपूर्ण बात यह है कि foo कॉल को इनलाइन करना।

 This: ```swift let point = Point(...) foo<T = Point>(point) Becomes this: ```swift bar<T = Point>(point)

कंपाइलर इसके कार्यान्वयन के साथ foo कॉल को एम्बेड करता है और सामान्य प्रकार के टी: ड्रॉएबल बार को भी प्रदर्शित करता है। दूसरे शब्दों में, संकलक पहले टाइप विधि = कॉल के साथ foo विधि को कॉल एम्बेड करता है, फिर यह पिछले एम्बेडिंग के परिणाम को टाइप करता है - टाइप टी = प्वाइंट के साथ बार विधि।

जेनेरिक विधियों का कार्यान्वयन

 func drawACopy<T: Drawable>(local: T) { local.draw() } drawACopy(Point(...))

आंतरिक रूप से, drawACopy स्विफ्ट एक प्रोटोकॉल-विधि तालिका (जिसमें टी पद्धति के सभी कार्यान्वयन शामिल हैं) और एक जीवन चक्र तालिका (जिसमें टी उदाहरण के लिए सभी जीवन चक्र विधियां शामिल हैं) का उपयोग करता है। स्यूडोकोड में, यह इस तरह दिखता है:

 func drawACopy<T: Drawable>(local: T, pwt: T.PWT, vwt: T.VWT) {...} drawACopy(Point(...), Point.pwt, Point.vwt)

VWT और PWT टी में संबद्ध प्रकार (संबद्धता) हैं - टाइप उपनाम (टाइपेलियस), केवल बेहतर। Point.pwt और Point.vwt स्थिर गुण हैं।

चूंकि हमारे उदाहरण में टी प्वाइंट है, टी को अच्छी तरह से परिभाषित किया गया है, इसलिए, कंटेनर के निर्माण की आवश्यकता नहीं है। पिछले drawACopy संस्करण में drawACopy (स्थानीय: drawACopy ), एक अस्तित्ववान कंटेनर का निर्माण आवश्यकतानुसार किया गया था - हमने लेख के दूसरे भाग में इसकी जांच की।

एक तर्क के निर्माण के कारण कार्यों में एक जीवनचक्र तालिका की आवश्यकता होती है। जैसा कि हम जानते हैं, स्विफ्ट में तर्कों को लिंक के माध्यम से नहीं, मूल्यों के माध्यम से पारित किया जाता है, इसलिए, उन्हें कॉपी किया जाना चाहिए, और इस तर्क के लिए प्रतिलिपि विधि इस तर्क की तरह जीवनचक्र तालिका से संबंधित है। वहाँ भी अन्य जीवनचक्र विधियाँ हैं: आवंटित, विनाश और डीललोकेट।

जेनेरिक कोड मापदंडों के लिए विधियों के उपयोग के कारण सामान्य कार्यों में एक जीवन चक्र तालिका की आवश्यकता होती है।

सामान्यीकृत या गैर-सामान्यीकृत?

क्या यह सही है कि जेनेरिक प्रकारों का उपयोग करने से केवल प्रोटोकॉल प्रकारों का उपयोग करने की तुलना में कोड निष्पादन तेजी से होता है? क्या सामान्यीकृत फ़ंक्शन func foo<T: Drawable>(arg: T) अपने प्रोटोकॉल जैसे समकक्ष fun foo(arg: Drawable) से अधिक तेज है?

हमने देखा कि जेनेरिक कोड बहुरूपता का अधिक स्थिर रूप देता है। इसमें कंपाइलर ऑप्टिमाइज़ेशन भी शामिल है, जिसे "जेनेरिक कोड स्पेशलाइज़ेशन" कहा जाता है। आइए देखें:

फिर से हमारे पास एक ही कोड है:

 func drawACopy<T: Drawable>(local: T) { local.draw() } drawACopy(Point(...)) drawACopt(Line(...))

एक जेनेरिक फ़ंक्शन का विशेषज्ञता इस फ़ंक्शन के विशिष्ट जेनेरिक प्रकारों के साथ एक प्रतिलिपि बनाता है। उदाहरण के लिए, अगर हम drawACopy को टाइप प्वाइंट के एक चर के साथ कहते हैं, तो कंपाइलर इस फ़ंक्शन का एक विशेष संस्करण बनाएगा - drawACopyOfPoint (स्थानीय: प्वाइंट), और हम प्राप्त करते हैं:

 func drawACopyOfPoint(local: Point) { local.draw() } func drawACopyOfLine(local: Line) { local.draw() } drawACopy(Point(...)) drawACopt(Line(...))

इससे पहले क्रूड कंपाइलर ऑप्टिमाइज़ेशन से क्या घट सकता है:

 Point(...).draw() Line(...).draw()

ये सभी ट्रिक उपलब्ध हैं क्योंकि जेनेरिक फ़ंक्शंस को केवल तभी कहा जा सकता है जब सभी जेनेरिक प्रकारों को परिभाषित किया जाता है - drawACopy विधि में drawACopy जेनेरिक प्रकार (टी) को अच्छी तरह से परिभाषित किया गया है।

सामान्य संग्रहीत गुण

एक साधारण संरचना युग्म पर विचार करें:

 struct Pair { let fst: Drawable let snd: Drawable } let pair = Pair(fst: Line(...), snd: Line(...))

जब हम इस तरह से इसका उपयोग करते हैं, तो हमें ढेर पर 2 आवंटन मिलते हैं (इस परिदृश्य में सटीक मेमोरी की स्थिति दूसरे भाग में वर्णित की गई थी), लेकिन हम एक सामान्यीकृत कोड की मदद से इससे बच सकते हैं।

पेयर का जेनेरिक संस्करण इस तरह दिखता है:

 struct Pair<T: Drawable> { let fst: T let snd: T }

जिस समय से टी को सामान्यीकृत संस्करण में परिभाषित किया जाता है, संपत्ति प्रकार fst और snd समान होते हैं और इन्हें परिभाषित भी किया जाता है। चूंकि प्रकार परिभाषित किया गया है, इसलिए कंपाइलर इन दो गुणों के लिए मेमोरी की एक विशेष मात्रा आवंटित कर सकता है - fst और snd ।

मेमोरी की विशेष मात्रा के बारे में अधिक विस्तार से:

जब हम Pair fst संस्करण के साथ काम कर रहे हैं, तो संपत्ति प्रकार fst और snd fst हैं। कोई भी प्रकार ड्राबल के अनुरूप हो सकता है, भले ही वह 10 केबी मेमोरी का हो। यही है, स्विफ्ट इस प्रकार के आकार के बारे में एक निष्कर्ष निकालने में सक्षम नहीं होगा और एक सार्वभौमिक स्मृति स्थान का उपयोग करेगा, उदाहरण के लिए, एक अस्तित्वगत कंटेनर। इस कंटेनर में किसी भी प्रकार का भंडारण किया जा सकता है। जेनेरिक कोड के मामले में, प्रकार अच्छी तरह से मान्यता प्राप्त है, गुणों का वास्तविक आकार भी पहचानने योग्य है, और स्विफ्ट एक विशेष मेमोरी स्थान बना सकता है। उदाहरण के लिए (सामान्यीकृत संस्करण):

 let pair = Pair(Point(...), Point(...))

टाइप टी अब प्वाइंट है। प्वाइंट एन मेमोरी के एन बाइट्स लेता है और पेयर में हमें उनमें से दो मिलते हैं। स्विफ्ट मेमोरी की 2 * N राशि आवंटित करेगा और वहां pair बनाएगा।

इसलिए, जोड़ी के सामान्यीकृत संस्करण के साथ, हमें ढेर पर अनावश्यक आवंटन से छुटकारा मिलता है, क्योंकि प्रकार आसानी से पहचानने योग्य हैं और विशेष रूप से स्थित हो सकते हैं - सार्वभौमिक मेमोरी टेम्प्लेट बनाने की आवश्यकता के बिना, क्योंकि सब कुछ ज्ञात है।

निष्कर्ष

1. विशिष्ट जेनरिक कोड - मूल्य प्रकार

सबसे अच्छी निष्पादन गति है, क्योंकि:

नकल करते समय कोई आवंटन नहीं
जेनेरिक कोड - आप एक विशेष प्रकार के लिए एक फ़ंक्शन लिखते हैं
कोई संदर्भ गिनती नहीं
स्थैतिक विधि प्रेषण

2. विशिष्टीकृत सामान्यीकृत कोड - संदर्भ प्रकार

इसकी एक औसत निष्पादन गति है, क्योंकि:

तत्काल होने पर प्रति ढेर आवंटन
एक संदर्भ गणना है
आभासी तालिका के माध्यम से गतिशील विधि प्रस्तुत करना

3. गैर-विशिष्ट सामान्यीकृत कोड - छोटे मूल्य

कोई ढेर आवंटन नहीं - मूल्य को अस्तित्व के कंटेनर के मूल्य बफर में रखा गया है
कोई संदर्भ गिनती नहीं (क्योंकि ढेर पर कुछ भी नहीं रखा गया है)
प्रोटोकॉल-विधि तालिका के माध्यम से भेजने वाली गतिशील विधि

4. गैर-विशिष्ट सामान्यीकृत कोड - बड़े मूल्य

हीप पर प्लेसमेंट - मान बफर में रखा गया है
एक संदर्भ गणना है
प्रोटोकॉल-विधि तालिका के माध्यम से गतिशील प्रेषण

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

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

संरचनात्मक प्रकार - अर्थ का शब्दार्थ
वर्ग के प्रकार - पहचान
सामान्यीकृत कोड - स्थैतिक बहुरूपता
प्रोटोकॉल प्रकार - गतिशील बहुरूपता

बड़े मूल्यों के साथ काम करने के लिए अप्रत्यक्ष भंडारण का उपयोग करें।

और मत भूलो - सही उपकरण चुनने की जिम्मेदारी आपकी है।
इस विषय पर ध्यान देने के लिए आपका धन्यवाद। हमें उम्मीद है कि इन लेखों ने आपकी मदद की है और दिलचस्प थे।

सौभाग्य है

प्रोटोकॉल ओरिएंटेड प्रोग्रामिंग, भाग 3