जावा 14: रिकॉर्ड्स का पूर्वावलोकन

जल्द ही, आगामी जावा 14 - रिकॉर्ड में एक नया वाक्यविन्यास फीचर दिखाई देगा। पूर्वावलोकन का अध्ययन करने के बाद, जो संक्षेप में बताता है कि रिकॉर्डिंग कैसे दिखती है और "वे क्या खाते हैं" के साथ, मैंने हिम्मत को रूसी को दस्तावेज़ को अनुकूलित करने की हिम्मत की। कौन परवाह करता है - बिल्ली में आपका स्वागत है।

सारांश

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

कारण और लक्ष्य

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

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

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

लक्ष्य जो नहीं थे

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

विवरण

प्रविष्टियाँ जावा में एक नई तरह की घोषणा हैं। एनम की तरह, लेखन एक कार्यात्मक रूप से सीमित वर्ग है। यह अपने दृश्य की घोषणा करता है और एक एपीआई प्रदान करता है जो उस दृश्य पर बनाता है। प्रविष्टियाँ API को प्रस्तुति से अलग नहीं करती हैं और बदले में संक्षिप्त होती हैं।

प्रविष्टि में नाम और स्थिति का विवरण होता है। राज्य विवरण इस रिकॉर्ड के घटकों की घोषणा करता है। वैकल्पिक रूप से, रिकॉर्ड में एक निकाय हो सकता है। उदाहरण के लिए:

record Point(int x, int y) { } 

चूंकि शब्दार्थ रिकॉर्ड सरल डेटा वाहक हैं, वे स्वचालित रूप से मानक तत्व प्राप्त करते हैं:

• प्रत्येक राज्य घटक के लिए निजी अंतिम क्षेत्र;
• एक ही नाम और प्रकार के साथ प्रत्येक राज्य घटक के लिए एक सार्वजनिक पठन विधि;
• रिकॉर्ड हस्ताक्षर से मेल खाता एक सार्वजनिक निर्माणकर्ता; यह प्रत्येक क्षेत्र को संबंधित तर्क से आरंभ करता है;
• बराबरी के कार्यान्वयन () और हैशकोड (), जो कहते हैं कि दो रिकॉर्ड समान हैं यदि वे एक ही प्रकार के हैं और एक ही स्थिति समाहित करते हैं;
• String () का कार्यान्वयन, जिसमें उनके नाम के साथ सभी रिकॉर्डिंग घटकों का एक स्ट्रिंग प्रतिनिधित्व शामिल है।

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

प्रतिबंध

रिकॉर्ड किसी भी अन्य वर्ग को विरासत में नहीं दे सकते हैं और राज्य के घटकों के अनुरूप निजी अंतिम क्षेत्रों को छोड़कर, ऑब्जेक्ट फ़ील्ड घोषित नहीं कर सकते हैं। कोई अन्य घोषित फ़ील्ड स्थिर होना चाहिए। ये सीमाएँ सुनिश्चित करती हैं कि राज्य का वर्णन अपने आप में दृश्य को परिभाषित करता है।

प्रविष्टियां अंतिम हैं और सार नहीं हो सकती हैं। इन प्रतिबंधों से संकेत मिलता है कि रिकॉर्ड एपीआई केवल एक राज्य विवरण द्वारा परिभाषित किया गया है और बाद में किसी अन्य वर्ग या रिकॉर्ड के साथ बढ़ाया नहीं जा सकता है।

रिकॉर्डिंग घटक अंतिम हैं। यह प्रतिबंध "डिफ़ॉल्ट रूप से अपरिवर्तित" के सिद्धांत को लागू करता है, जिसका उपयोग डेटा सेट के लिए व्यापक रूप से किया जाता है।

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

स्पष्ट रूप से घोषित प्रविष्टियाँ

हालांकि गेटर्स के मानक कार्यान्वयन, साथ ही साथ बराबरी (), हैशकोड (), और स्ट्रींग () विधियों के लिए, अधिकांश उपयोग के मामलों के लिए स्वीकार्य है, डेवलपर के पास मानक कार्यान्वयन को ओवरराइड करने का विकल्प है। हालाँकि, आपको विशेष रूप से सावधान रहना चाहिए जब बराबरी / हैशकोड विधियों को ओवरराइड करना हो।

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

 record Range(int lo, int hi) { public Range { if (lo > hi) /* referring here to the implicit constructor parameters */ throw new IllegalArgumentException(String.format("(%d,%d)", lo, hi)); } } 

व्याकरण

 RecordDeclaration: {ClassModifier} record TypeIdentifier [TypeParameters] (RecordComponents) [SuperInterfaces] [RecordBody] RecordComponents: {RecordComponent {, RecordComponent}} RecordComponent: {Annotation} UnannType Identifier RecordBody: { {RecordBodyDeclaration} } RecordBodyDeclaration: ClassBodyDeclaration RecordConstructorDeclaration RecordConstructorDeclaration: {Annotation} {ConstructorModifier} [TypeParameters] SimpleTypeName [Throws] ConstructorBody 

रिकॉर्डिंग घटकों के लिए एनोटेशन

एनोटेशन एनोटेशन को रिकॉर्डिंग घटकों पर लागू किया जा सकता है यदि वे घटकों, मापदंडों, फ़ील्ड, या विधियों पर लागू होते हैं। इनमें से किसी भी घटक पर लागू होने वाले विज्ञापन एनोटेशन किसी भी आवश्यक तत्वों की निहित घोषणाओं पर लागू होते हैं।

प्रकार के एनोटेशन जो रिकॉर्ड घटकों के प्रकारों को बदलते हैं, वे आवश्यक तत्वों के निहित घोषणाओं के प्रकारों (उदाहरण के लिए, निर्माण पैरामीटर, फ़ील्ड घोषणाएं, और विधियाँ) में विस्तार करते हैं। आवश्यक तत्वों की स्पष्ट घोषणाएं रिकॉर्ड के संबंधित घटक के प्रकार से मेल खाना चाहिए, न कि प्रकार के एनोटेशन सहित।

परावर्तन एपीआई

निम्नलिखित सार्वजनिक विधियों को java.lang.Class में जोड़ा जाएगा:

• RecordComponent [] getRecordCompords ()
• बूलियन रैकार्ड ()

GetRecordCompords () विधि एक सरणी java.lang.reflect.RecordComponent देता है , जहाँ java.lang.reflect.RecordComponent एक नया वर्ग है।

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

यदि इस वर्ग को रिकॉर्ड के रूप में घोषित किया जाता है तो isececord () विधि सही साबित होती है। ( IsEnum () विधि के समान)।

विकल्प

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

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

पर निर्भर करता है

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