प्रोटोकॉल उन्मुख प्रोग्रामिंग। भाग 1

चलो प्रोटोकॉल-उन्मुख प्रोग्रामिंग के विषय पर करीब से नज़र डालें। सुविधा के लिए, सामग्री को तीन भागों में विभाजित किया गया था।

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

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

ओओपी की समस्याएं और हमें पीओपी की आवश्यकता क्यों है

यह ज्ञात है कि ओओपी में कई तरह की कमजोरियां हैं जो कार्यक्रम के निष्पादन को "ओवरलोड" कर सकती हैं। सबसे स्पष्ट और सामान्य पर विचार करें:

1. आवंटन: ढेर या ढेर?
2. संदर्भ गिनती: कम या ज्यादा?
3. विधि प्रेषण: स्थिर या गतिशील?

1.1 आवंटन - ढेर

स्टैक एक काफी सरल और आदिम डेटा संरचना है। हम स्टैक (पुश) के शीर्ष पर रख सकते हैं, हम स्टैक (पॉप) के शीर्ष से ले सकते हैं। सरलता यह है कि यह सब हम इसके साथ कर सकते हैं।

सरलता के लिए, हम मान लें कि प्रत्येक स्टैक में एक चर (स्टैक पॉइंटर) है। इसका उपयोग स्टैक के शीर्ष को ट्रैक करने और पूर्णांक (पूर्णांक) को संग्रहीत करने के लिए किया जाता है। यह इस प्रकार है कि स्टैक के साथ संचालन की गति इस चर में पुन: लिखने वाले की गति के बराबर है।

पुश - स्टैक के शीर्ष पर डालें, स्टैक पॉइंटर बढ़ाएं;

पॉप - स्टैक पॉइंटर को कम करें।

मान प्रकार

आइए संरचनाओं (संरचना) का उपयोग करके स्विफ्ट में स्टैक ऑपरेशन के सिद्धांतों पर विचार करें।

स्विफ्ट में, मूल्य प्रकार संरचनाएं (संरचना) और गणना (एनम) हैं, और संदर्भ प्रकार वर्ग (वर्ग) और फ़ंक्शन / क्लोजर (फंक) हैं। मूल्य प्रकार स्टैक पर संग्रहीत किए जाते हैं, संदर्भ प्रकार हीप पर संग्रहीत होते हैं।

struct Point { var x, y: Double func draw() {...} } let point1 = Point(...) // (1) let point2 = point1 // (2) point2.x = 5 // (3) //  point1 //  point2 // (4) 

1. हम स्टैक पर पहली संरचना रखते हैं
2. पहले संरचना की सामग्री की प्रतिलिपि बनाएँ
3. दूसरी संरचना की स्मृति बदलें (पहला बरकरार है)
4. उपयोग का अंत। मुक्त स्मृति

1.2 आवंटन - ढेर

ढेर एक पेड़ की तरह डेटा संरचना है। ढेर कार्यान्वयन विषय यहां प्रभावित नहीं होगा, लेकिन हम इसे स्टैक के साथ तुलना करने की कोशिश करेंगे।

क्यों, यदि संभव हो, तो क्या यह ढेर के बजाय स्टैक का उपयोग करने के लायक है? यहाँ क्यों है:

• संदर्भ गिनती
• मुफ्त स्मृति प्रशासन और आवंटन के लिए इसकी खोज
• डीलक्लोकेशन के लिए मेमोरी फिर से लिखना

यह सब हीप का एक छोटा सा हिस्सा है जो ढेर का काम करता है और स्टैक की तुलना में इसे स्पष्ट रूप से कम करता है।

उदाहरण के लिए, जब हमें स्टैक पर मुफ्त मेमोरी की आवश्यकता होती है, तो हम केवल स्टैक-पॉइंटर का मूल्य लेते हैं और इसे बढ़ाते हैं (क्योंकि स्टैक में स्टैक-पॉइंटर के ऊपर की सब कुछ मुफ्त मेमोरी है) - ओ (1) एक ऑपरेशन है जो समय में निरंतर होता है।

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

यह भी ध्यान देने योग्य है कि मल्टीथ्रेडिंग मोड में हीप का उपयोग स्थिति को काफी बढ़ाता है, क्योंकि विभिन्न थ्रेड्स के लिए साझा संसाधन (मेमोरी) के सिंक्रनाइज़ेशन को सुनिश्चित करना आवश्यक है। यह ताले (सेमाफोर, स्पिनलॉक आदि) का उपयोग करके प्राप्त किया जाता है।

संदर्भ प्रकार

आइए देखें कि स्विफ्ट कक्षाओं का उपयोग करके कैसे काम करती है।

 class Point { var x, y: Double func draw() {...} } let point1 = Point(...) // (1) let point2 = point1 // (2) point2.x = 5 // (3) //  point1 //  point2 // (4) 

1. हीप पर क्लास बॉडी रखें। स्टैक पर इस बॉडी को पॉइंटर लगाएं।

1. कक्षा के शरीर को संदर्भित करने वाले पॉइंटर को कॉपी करें
2. हम एक वर्ग का एक शरीर बदलते हैं
3. उपयोग का अंत। मुक्त स्मृति

1.3 आवंटन - एक छोटा और "वास्तविक" उदाहरण

कुछ स्थितियों में, स्टैक का चयन न केवल मेमोरी हैंडलिंग को आसान बनाता है, बल्कि कोड की गुणवत्ता में भी सुधार करता है। एक उदाहरण पर विचार करें:

 enum Color { case red, green, blue } enum Orientation { case left, right } enum Tail { case none, tail, bubble } var cache: [String: UIImage] = [] func makeBalloon(_ color: Color, _ orientation: Orientation, _ tail: Tail) -> UIImage { let key = "\(color):\(orientation):\(tail)" if let image = cache[key] { return image } ... } 

यदि कैश शब्दकोश में कुंजी कुंजी के साथ एक मूल्य है, तो फ़ंक्शन केवल कैश्ड UIImage वापस कर देगा।

इस कोड की समस्याएं हैं:

एक अच्छा अभ्यास नहीं है कि स्ट्रिंग में एक कुंजी के रूप में स्ट्रिंग का उपयोग किया जाए, क्योंकि अंत में स्ट्रिंग "कुछ भी हो सकता है।"

स्ट्रिंग एक कॉपी-ऑन-राइट संरचना है, इसकी गतिशीलता को लागू करने के लिए, यह अपने सभी कैरेक्टर-एस को हीप पर संग्रहीत करता है। इस प्रकार, स्ट्रिंग एक संरचना है, और स्टैक में संग्रहीत किया जाता है, लेकिन यह अपने सभी सामग्रियों को हीप पर संग्रहीत करता है।

लाइन को बदलने की क्षमता प्रदान करने के लिए यह आवश्यक है (लाइन का हिस्सा निकालें, इस लाइन में एक नई लाइन जोड़ें)। यदि स्ट्रिंग के सभी पात्रों को स्टैक पर संग्रहीत किया गया था, तो ऐसे जोड़तोड़ असंभव होंगे। उदाहरण के लिए, C में, स्ट्रिंग्स स्थिर हैं, जिसका अर्थ है कि एक स्ट्रिंग का आकार रनटाइम में नहीं बढ़ाया जा सकता क्योंकि सभी सामग्री स्टैक में संग्रहीत होती है। कॉपी-ऑन-राइट और स्विफ्ट में लाइनों के अधिक विस्तृत पार्सिंग के लिए, कृपया यहां क्लिक करें ।

समाधान:

1. स्ट्रिंग के बजाय यहाँ स्पष्ट संरचना का उपयोग करें:

   
   

    struct Attributes: Hashable { var color: Color var orientation: Orientation var tail: Tail } 

   
   

2. शब्दकोश में बदलें:

   
   

    var cache: [Attributes: UIImage] = [] 

   
   

3. स्ट्रिंग से छुटकारा पाएं

   
   

    let key = Attributes(color: color, orientation: orientation, tail: tail) 

   
   

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

फैसला: ढेर ढेर की तुलना में बहुत आसान और तेज है - ज्यादातर स्थितियों के लिए विकल्प स्पष्ट है।

2. संदर्भ गणना

किस लिए?

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

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

स्टैक: मुफ्त मेमोरी और फ्रीइंग यूज्ड मेमोरी - स्टैक-पॉइंटर ऑपरेशन का पता लगाना

ढेर: मुफ्त मेमोरी और उपयोग की जाने वाली मेमोरी को फ्रीज़ करना - ट्री सर्च एल्गोरिथ्म और रेफरेंस काउंटिंग।

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

छद्म कोड

गिनती को कैसे काम करता है, यह प्रदर्शित करने के लिए छद्मकोश के एक छोटे से टुकड़े पर विचार करें:

 class Point { var refCount: Int var x, y: Double func draw() {...} init(...) { ... self.refCount = 1 } } let point1 = Point(x: 0, y: 0) let point2 = point1 retain(point2) // retain() -  refCount  1    point2.x = 5 //  `point1` release(point1) // release() -  refCount  1 //  `point2` release(point2) 

struct

संरचनाओं के साथ काम करते समय, संदर्भ गिनती जैसी एक तंत्र की आवश्यकता नहीं है:

1. संरचना ढेर पर संग्रहीत नहीं है
2. संरचना - असाइनमेंट पर कॉपी की गई, इसलिए, कोई संदर्भ नहीं

लिंक कॉपी करें

फिर, संरचना और स्विफ्ट के किसी भी अन्य प्रकार को असाइनमेंट पर कॉपी किया जाता है। यदि संरचना अपने आप में लिंक संग्रहीत करती है, तो उन्हें भी कॉपी किया जाएगा:

 struct Label { let text: String let font: UIFont ... init() { ... text.refCount = 1 font.refCount = 1 } } let label = Label(text: "Hi", font: font) let label2 = label retain(label2.text._storage) //    `String`       Heap retain(label2.font) //  label release(label.text._storage) release(label.font) //  label2 release(label2.text._storage) release(label2.font) 

हीप पर होस्ट किए गए लेबल और लेबल 2 साझा आम उदाहरण:

• पाठ सामग्री
• और फ़ॉन्ट

इस प्रकार, यदि संरचना अपने आप में लिंक करती है, तो इस संरचना को कॉपी करते समय, लिंक की संख्या दोगुनी हो जाती है, जो कि आवश्यक नहीं होने पर, प्रोग्राम के "आराम" को नकारात्मक रूप से प्रभावित करती है।

और फिर से "वास्तविक" उदाहरण:

 struct Attachment { let fileUrl: URL //   HEAP  let uuid: String //    HEAP  let mimeType: String //    HEAP  init?(fileUrl: URL, uuid: String, mimeType: String) { guard mimeType.isMimeType else { return nil } self.fileUrl = fileUrl self.uuid = uuid self.mimeType = mimeType } } 

इस संरचना की समस्याएं हैं:

1. 3 ढेर आवंटन
2. क्योंकि स्ट्रिंग कोई भी स्ट्रिंग हो सकती है, सुरक्षा और कोड स्पष्टता प्रभावित होती है।

इसी समय, uuid और mimeType सख्ती से परिभाषित चीजें हैं:

uuid एक प्रारूप स्ट्रिंग xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx है
mimeType एक प्रकार / एक्सटेंशन प्रारूप स्ट्रिंग है।

निर्णय

 let uuid: UUID // UUID  ,    Foundation 

माइम टाइप के मामले में, एनम ठीक काम करता है:

 enum MimeType { init?(rawValue: String) { switch rawValue { case "image/jpeg": self = .jpeg case "image/png": self = .png case "image/gif": self = .gif default: return nil } } case jpeg, png, gif } 

या बेहतर और आसान:

 enum MimeType: String { case jpeg = "image/jpeg" case png = "image/png" case gif = "image/gif" } 

और बदलने के लिए मत भूलना:

 let mimeType: MimeType 

3.1 विधि प्रेषण

• यह एक एल्गोरिथ्म है जो विधि कोड के लिए दिखता है जिसे कहा जाता था

इस तंत्र के कार्यान्वयन के बारे में बात करने से पहले, यह निर्धारित करना लायक है कि इस संदर्भ में "संदेश" और "विधि" क्या हैं:

• एक संदेश वह नाम है जिसे हम ऑब्जेक्ट पर भेजते हैं। नाम के साथ तर्क अभी भी भेजे जा सकते हैं।

 circle.draw(in: origin) 

संदेश ड्रा है - विधि का नाम। रिसीवर ऑब्जेक्ट एक सर्कल है। उत्पत्ति भी एक तर्क है।

• विधि वह कोड है जो संदेश के जवाब में दिया जाएगा।

फिर मेथड डिस्पैच एक एल्गोरिथ्म है जो यह तय करता है कि किस विधि को एक विशेष संदेश दिया जाना चाहिए।

विशेष रूप से स्विफ्ट में विधि डिस्पैच के बारे में

चूंकि हम मूल वर्ग से विरासत में प्राप्त कर सकते हैं और इसके तरीकों को ओवरराइड कर सकते हैं, इसलिए स्विफ्ट को ठीक से पता होना चाहिए कि इस पद्धति के कार्यान्वयन को एक विशिष्ट स्थिति में कहा जाना चाहिए।

 class Parent { func me() { print("parent") } } class Child: Parent { override func me() { print("child") } } 

उदाहरण के एक जोड़े बनाएँ और मुझे विधि कहते हैं:

 let parent = Parent() let child = Child() parent.me() // "parent" child.me() // "child" 

एक काफी स्पष्ट और सरल उदाहरण। और क्या हो अगर:

 let array: [Parent] = [Child(), Child(), Parent(), Child()] array.forEach { $0.me() // "child" "child" "parent" "child" } 

यह इतना स्पष्ट नहीं है और मुझे विधि के सही कार्यान्वयन का निर्धारण करने के लिए संसाधनों और एक निश्चित तंत्र की आवश्यकता है। संसाधन प्रोसेसर और रैम हैं। एक तंत्र एक विधि प्रेषण है।

दूसरे शब्दों में, मेथड डिस्पैच यह है कि प्रोग्राम कैसे निर्धारित करता है कि किस विधि को लागू करना है।

जब एक विधि को कोड में बुलाया जाता है, तो इसके कार्यान्वयन को जानना होगा। अगर वह जानी जाती है
संकलन के समय, फिर यह स्टेटिक डिस्पैच है। यदि कॉल (रनटाइम में, कोड निष्पादन के समय) से पहले कार्यान्वयन निर्धारित किया जाता है, तो यह डायनेमिक डिस्पैच है।

3.2 विधि प्रेषण - स्टेटिक डिस्पैच

सबसे इष्टतम, चूंकि:

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

3.3 विधि डिस्पैच - डायनेमिक डिस्पैच

सबसे इष्टतम नहीं है, क्योंकि:

1. कार्यक्रम के निष्पादन के समय विधि का सही कार्यान्वयन निर्धारित किया जाएगा, जिसके लिए संसाधनों और समय की आवश्यकता होती है
2. कोई संकलक अनुकूलन प्रश्न से बाहर नहीं हैं

३.४ विधि प्रेषण - शोधन

इनलाइनिंग जैसे एक तंत्र का उल्लेख किया गया था, लेकिन यह क्या है? एक उदाहरण पर विचार करें:

 struct Point { var x, y: Double func draw() { // Point.draw implementation } } func drawAPoint(_ param: Point) { param.draw() } let point = Point(x: 0, y: 0) drawAPoint(point) 

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

 let point = Point(x: 0, y: 0) point.draw() 

• तब बिंदु को हटा दिया जाता है। इस विधि के कार्यान्वयन के लिए भी जाना जाता है:

 let point = Point(x: 0, y: 0) // Point.draw implementation 

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

3.5 विधि प्रेषण - वंशानुक्रम-आधारित बहुरूपता

मुझे डायनेमिक डिस्पैच की आवश्यकता क्यों है? इसके बिना, बाल वर्गों द्वारा ओवरराइड किए गए तरीकों को परिभाषित करना असंभव है। बहुरूपता संभव नहीं होगा। एक उदाहरण पर विचार करें:

 class Drawable { func draw() {} } class Point: Drawable { var x, y: Double override func draw() { ... } } class Line: Drawable { var x1, y1, x2, y2: Double override func draw() { ... } } var drawables: [Drawable] for d in drawables { d.draw() } 

• ड्रॉइंग सरणी में प्वाइंट और लाइन हो सकते हैं
• सहज रूप से, स्टेटिक डिस्पैच यहां संभव नहीं है। घ में लूप के लिए लाइन, या शायद प्वाइंट हो सकता है। संकलक इसे निर्धारित नहीं कर सकता है, और प्रत्येक प्रकार का ड्रॉ का अपना कार्यान्वयन है

फिर डायनामिक डिस्पैच कैसे काम करता है? प्रत्येक वस्तु का एक प्रकार का क्षेत्र होता है। तो प्वाइंट (...)। टाइप प्वाइंट के बराबर होगा, और लाइन (...) टाइप लाइन के बराबर होगा। इसके अलावा कार्यक्रम की (स्थिर) मेमोरी में कहीं-कहीं एक टेबल (वर्चुअल-टेबल) है, जहां प्रत्येक प्रकार के लिए इसकी सूची के कार्यान्वयन के साथ एक सूची है।

ऑब्जेक्टिव-सी में, टाइप फील्ड को आइसा फील्ड के रूप में जाना जाता है। यह हर ऑब्जेक्टिव-सी ऑब्जेक्ट (NSObject) पर मौजूद है।

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

इस प्रकार, कंपाइलर इस कोड को बदल देगा:

 class Point: Drawable { ... override func draw(_ self: Point) { ... } } class Line: Drawable { ... override func draw(_ self: Line) { ... } } var drawables: [Drawable] for d in drawables { vtable[d.type].draw(d) } 

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

विधि प्रेषण - सारांश

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

OOP समस्याएं - सारांश

इस तरह के trifles पर ध्यान देना आवश्यक है:

1. एक उदाहरण बनाते समय: यह कहाँ स्थित होगा?
2. इस उदाहरण के साथ काम करते समय: लिंकिंग के काम को कैसे जोड़ा जाएगा?
3. एक विधि को बुलाते समय: इसे कैसे संसाधित किया जाएगा?

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

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