अतिरिक्त पाउंड से परियोजना को कैसे बचाया जाए

सभी को नमस्कार! मेरा नाम इल्या है, मैं Tinkoff.ru पर एक iOS डेवलपर हूं। इस लेख में मैं प्रोटोकॉल का उपयोग करके प्रस्तुति परत में कोड दोहराव को कम करने के बारे में बात करना चाहता हूं।

क्या समस्या है?

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

जीवन उदाहरण

दृष्टिकोण का उपयोग विभिन्न विभिन्न वास्तुशिल्प समाधानों के साथ किया जा सकता है, लेकिन मैं इसे एक उदाहरण के रूप में VIPER का उपयोग करने पर विचार करूंगा।

राउटर में सबसे आम विधि पर विचार करें - वह विधि जो स्क्रीन को बंद करती है:

func close() { self.transitionHandler.dismiss(animated: true, completion: nil) } 

यह कई राउटर्स में मौजूद है, और इसे केवल एक बार लिखना बेहतर है।

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

विरासत से बेहतर क्या है? बेशक रचना।

आप स्क्रीन को बंद करने वाली विधि के लिए एक अलग वर्ग बना सकते हैं और इसे प्रत्येक राउटर में जोड़ सकते हैं जिसमें इसकी आवश्यकता होती है:

 struct CloseRouter { let transitionHandler: UIViewController func close() { self.transitionHandler.dismiss(animated: true, completion: nil) } } 

हमें अभी भी राउटर के इनपुट प्रोटोकॉल में इस विधि को घोषित करना होगा और राउटर में ही इसे लागू करना होगा:

 protocol SomeRouterInput { func close() } class SomeRouter: SomeRouterInput { var transitionHandler: UIViewController! lazy var closeRouter = { CloseRouter(transitionHandler: self. transitionHandler) }() func close() { self.closeRouter.close() } } 

यह बहुत अधिक कोड निकला जो कॉल को नजदीकी विधि में सम्‍मिलित करता है। आलसी अच्छा प्रोग्रामर सराहना नहीं करेगा।

प्रोटोकॉल समाधान

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

यह इस तरह दिखेगा:

 protocol CloseRouterTrait { var transitionHandler: UIViewController! { get } func close() } extension CloseRouterTrait { func close() { self.transitionHandler.dismiss(animated: true, completion: nil) } } 

सवाल यह है कि प्रोटोकॉल के नाम पर शब्द विशेषता क्यों दिखाई देती है? यह सरल है - आप निर्दिष्ट कर सकते हैं कि यह प्रोटोकॉल विस्तार में अपने तरीकों को लागू करता है और इसकी कार्यक्षमता का विस्तार करने के लिए इसे किसी अन्य प्रकार के प्रवेश के रूप में उपयोग किया जाना चाहिए।

अब, देखते हैं कि इस तरह के एक प्रोटोकॉल का उपयोग कैसे दिखेगा:

 class SomeRouter: CloseRouterTrait { var transitionHandler: UIViewController! } 

हाँ, वह सब है। बहुत अच्छा लग रहा है :)। हमने राउटर के वर्ग में प्रोटोकॉल जोड़कर रचना प्राप्त की, एक भी अतिरिक्त पंक्ति नहीं लिखी और कोड का पुन: उपयोग करने का अवसर मिला।

इस दृष्टिकोण के बारे में क्या असामान्य है?

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

यहाँ मेरी सूची है:

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

VIPER से MVP तक

यदि आप प्रोटोकॉल के साथ इस दृष्टिकोण का उपयोग करने के लिए पूरी तरह से स्विच करते हैं, तो राउटर और इंटरेक्टर कक्षाएं कुछ इस तरह दिखाई देंगी:

 class SomeRouter: CloseRouterTrait, OtherRouterTrait { var transitionHandler: UIViewController! } class SomeInteractor: SomeInteractorTrait { var someService: SomeServiceInput! } 

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

कुछ इस तरह:

 class SomePresenter: CloseRouterTrait, OtherRouterTrait, SomeInteractorTrait, OtherInteractorTrait { var transitionHandler: UIViewController! var someService: SomeSericeInput! } 

हां, निर्भरता के रूप में राउटर और इंटरेक्टर को लागू करने की क्षमता खो गई है, लेकिन कुछ मामलों में यह मामला है।

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

बदलते व्यवहार

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

उदाहरण के लिए, नेटवर्क अनुरोध करने वाली विधि के साथ एक साधारण इंटरेक्टर लें:

 protocol SomeInteractorTrait { var someService: SomeServiceInput! { get } func performRequest(completion: @escaping (Response) -> Void) } extension SomeInteractorTrait { func performRequest(completion: @escaping (Response) -> Void) { someService.performRequest(completion) } } 

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

 protocol Mock {} extension SomeInteractorTrait where Self: Mock { func performRequest(completion: @escaping (Response) -> Void) { completion(MockResponse()) } } 

यहां, Mock प्रोटोकॉल को लागू करने वाले प्रकारों के लिए PerformRequest पद्धति के कार्यान्वयन को बदल दिया गया है। अब आपको वर्ग के लिए मॉक प्रोटोकॉल लागू करने की आवश्यकता है जो SomeInteractor को लागू करेगा:

 class SomePresenter: SomeInteractorTrait, Mock { // Implementation } 

SomePresenter वर्ग के लिए, PerformRequest पद्धति के कार्यान्वयन को विस्तार में स्थित कहा जाएगा, जहाँ स्वयं Mock प्रोटोकॉल को संतुष्ट करता है। यह मॉक प्रोटोकॉल को हटाने के लायक है और PerformRequest विधि के कार्यान्वयन को सामान्य एक्सटेंशन से SomeInteractor तक ले जाया जाएगा।

यदि आप इसे केवल परीक्षणों के लिए उपयोग करते हैं, तो परीक्षण लक्ष्य में कार्यान्वयन के प्रतिस्थापन से जुड़े सभी कोड रखना बेहतर है।

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

अंत में, यह इस दृष्टिकोण के पेशेवरों और विपक्षों पर ध्यान देने योग्य है और किन मामलों में, मेरी राय में, यह उपयोग करने के लायक है।

चलिए शुरुआत करते हैं:

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

इस दृष्टिकोण के सकारात्मक पहलू इस प्रकार हैं:

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

इस निर्णय पर विचार करना अच्छा है या नहीं यह सभी के लिए निजी मामला है। इस दृष्टिकोण के साथ हमारा अनुभव सकारात्मक और सुलझी हुई समस्याएं थीं।

वह सब है!