एकाधिक प्रश्नों के साथ कैसे काम करें। रचना, Reducer, FP

हाय, हैब्र। मेरा नाम मैक्सिम है, मैं FINCH में एक iOS डेवलपर हूं। आज मैं आपको कार्यात्मक प्रोग्रामिंग का उपयोग करने की कुछ प्रथाओं को दिखाऊंगा जिन्हें हमने अपने विभाग में विकसित किया है।

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

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

एकाधिक क्वेरी समस्या

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

कभी-कभी मैं कुछ लिख सकता था:

networkClient.sendRequest(request1) { result in switch result { case .success(let response1): // ... self.networkClient.sendRequest(request2) { result in // ... switch result { case .success(let response2): // ...  -     response self.networkClient.sendRequest(request3) { result in switch result { case .success(let response3): // ...  -     completion(Result.success(response3)) case .failure(let error): completion(Result.failure(.description(error))) } } case .failure(let error): completionHandler(Result.failure(.description(error))) } } case .failure(let error): completionHandler(Result.failure(.description(error))) } } 

घृणित, सही? लेकिन यह वास्तविकता है जिसके साथ मुझे काम करने की आवश्यकता थी।

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

 func obtainUserStatus(completion: @escaping (Result<AuthResponse>) -> Void) { let endpoint= AuthEndpoint.loginRoute networkService.request(endpoint: endpoint, cachingEnabled: false) { [weak self] (result: Result<LoginRouteResponse>) in switch result { case .success(let response): self?.obtainLoginResponse(response: response, completion: completion) case .failure(let error): completion(.failure(error)) } } } private func obtainLoginResponse(_ response: LoginRouteResponse, completion: @escaping (Result<AuthResponse>) -> Void) { let endpoint= AuthEndpoint.login networkService.request(endpoint: endpoint, cachingEnabled: false) { [weak self] (result: Result<LoginResponse>) in switch result { case .success(let response): self?.obtainAuthResponse(response: response, completion: completion) case .failure(let error): completion(.failure(error)) } } private func obtainAuthResponse(_ response: LoginResponse, completion: @escaping (Result<AuthResponse>) -> Void) { let endpoint= AuthEndpoint.auth networkService.request(endpoint: endpoint, cachingEnabled: false) { (result: Result<AuthResponse>) in completion(result) } } 

यह देखा जा सकता है कि प्रत्येक निजी तरीकों में मुझे प्रॉक्सी करना है

 completion: @escaping (Result<AuthResponse>) -> Void 

और मुझे यह वास्तव में पसंद नहीं है।

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

रचना और Reducer

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

गणितीय दृष्टिकोण से रचना कुछ इस प्रकार है:

 func compose<A,B,C>(_ f: @escaping (A) -> B, and g: @escaping (B) -> C) -> (A) -> C { return { a in g(f(a)) } } 

ऐसे कार्य च और छ हैं जो आंतरिक रूप से आउटपुट और इनपुट मापदंडों को निर्दिष्ट करते हैं। हम इन इनपुट विधियों से किसी प्रकार का परिणामी व्यवहार प्राप्त करना चाहते हैं।

एक उदाहरण के रूप में, आप दो को बंद कर सकते हैं, जिनमें से एक इनपुट संख्या 1 से बढ़ाता है, और दूसरा खुद से गुणा करता है।

 let increment: (Int) -> Int = { value in return value + 1 } let multiply: (Int) -> Int = { value in return value * value } 

परिणामस्वरूप, हम इन दोनों कार्यों को लागू करना चाहते हैं:

 let result = compose(multiply, and: increment) result(10) //     101 

दुर्भाग्य से मेरा उदाहरण सहयोगी नहीं है
(यदि हम वेतन वृद्धि को बढ़ाते हैं और गुणा करते हैं, तो हमें 121 नंबर मिलता है), लेकिन अभी के लिए इस क्षण को छोड़ दें।

 let result = compose(increment, and: multiply) result(10) //     121 

पीएस मैं विशेष रूप से अपने उदाहरणों को सरल बनाने की कोशिश करता हूं ताकि यह यथासंभव स्पष्ट हो)

व्यवहार में, आपको अक्सर ऐसा कुछ करने की आवश्यकता होती है:

 let value: Int? = array .lazy .filter { $0 % 2 == 1 } .first(where: { $0 > 10 }) 

यह रचना है। हम इनपुट कार्रवाई सेट करते हैं और कुछ आउटपुट प्रभाव प्राप्त करते हैं। लेकिन यह सिर्फ कुछ वस्तुओं का जोड़ नहीं है - यह एक पूरे व्यवहार का जोड़ है।

और अब चलिए अधिक सारगर्भित सोचते हैं :)

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

लेकिन क्या होगा यदि आप एक ऐसी इकाई बनाएँ जो सिर्फ मेरे राज्य और क्रिया को एक साथ जोड़ती है?

तो हमें Reducer मिलता है

 struct Reducer<S, A> { let reduce: (S, A) -> S } 

हम कम विधि इनपुट के लिए वर्तमान स्थिति और कार्रवाई देंगे, और आउटपुट पर हमें एक नया राज्य मिलेगा, जिसे कम करने के लिए बनाया गया था।

हम इस संरचना का कई तरीकों से वर्णन कर सकते हैं: एक नए राज्य को परिभाषित करके, एक कार्यात्मक विधि का उपयोग करके या उत्परिवर्तनीय मॉडल का उपयोग करके।

 struct Reducer<S, A> { let reduce: (S, A) -> S } struct Reducer<S, A> { let reduce: (S) -> (A) -> S } struct Reducer<S, A> { let reduce: (inout S, A) -> Void } 

पहला विकल्प "क्लासिक" है।

दूसरा अधिक कार्यात्मक है। मुद्दा यह है कि हम राज्य नहीं लौटा रहे हैं, लेकिन एक तरीका है जो कार्रवाई करता है, जो पहले से ही बदले की स्थिति में है। यह अनिवार्य रूप से घट विधि की करी है।

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

रिड्यूसर लगाना

हम Reducer अवधारणा को मौजूदा कोड पर लागू करते हैं - एक RequestState बनाएं, फिर इसे प्रारंभ करें और इसे सेट करें।

 class RequestState { // MARK: - Private properties private let semaphore = DispatchSemaphore(value: 0) private let networkClient: NetworkClient = NetworkClientImp() // MARK: - Public methods func sendRequest<Response: Codable>(_ request: RequestProtocol, completion: ((Result<Response>) -> Void)?) { networkClient.sendRequest(request) { (result: Result<Response>) in completion?(result) self.semaphore.signal() } semaphore.wait() } } 

अनुरोधों के सिंक्रनाइज़ेशन के लिए मैंने DispatchSemaphore जोड़ा

आगे बढ़ो। अब हमें तीन अनुरोधों के साथ एक RequestAction बनाने की आवश्यकता है।

 enum RequestAction { case sendFirstRequest(FirstRequest) case sendSecondRequest(SecondRequest) case sendThirdRequest(ThirdRequest) } 

अब एक Reducer बनाएं जिसमें एक RequestState और RequestAction हो। हम व्यवहार सेट करते हैं - हम पहले, दूसरे, तीसरे अनुरोध के साथ क्या करना चाहते हैं।

 let requestReducer = Reducer<RequestState, RequestAction> { state, action in switch action { case .sendFirstRequest(let request): state.sendRequest(request) { (result: Result<FirstResponse>) in // 1 Response } case .sendSecondRequest(let request): state.sendRequest(request) { (result: Result<SecondResponse>) in // 2 Response } case .sendThirdRequest(let request): state.sendRequest(request) { (result: Result<ThirdResponse>) in // 3 Response } } } 

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

 var state = RequestState() requestReducer.reduce(&state, .sendFirstRequest(FirstRequest())) requestReducer.reduce(&state, .sendSecondRequest(SecondRequest())) requestReducer.reduce(&state, .sendThirdRequest(ThirdRequest())) 

निष्कर्ष

नई चीजें सीखने से डरो मत और कार्यात्मक प्रोग्रामिंग सीखने से डरो मत। मुझे लगता है कि सबसे अच्छे अभ्यास प्रौद्योगिकी के चौराहे पर हैं। विभिन्न प्रोग्रामिंग प्रतिमानों से बेहतर संयोजन और लेने की कोशिश करें।

यदि कोई गैर-तुच्छ कार्य है, तो इसे एक अलग कोण से देखने के लिए समझ में आता है।