स्काला वाट: प्रसंस्करण वैकल्पिक मूल्य

पहले से ही नेटवर्क पर बहुत सारे परिचयात्मक स्तर के लेख हैं और हेरा पर कैसे स्काला पर लिखना शुरू करना है, और कार्यात्मक दृष्टिकोण की विशेषताओं का खुलासा करना है।

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

आइए तुच्छ मामले से शुरू करते हैं: आप जिस स्काला एपीआई का उपयोग कर रहे हैं, वह एक विकल्प है। आप इससे मूल्य प्राप्त करना और इसे संसाधित करना चाहते हैं। जावा प्रोग्रामर इसे इस तरह लिखेंगे:

val optionalValue = service.readValue() if(optionalValue.isDefined) { //    optionalValue != None val value = optionalValue.get processValue(value) } else { throw new IllegalArgumentException("No value!") } 

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

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

 for(value <- service.readValue()) { processValue(value) } 

दूसरा तब है जब आपको दोनों मामलों को संभालने की जरूरत है। तब पैटर्न मिलान का उपयोग करने की अनुशंसा की जाती है:

 service.readValue() match { case Some(value) => processValue(value) case None => throw new IllegalArgumentException("No value!") } 

कृपया ध्यान दें कि प्रत्येक विकल्प वर्णित नुकसान से रहित है।

चलिए जारी रखते हैं। एक मान प्राप्त करना अक्सर अपवाद हैंडलिंग से जुड़ा होता है, और अक्सर ऐसे निर्माण पैदा होते हैं:

 var value: Type = null try { value = parse(receiveValue()) } catch { case e: SomeException => value = defaultValue } 

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

 val value = try { parse(receiveValue()) } catch { case e: SomeException => defaultValue } 

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

 var value: Option[Type] = null try { value = Some(parse(receiveValue())) } catch { case e: SomeException => value = None } 

वैसे, एक दिलचस्प विशेषता है: यदि पार्स, अचानक, भगवान न करे, अशक्त हो, जो हो सकता है, तो हम कुछ (शून्य) प्राप्त करेंगे, और कोई नहीं, जिसे आप उम्मीद करेंगे, इसलिए, कम से कम, आपको करना होगा विकल्प लिखना होगा (पार्स (प्राप्तव्यू) ()), और इससे भी बेहतर, मानक पैकेज scala.util.control.Exception._ का उपयोग करें:

 val value = catching(classOf[SomeException]).opt({ parse(receiveValue()) }).getOrElse(defaultValue) 

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

 list.map(_.optionalField).filterNot(_ == None).map(_.get) 

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

 list.map(_.optionalField).flatten 

क्या सुरक्षित रूप से कम किया जा सकता है:

 list.flatMap(_.optionalField) 

यह पहले से ही महान है!

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

 iterable.map(value => value match { case Some(value) => whenValue(value) case None => whenNothing() }) 

यह बहुत साफ है, लेकिन क्योंकि मानचित्र विधि एक फ़ंक्शन को स्वीकार करती है और जिस तरह से हम स्काला में आंशिक कार्य को परिभाषित करते हैं, हम और भी सुरुचिपूर्ण ढंग से लिख सकते हैं:

 iterable.map({ case Some(value) => whenValue(value) case None => whenNothing() }) 

वैसे, एक अन्य विशेषता मानचित्र के कार्यों के हस्तांतरण के साथ जुड़ी हुई है। कभी-कभी आप कोड देख सकते हैं:

 iterable.map(function(_)) 

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

 iterable.map(function) 

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

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