मोबाइल का विकास। स्विफ्ट: प्रोटोकॉल का रहस्य

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



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

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

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

स्विफ्ट में प्रोटोकॉल क्या हैं?

मोबाइल डेवलपर्स अक्सर प्रोटोकॉल का उपयोग किए बिना करते हैं, लेकिन वे कुछ संस्थाओं के साथ काम करने की क्षमता खो देते हैं। यदि हम स्विफ्ट में प्रोटोकॉल की मुख्य विशेषताओं को उजागर करते हैं, तो हमें निम्नलिखित 7 बिंदु मिलते हैं:

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

जैसा कि आप जानते हैं, स्विफ्ट में सभी सरल प्रकार (स्ट्रिंग, इंट) संरचनाएं हैं। स्विफ्ट मानक पुस्तकालय में, यह, उदाहरण के लिए, इस तरह दिखता है:

public struct Int: FixedWidthInteger, SignedInteger { 

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

 public struct Dictionary<Key, Value> where Key: Hashable { 

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

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

स्विफ्ट में प्रोटोकॉल का कार्यान्वयन काफी सरल है। सिंटैक्स का अर्थ है एक नाम, कई विधियाँ, और पैरामीटर (चर) जो इसमें शामिल होंगे।

 protocol Employee { func work() var hours: Int { get } } 

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

 extension Employee { func work() { print ("do my job") } } 

आप वैरिएबल के साथ भी ऐसा कर सकते हैं।

 extension Employee { var hours: Int { return 8 } } 

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

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

या यदि हम कुछ वर्ग या संरचना लेते हैं और प्रोटोकॉल को लागू करते हैं, तो हम इसमें सामान्य चर का उपयोग कर सकते हैं:

 class Programmer { var hours: Int = 24 } extension Programmer: Employee { } 

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

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

 extension Array where Element: Equatable {   var areAllElementsEqualToEachOther: Bool {       if isEmpty {           return false       }       var previousElement = self[0]       for (index, element) in self.enumerated() where index > 0 {           if element != previousElement {               return false           }           previousElement = element       }       return true   } } [1,1,1,1].areAllElementsEqualToEachOther 

एक छोटी सी टिप्पणी। प्रोटोकॉल में चर और कार्य स्थिर हो सकते हैं।

@ Objc का उपयोग करना

इस मामले में आपको मुख्य बात यह जानना जरूरी है कि @ objc स्विफ्ट प्रोटोकॉल ऑब्जेक्टिव-सी कोड में दिखाई दे रहे हैं। सख्ती से, इस "जादू शब्द" के लिए @ objc मौजूद है। लेकिन बाकी सब कुछ अपरिवर्तित रहता है

 @objc protocol Typable {   @objc optional func test()   func type() } extension Typable {   func test() {       print("Extension test")   }   func type() {       print("Extension type")   } } class Typewriter: Typable {   func test() {       print("test")   }   func type() {       print("type")   } } 

इस प्रकार के प्रोटोकॉल केवल कक्षाओं द्वारा विरासत में प्राप्त किए जा सकते हैं। लिस्टिंग और संरचनाओं के लिए यह नहीं किया जा सकता है।

वही एकमात्र रास्ता है।

 @objc protocol Dummy { } class DummyClass: Dummy { } 

यह ध्यान देने योग्य है कि इस मामले में वैकल्पिक कार्यों (@obj वैकल्पिक कवक) को परिभाषित करना संभव हो जाता है, जो, यदि वांछित है, तो लागू नहीं किया जा सकता है, जैसा कि पिछले उदाहरण में परीक्षण () फ़ंक्शन के लिए है। लेकिन सशर्त रूप से वैकल्पिक कार्यों को खाली कार्यान्वयन के साथ प्रोटोकॉल का विस्तार करके भी लागू किया जा सकता है।

 protocol Dummy { func ohPlease() } extension Dummy { func ohPlease() { } } 

टाइप इनहेरिटेंस

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

वैसे, इस संदर्भ में एक बहुत ही दिलचस्प समस्या दिखाई देती है। मान लीजिए कि हमारे पास एक प्रोटोकॉल है। कुछ क्लास है। और वर्ग प्रोटोकॉल को लागू करता है, और इसमें एक कार्य () फ़ंक्शन होता है। यदि हमारे पास प्रोटोकॉल का विस्तार है, तो एक कार्य () विधि भी होती है। विधि कहे जाने पर किसे कहा जाएगा?

 protocol Person {    func work() } extension Person {   func work() {       print("Person")   } } class Employee { } extension Employee: Person {   func work() {       print("Employee")   } } 

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

 protocol Person { //     func work() //      } extension Person {   func work() {       print("Person")   } } class Employee { } extension Employee: Person {   func work() {       print("Employee")   } } let person: Person = Employee() person.work() //output: Person 

जेनेरिक प्रोटोकॉल

स्विफ्ट में संबद्ध प्रकार के साथ जेनेरिक प्रोटोकॉल भी हैं जो आपको टाइप वेरिएबल्स को परिभाषित करने की अनुमति देते हैं। इस तरह के प्रोटोकॉल को अतिरिक्त शर्तों को सौंपा जा सकता है जो साहचर्य प्रकारों पर लगाए जाते हैं। इनमें से कई प्रोटोकॉल आपको एप्लिकेशन आर्किटेक्चर के गठन के लिए आवश्यक जटिल संरचनाओं का निर्माण करने की अनुमति देते हैं।

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

 protocol Printer {   associatedtype PrintableClass: Hashable   func printSome(printable: PrintableClass) } extension Printer {   func printSome(printable: PrintableClass) {       print(printable.hashValue)   } } class TheIntPrinter: Printer {   typealias PrintableClass = Int } let intPrinter = TheIntPrinter() intPrinter.printSome(printable: 0) let intPrinterError: Printer = TheIntPrinter() //   

यह याद रखना चाहिए कि जेनेरिक प्रोटोकॉल में उच्च स्तर की अमूर्तता होती है। इसलिए, अनुप्रयोगों में स्वयं, वे निरर्थक हो सकते हैं। लेकिन एक ही समय में, पुस्तकालयों की प्रोग्रामिंग करते समय जेनेरिक प्रोटोकॉल का उपयोग किया जाता है।

वर्ग प्रोटोकॉल

स्विफ्ट में क्लास-बाउंड प्रोटोकॉल भी हैं। उनका वर्णन करने के लिए दो प्रकार के वाक्यविन्यास का उपयोग किया जाता है।

 protocol Employee: AnyObject { } 

या

 protocol Employee: class { } 

भाषा के डेवलपर्स के अनुसार, इन सिंटैक्स का उपयोग करना समतुल्य है, लेकिन क्लास कीवर्ड का उपयोग केवल इस जगह में किया जाता है, AnyObject के विपरीत, जो एक प्रोटोकॉल है।

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

 protocol Handler: class {} class Presenter: Handler { weak var renderer: Renderer?  } protocol Renderer {} class View: Renderer { } 

नमक क्या है?

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

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

 protocol Handler {} class Presenter: Handler { var renderer: Renderer? } protocol Renderer {} class View: Renderer { var handler: Handler? } 

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

 protocol TableDelegate: class {} class Table {   weak var tableDelegate: TableDelegate? } 

एक अन्य उदाहरण जहां क्लास प्रोटोकॉल का उपयोग किया जाना चाहिए, यह एक स्पष्ट संकेत है कि ऑब्जेक्ट को संदर्भ द्वारा पारित किया गया है।

एकाधिक विधि वंशानुक्रम और प्रेषण

जैसा कि लेख की शुरुआत में कहा गया है, प्रोटोकॉल कई बार विरासत में मिल सकते हैं। वह है,

 protocol Pet {   func waitingForItsOwner() } protocol Sleeper {   func sleepOnAChair() } class Kitty: Pet, Sleeper {   func eat() {       print("yammy")   }   func waitingForItsOwner() {       print("looking at the door")   }   func sleepOnAChair() {       print("dreams")   } } 

यह उपयोगी है, लेकिन यहां क्या नुकसान छिपे हुए हैं? बात यह है कि कठिनाइयों, कम से कम पहली नज़र में, विधियों के प्रेषण (विधि प्रेषण) के कारण उत्पन्न होती हैं। सरल शब्दों में, यह स्पष्ट नहीं हो सकता है कि किस विधि को कहा जाएगा - माता-पिता या वर्तमान प्रकार से।

ऊपर, हमने पहले से ही इस विषय को कवर किया है कि कोड कैसे काम करता है; यह वर्ग विधि को कॉल करता है। जैसी कि उम्मीद थी।

 protocol Pet {   func waitingForItsOwner() } extension Pet { func waitingForItsOwner() { print("Pet is looking at the door") } } class Kitty: Pet { func waitingForItsOwner() { print("Kitty is looking at the door") } } let kitty: Pet = Kitty() kitty.waitingForItsOwner() // Output: Kitty is looking at the door 

लेकिन यदि आप प्रोटोकॉल परिभाषा से विधि हस्ताक्षर को हटाने की कोशिश करते हैं, तो "जादू" होता है। तथ्य की बात के रूप में, यह साक्षात्कार का एक प्रश्न है: "किसी प्रोटोकॉल से किसी फ़ंक्शन को कैसे बनाया जाए?"

 protocol Pet { } extension Pet { func waitingForItsOwner() { print("Pet is looking at the door") } } class Kitty: Pet { func waitingForItsOwner() { print("Kitty is looking at the door") } } let kitty: Pet = Kitty() kitty.waitingForItsOwner() // Output: Pet is looking at the door 

लेकिन यदि आप एक प्रोटोकॉल के रूप में नहीं, बल्कि एक वर्ग के रूप में चर का उपयोग करते हैं, तो सब कुछ ठीक हो जाएगा।

 protocol Pet { } extension Pet { func waitingForItsOwner() { print("Pet is looking at the door") } } class Kitty: Pet { func waitingForItsOwner() { print("Kitty is looking at the door") } } let kitty = Kitty() kitty.waitingForItsOwner() // Output: Kitty is looking at the door 

प्रोटोकॉल को बढ़ाते समय यह सभी स्टैटिक प्रेषण विधियों के बारे में है। और इस पर ध्यान दिया जाना चाहिए। और यहाँ कई विरासत है? लेकिन इसके साथ: यदि आप कार्यान्वित कार्यों के साथ दो प्रोटोकॉल लेते हैं, तो ऐसा कोड काम नहीं करेगा। कार्य को निष्पादित करने के लिए, आपको स्पष्ट रूप से वांछित प्रोटोकॉल में डालना होगा। इस तरह C ++ से कई विरासत की गूंज है।

 protocol Pet {   func waitingForItsOwner() } extension Pet {   func yawn() { print ("Pet yawns") } } protocol Sleeper {   func sleepOnAChair() } extension Sleeper {   func yawn() { print ("Sleeper yawns") } } class Kitty: Pet, Sleeper {   func eat() {       print("yammy")   }   func waitingForItsOwner() {       print("looking at the door")   }   func sleepOnAChair() {       print("dreams")   } } let kitty = Kitty() kitty.yawn() 

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

 protocol Pet {   func waitingForItsOwner() } extension Pet {   func yawn() { print ("Pet yawns") } } protocol Cat {   func walk() } extension Cat {   func yawn() { print ("Cat yawns") } } class Kitty:Cat {   func eat() {       print("yammy")   }   func waitingForItsOwner() {       print("looking at the door")   }   func sleepOnAChair() {       print("dreams")   } } let kitty = Kitty() 

पिछले दो उदाहरण बताते हैं कि यह वर्गों के साथ प्रोटोकॉल को पूरी तरह से बदलने के लायक नहीं है। आप स्थिर शेड्यूलिंग में भ्रमित हो सकते हैं।

जेनरिक और प्रोटोकॉल

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

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

 protocol Property { } protocol PropertyConnection { } class SomeProperty { } extension SomeProperty: Property { } extension SomeProperty: PropertyConnection { } protocol ViewConfigurator { } protocol Connection { } class Configurator<T> where T: Property {   var property: T   init(property: T) {       self.property = property   } } extension Configurator: ViewConfigurator { } extension Configurator: Connection where T: PropertyConnection { } [Configurator(property: SomeProperty()) as ViewConfigurator]   .forEach { configurator in   if let connection = configurator as? Connection {       print(connection)   } } 

स्विफ्ट 4.1 के लिए, निम्नलिखित प्रदर्शित होता है:

 warning: Swift runtime does not yet support dynamically querying conditional conformance ('__lldb_expr_1.Configurator<__lldb_expr_1.SomeProperty>': '__lldb_expr_1.Connection') 

जबकि स्विफ्ट 4.2 में सब कुछ उम्मीद के मुताबिक काम करता है:

 __lldb_expr_5.Configurator<__lldb_expr_5.SomeProperty> connection 

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

 protocol ObjectConfigurator { } protocol Property { } class FirstProperty: Property { } class SecondProperty: Property { } class Configurator<T> where T: Property {   var properties: T   init(properties: T) {       self.properties = properties   } } extension Configurator: ObjectConfigurator where T == FirstProperty { } //   : // Redundant conformance of 'Configurator<T>' to protocol 'ObjectConfigurator' extension Configurator: ObjectConfigurator where T == SecondProperty { } 

लेकिन, इन कठिनाइयों के बावजूद, जेनरिक में कनेक्शन के साथ काम करना काफी सुविधाजनक है।

संक्षेप में देना

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