जावा में var प्रकार का उपयोग करने के लिए 26 सिफारिशें

जावा स्थानीय परिवर्तनीय प्रकार का आविष्कार (LVTI) या, संक्षेप में, var प्रकार ( var पहचानकर्ता कोई कीवर्ड नहीं है, लेकिन एक आरक्षित प्रकार का नाम) JEP 286: स्थानीय-परिवर्तनीय प्रकार आविष्कार का उपयोग करके जावा 10 में जोड़ा गया था। एक 100% संकलक फ़ंक्शन होने के कारण, यह बाइटकोड, रनटाइम या प्रदर्शन को प्रभावित नहीं करता है। मूल रूप से, संकलक असाइनमेंट ऑपरेटर के दाईं ओर की जांच करता है और इसके आधार पर, विशिष्ट प्रकार के चर को निर्धारित करता है, और फिर इसे var के साथ बदलता है।

इसके अलावा, यह बॉयलरप्लेट कोड की क्रियाशीलता को कम करने के लिए उपयोगी है, और यह प्रोग्रामिंग प्रक्रिया को भी गति देता है। उदाहरण के लिए, var evenAndOdd =... Map<Boolean, List<Integer>> evenAndOdd =... var evenAndOdd =... बजाय Map<Boolean, List<Integer>> evenAndOdd =... लिखना बहुत सुविधाजनक है Map<Boolean, List<Integer>> evenAndOdd =...

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

इस लेख में, हम 26 स्थितियों को देखेंगे, उदाहरण के साथ कि आप कब var का उपयोग कर सकते हैं, और कब इसके लायक नहीं हैं।

बिंदु 1: स्थानीय चर को सार्थक नाम देने का प्रयास करें

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

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

उदाहरण 1:

कई लोग शायद इस बात से सहमत होंगे कि नीचे के उदाहरण में, स्थानीय चर के नाम बहुत कम हैं:

 // HAVING public boolean callDocumentationTask() { DocumentationTool dtl = ToolProvider.getSystemDocumentationTool(); DocumentationTask dtt = dtl.getTask(...); return dtt.call(); } 

लघु नामों का उपयोग करते समय, var के साथ, कोड और भी कम स्पष्ट हो जाता है:

 // AVOID public boolean callDocumentationTask() { var dtl = ToolProvider.getSystemDocumentationTool(); var dtt = dtl.getTask(...); return dtt.call(); } 

अधिक पसंदीदा विकल्प:

 // PREFER public boolean callDocumentationTask() { var documentationTool = ToolProvider.getSystemDocumentationTool(); var documentationTask = documentationTool.getTask(...); return documentationTask.call(); } 

उदाहरण 2:

इस तरह नामकरण चर से बचें:

 // AVOID public List<Product> fetchProducts(long userId) { var u = userRepository.findById(userId); var p = u.getCart(); return p; } 

अधिक सार्थक नामों का उपयोग करें:

 // PREFER public List<Product> fetchProducts(long userId) { var user = userRepository.findById(userId); var productList = user.getCart(); return productList; } 

उदाहरण 3:

स्थानीय चर के लिए अधिक समझदार नाम देने के प्रयास में, चरम सीमा पर न जाएं:

 // AVOID var byteArrayOutputStream = new ByteArrayOutputStream(); 

इसके बजाय, आप एक छोटे, लेकिन कम समझ में आने वाले विकल्प का उपयोग कर सकते हैं:

 // PREFER var outputStream = new ByteArrayOutputStream(); // or var outputStreamOfFoo = new ByteArrayOutputStream(); 

क्या आप जानते हैं कि जावा में एक आंतरिक वर्ग का नाम है:
InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState

खैर, इस प्रकार के नामकरण चर मुश्किल हो सकते हैं :)

बिंदु 2: आदिम के प्रकार (इंट, लॉन्ग, फ्लोट, डबल) की मदद करने के लिए शाब्दिक का उपयोग करें

आदिम प्रकारों के लिए शाब्दिक उपयोग के बिना, हम पा सकते हैं कि अपेक्षित और निहित प्रकार भिन्न हो सकते हैं। यह वैरिएबल द्वारा प्रयुक्त निहित प्रकार रूपांतरण के कारण होता है।

उदाहरण के लिए, निम्नलिखित दो कोड टुकड़े अपेक्षित रूप से व्यवहार करते हैं। यहाँ हम स्पष्ट रूप से बूलियन और चार प्रकारों की घोषणा करते हैं:

 boolean flag = true; // this is of type boolean char a = 'a'; // this is of type char 

अब हम स्पष्ट रूप से घोषित प्रकारों के बजाय var का उपयोग करते हैं:

 var flag = true; // this is inferred as boolean var a = 'a'; // this is inferred as char 

अभी तक तो अच्छा है। अब इंट , लॉन्ग , फ्लोट और डबल टाइप्स के लिए भी ऐसा ही करें:

 int intNumber = 20; // this is of type int long longNumber = 20; // this is of type long float floatNumber = 20; // this is of type float, 20.0 double doubleNumber = 20; // this is of type double, 20.0 

यद्यपि उपरोक्त कोड स्निपेट सरल और सीधा है, अब स्पष्ट रूप से निर्दिष्ट प्रकारों के बजाय var का उपयोग करते हैं।

से बचें:

 // AVOID var intNumber = 20; // this is inferred as int var longNumber = 20; // this is inferred as int var floatNumber = 20; // this is inferred as int var doubleNumber = 20; // this is inferred as int 

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

 // PREFER var intNumber = 20; // this is inferred as int var longNumber = 20L; // this is inferred as long var floatNumber = 20F; // this is inferred as float, 20.0 var doubleNumber = 20D; // this is inferred as double, 20.0 

लेकिन अगर हम दशमलव संख्या घोषित करते हैं तो क्या होगा?

इससे बचने के लिए यदि आप एक प्रकार का चर पाने की उम्मीद करते हैं:

 // AVOID, IF THIS IS A FLOAT var floatNumber = 20.5; // this is inferred as double 

आश्चर्य से बचने के लिए, उपयुक्त शाब्दिक का उपयोग करें:

 // PREFER, IF THIS IS A FLOAT var floatNumber = 20.5F; // this is inferred as float 

बिंदु 3: कुछ मामलों में संस्करण और अंतर्निहित प्रकार रूपांतरण कोड समर्थन को सरल बना सकते हैं

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

पहले, आइए एक विधि देखें जो सर्वोत्तम मूल्य की गणना करती है:

 public float computeBestPrice(String[] items) { ... float price = ...; return price; } 

दूसरी बात, आइए नक्शे के साथ काम करने वाली विधि पर एक नज़र डालते हैं:

 public boolean debitCard(float amount, ...) { ... } 

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

 // AVOID public void purchaseCart(long customerId) { ... float price = computeBestPrice(...); debitCard(price, ...); } 

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

 public int computeBestPrice(String[] items) { ... float realprice = ...; ... int price = (int) realprice; return price; } public boolean debitCard(int amount, ...) { ... } 

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

 // PREFER public void purchaseCart(long customerId) { ... var price = computeBestPrice(...); debitCard(price, ...); } 

बिंदु 4: जब शाब्दिक रूप से उपयुक्त समाधान नहीं है, तो स्पष्ट कास्टिंग का उपयोग करें या var को त्यागें

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

Var के बजाय इसका उपयोग करें:

 // PREFER THIS INSTEAD OF USING VAR byte byteNumber = 45; // this is of type byte short shortNumber = 4533; // this is of type short 

लेकिन इस स्थिति में केवल var का उपयोग करने के बजाय स्पष्ट प्रकार संकेतन को वरीयता क्यों दें? खैर, चलिए इस कोड को var का उपयोग करके लिखते हैं। ध्यान दें कि दोनों ही मामलों में, कंपाइलर यह मान लेगा कि आपको टाइप इंट के चर की आवश्यकता है।

इस त्रुटि से बचें:

 // AVOID var byteNumber = 45; // this is inferred as int var shortNumber = 4533; // this is inferred as int 

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

केवल इस प्रविष्टि का उपयोग करें यदि आप वास्तव में var का उपयोग करना चाहते हैं:

 // PREFER THIS ONLY IF YOU WANT TO USE VAR var byteNumber = (byte) 45; // this is inferred as byte var shortNumber = (short) 4533; // this is inferred as short 

अंक 5: यदि चर नाम कोड को समझने के लिए पर्याप्त प्रकार की जानकारी नहीं रखते हैं तो var का उपयोग करने से बचें

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

निम्नलिखित से बचें:

 // AVOID MemoryCacheImageInputStream inputStream = new MemoryCacheImageInputStream(...); 

इसके बजाय उपयोग करें:

 // PREFER var inputStream = new MemoryCacheImageInputStream(...); 

नीचे के निर्माण के लिए, var बिना सूचना खोए कोड को सरल बनाने का एक अच्छा तरीका होगा।

से बचें:

 // AVOID JavaCompiler compiler = ToolProvider.getSystemJavaCompiler(); StandardJavaFileManager fm = compiler.getStandardFileManager(...); 

निम्नलिखित कोड का उपयोग करें:

 // PREFER var compiler = ToolProvider.getSystemJavaCompiler(); var fileManager = compiler.getStandardFileManager(...); 

तो, प्रस्तुत उदाहरणों में हम var के साथ काम करने में अधिक सहज क्यों हैं? क्योंकि सभी आवश्यक जानकारी चर के नामों में निहित है। लेकिन अगर संस्करण , चर नाम के साथ संयोजन में, कोड की स्पष्टता को कम कर देता है, तो इसका उपयोग करने से इनकार करना बेहतर है।

से बचें:

 // AVOID public File fetchCartContent() { return new File(...); } // As a human, is hard to infer the "cart" type without // inspecting the fetchCartContent() method var cart = fetchCartContent(); 

का उपयोग करें:

 // PREFER public File fetchCartContent() { return new File(...); } File cart = fetchCartContent(); 

उदाहरण के लिए, java.nio.channels.Selector वर्ग के उपयोग पर विचार करें। इस वर्ग में एक स्थिर open() विधि है जो एक नया चयनकर्ता लौटाता है और इसे खोलता है। लेकिन यहां आप आसानी से सोच सकते हैं कि Selector.open() विधि एक बूलियन प्रकार वापस कर सकती है, जो मौजूदा चयनकर्ता को खोलने की सफलता के आधार पर, या यहां तक ​​कि शून्य भी लौटा सकती है । यहां var का उपयोग करने से कोड में जानकारी और भ्रम की स्थिति पैदा होगी।

बिंदु 6: var प्रकार संकलन-समय सुरक्षा की गारंटी देता है

इसका अर्थ है कि हम एक ऐसे एप्लिकेशन को संकलित नहीं कर सकते हैं जो गलत कार्य करने का प्रयास करता है। उदाहरण के लिए, नीचे दिया गया कोड संकलित नहीं होता है:

 // IT DOESN'T COMPILE var items = 10; items = "10 items"; // incompatible types: String cannot be converted to int 

लेकिन यह एक संकलन:

 var items = 10; items = 20; 

और यह कोड सफलतापूर्वक संकलित करता है:

 var items = "10"; items = "10 items"; 

एक बार कंपाइलर ने वैरिएबल के मान को परिभाषित कर लिया है, हम इस प्रकार के अलावा कुछ भी असाइन नहीं कर सकते हैं।

बिंदु 7: var का उपयोग किसी विशिष्ट प्रकार को तत्काल करने और इंटरफ़ेस प्रकार चर में असाइन करने के लिए नहीं किया जा सकता है

जावा में, हम "इंटरफेस विथ इंटरफेस" दृष्टिकोण का उपयोग करते हैं। उदाहरण के लिए, हम ArrayList वर्ग का एक उदाहरण बनाते हैं, इसे अमूर्त (इंटरफ़ेस) के साथ जोड़ते हैं:

 List<String> products = new ArrayList<>(); 

और हम एक वस्तु को उसी प्रकार के चर से बांधने जैसी चीजों से बचते हैं:

 ArrayList<String> products = new ArrayList<>(); 

यह सबसे आम और वांछनीय अभ्यास है, क्योंकि हम इंटरफ़ेस कार्यान्वयन को आसानी से किसी अन्य के साथ बदल सकते हैं। इसके लिए, केवल इंटरफ़ेस प्रकार चर घोषित करना आवश्यक है।

जैसा कि हम वैरिएबल का उपयोग करके इस अवधारणा का पालन नहीं कर पाएंगे एक विशिष्ट प्रकार हमेशा उनके लिए प्रदर्शित किया जाता है। उदाहरण के लिए, निम्नलिखित कोड स्निपेट में, कंपाइलर चर के प्रकार को ArrayList<String> रूप में निर्धारित करेगा।

 var productList = new ArrayList<String>(); // inferred as ArrayList<String> 

कई रक्षा तर्क हैं जो इस व्यवहार की व्याख्या करते हैं:

• var का उपयोग स्थानीय चर के लिए किया जाता है, जहां, ज्यादातर मामलों में, इंटरफेस का उपयोग करते हुए प्रोग्रामिंग का उपयोग उन मामलों की तुलना में कम किया जाता है जहां मान या फ़ील्ड द्वारा लौटाए गए विधि पैरामीटर हैं

  
  

• स्थानीय चर का दायरा छोटा होना चाहिए, इसलिए किसी अन्य कार्यान्वयन पर स्विच करने के कारण होने वाली समस्याओं को हल करना बहुत मुश्किल नहीं होना चाहिए

  
  

• var वास्तविक प्रकार निर्धारित करने के लिए उपयोग किए जाने वाले initializer के रूप में दाईं ओर कोड को मानता है। यदि, कुछ बिंदु पर, इनिशियलाइज़र को बदल दिया जाता है, तो परिभाषित किया जा रहा प्रकार भी बदल सकता है, जिससे कोड में समस्याएँ आती हैं जो इस चर पर निर्भर करता है।

  
  

अनुच्छेद 8: एक अप्रत्याशित प्रकार के समापन की संभावना

प्रकार की पहचान करने के लिए जानकारी की अनुपस्थिति में हीरे के ऑपरेटर (<>) के साथ संयोजन में var का उपयोग करने से अप्रत्याशित परिणाम हो सकते हैं।

जावा 7 से पहले, संग्रह के लिए स्पष्ट प्रकार का प्रयोग किया गया था:

 // explicitly specifying generic class's instantiation parameter type List<String> products = new ArrayList<String>(); 

जावा 7 से शुरू होकर, हीरा ऑपरेटर को पेश किया गया था। इस मामले में, संकलक स्वतंत्र रूप से आवश्यक प्रकार का उत्पादन करेगा:

 // inferring generic class's instantiation parameter type List<String> products = new ArrayList<>(); 

नीचे दिए गए कोड में किस प्रकार का आउटपुट होगा?

आपको ऐसे निर्माणों से बचना चाहिए:

 // AVOID var productList = new ArrayList<>(); // is inferred as ArrayList<Object> 

प्रकार को ArrayList<Object> रूप में परिभाषित किया जाएगा। ऐसा इसलिए है क्योंकि प्रकार को सही ढंग से निर्धारित करने के लिए आवश्यक जानकारी प्रदान नहीं की गई है। यह इस तथ्य की ओर जाता है कि निकटतम प्रकार का चयन किया जाएगा, जो कि जो हो रहा है उसके संदर्भ के साथ संगत हो सकता है। इस मामले में, Object ।

इस प्रकार, var का उपयोग केवल तभी किया जा सकता है जब हम अपेक्षित प्रकार निर्धारित करने के लिए आवश्यक जानकारी प्रदान करते हैं। प्रकार को सीधे निर्दिष्ट किया जा सकता है या तर्क के रूप में पारित किया जा सकता है।

सीधे प्रकार निर्दिष्ट करें:

 // PREFER var productList = new ArrayList<String>(); // inferred as ArrayList<String> 

आवश्यक प्रकार के तर्क पास करें:

 var productStack = new ArrayDeque<String>(); var productList = new ArrayList<>(productStack); // inferred as ArrayList<String> 

 Product p1 = new Product(); Product p2 = new Product(); var listOfProduct = List.of(p1, p2); // inferred as List<Product> // DON'T DO THIS var listofProduct = List.of(); // inferred as List<Object> listofProduct.add(p1); listofProduct.add(p2); 

आइटम 9: एक वेरिएबल को एक वेरिएबल में ऐरे को असाइन करने के लिए कोष्ठक की आवश्यकता नहीं है

हम सभी जानते हैं कि जावा में सरणियों की घोषणा कैसे करें:

 int[] numbers = new int[5]; // or, less preferred int numbers[] = new int[5]; 

सरणियों के साथ काम करते समय var का उपयोग कैसे करें? इस मामले में, बाईं ओर कोष्ठक का उपयोग करने की आवश्यकता नहीं है।

निम्नलिखित से बचें (यह भी संकलन नहीं है):

 // IT DOESN'T COMPILE var[] numbers = new int[5]; // or var numbers[] = new int[5]; 

का उपयोग करें:

 // PREFER var numbers = new int[5]; // inferred as array of int numbers[0] = 2; // work numbers[0] = 2.2; // doesn't work numbers[0] = "2"; // doesn't work 

Var का उपयोग करके नीचे दिया गया कोड भी संकलन करने में विफल रहता है। ऐसा इसलिए है क्योंकि कंपाइलर दाईं ओर से प्रकार निर्धारित नहीं कर सकता है:

 // explicit type work as expected int[] numbers = {1, 2, 3}; // IT DOESN'T COMPILE var numbers = {1, 2, 3}; var numbers[] = {1, 2, 3}; var[] numbers = {1, 2, 3}; 

आइटम 10: एक ही लाइन पर कई चर घोषित करते समय var का उपयोग नहीं किया जा सकता है

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

 // IT DOESN'T COMPILE // error: 'var' is not allowed in a compound declaration var hello = "hello", bye = "bye", welcome = "welcome"; 

इसके बजाय उपयोग करें:

 // PREFER String hello = "hello", bye = "bye", welcome = "welcome"; 

या यह है:

 // PREFER var hello = "hello"; var bye = "bye"; var welcome = "welcome"; 

बिंदु 11: स्थानीय चर को अपने दायरे को कम करने का प्रयास करना चाहिए। Var प्रकार इस कथन को पुष्ट करता है।

स्थानीय चर के लिए एक छोटी सी गुंजाइश रखें - मुझे यकीन है कि आपने इस कथन को var से पहले सुना होगा।

पठनीयता और त्वरित बग फिक्स इस दृष्टिकोण के पक्ष में तर्क हैं। उदाहरण के लिए, आइए एक स्टैक को निम्नानुसार परिभाषित करें:

इससे बचें:

 // AVOID ... var stack = new Stack<String>(); stack.push("George"); stack.push("Tyllen"); stack.push("Martin"); stack.push("Kelly"); ... // 50 lines of code that doesn't use stack // George, Tyllen, Martin, Kelly stack.forEach(...); ... 

ध्यान दें कि हम forEach() विधि को कॉल कर रहे हैं, जो कि java.util.Vector से विरासत में मिली है। यह विधि किसी भी अन्य वेक्टर की तरह स्टैक से होकर गुजरेगी और यही हमारी जरूरत है। लेकिन अब हमने Stack बजाय ArrayDeque का उपयोग करने का फैसला किया। जब हम ऐसा करते हैं, तो forEach() विधि ArrayDeque से एक कार्यान्वयन प्राप्त करेगी जो स्टैक को मानक स्टैक (LIFO) के रूप में पीछे ले जाएगी।

 // AVOID ... var stack = new ArrayDeque<String>(); stack.push("George"); stack.push("Tyllen"); stack.push("Martin"); stack.push("Kelly"); ... // 50 lines of code that doesn't use stack // Kelly, Martin, Tyllen, George stack.forEach(...); ... 

यह वह नहीं है जो हम चाहते हैं। यहां त्रुटि को ट्रैक करना बहुत कठिन है, क्योंकि जिस कोड में परिवर्तन किए गए थे, उसके आगे forEach() भाग स्थित नहीं है। त्रुटियों की खोज और फिक्सिंग की गति को बढ़ाने के लिए, stack चर का उपयोग करके कोड लिखना बेहतर है, जितना संभव हो इस चर की घोषणा के करीब।

यह इस प्रकार किया जाता है:

 // PREFER ... var stack = new Stack<String>(); stack.push("George"); stack.push("Tyllen"); stack.push("Martin"); stack.push("Kelly"); ... // George, Tyllen, Martin, Kelly stack.forEach(...); ... // 50 lines of code that doesn't use stack 

अब, जब डेवलपर Stack से ArrayQueue स्विच करता है, तो वह त्रुटि को तुरंत नोटिस कर सकेगा और उसे ठीक कर सकेगा।

खण्ड 12: संस्करण प्रकार, टर्नरी ऑपरेटरों में विभिन्न प्रकारों के उपयोग को सरल करता है

हम टर्नरी ऑपरेटर के दाईं ओर विभिन्न प्रकार के ऑपरेंड का उपयोग कर सकते हैं।

जब स्पष्ट रूप से निर्दिष्ट प्रकार, निम्नलिखित कोड संकलित नहीं करता है:

 // IT DOESN'T COMPILE List code = containsDuplicates ? List.of(12, 1, 12) : Set.of(12, 1, 10); // or Set code = containsDuplicates ? List.of(12, 1, 12) : Set.of(12, 1, 10); 

फिर भी, हम यह कर सकते हैं:

 Collection code = containsDuplicates ? List.of(12, 1, 12) : Set.of(12, 1, 10); Object code = containsDuplicates ? List.of(12, 1, 12) : Set.of(12, 1, 10); 

नीचे दिए गए कोड भी संकलित नहीं हैं:

 // IT DOESN'T COMPILE int code = intOrString ? 12112 : "12112"; String code = intOrString ? 12112 : "12112"; 

लेकिन आप अधिक सामान्य प्रकारों का उपयोग कर सकते हैं:

 Serializable code = intOrString ? 12112 : "12112"; Object code = intOrString ? 12112 : "12112"; 

ऐसे सभी मामलों में var को प्राथमिकता देना बेहतर है:

 // PREFER // inferred as Collection<Integer> var code = containsDuplicates ? List.of(12, 1, 12) : Set.of(12, 1, 10); // inferred as Serializable var code = intOrString ? 12112 : "12112"; 

यह इन उदाहरणों से पालन नहीं करता है कि रन टाइम पर var प्रकार ऑब्जेक्ट प्रकार को परिभाषित करता है। ऐसा नहीं है!

और, ज़ाहिर है, दोनों प्रकार के ऑपरेंड के साथ var प्रकार सही ढंग से काम करेगा:

 // inferred as float var code = oneOrTwoDigits ? 1211.2f : 1211.25f; 

प्वाइंट 13: छोरों के अंदर var प्रकार का उपयोग किया जा सकता है

हम प्रकार के साथ छोरों के लिए प्रकारों की स्पष्ट घोषणा को आसानी से बदल सकते हैं।

Var के लिए एक स्पष्ट इंट प्रकार बदलना:

 // explicit type for (int i = 0; i < 5; i++) { ... } // using var for (var i = 0; i < 5; i++) { // i is inferred of type int ... } 

Order के स्पष्ट प्रकार को बदलकर var :

 List<Order> orderList = ...; // explicit type for (Order order : orderList) { ... } // using var for (var order : orderList) { // order type is inferred as Order ... } 

प्वाइंट 14: जावा 8 में स्ट्रीम के साथ var ठीक काम करता है

जावा 8 में दिखाई देने वाली धाराओं के साथ जावा 10 से संस्करण का उपयोग करना बहुत सरल है।

आप बस प्रकार की स्पष्ट घोषणा को var के साथ बदल सकते हैं:

उदाहरण 1:

 // explicit type Stream<Integer> numbers = Stream.of(1, 2, 3, 4, 5); numbers.filter(t -> t % 2 == 0).forEach(System.out::println); // using var var numbers = Stream.of(1, 2, 3, 4, 5); // inferred as Stream<Integer> numbers.filter(t -> t % 2 == 0).forEach(System.out::println); 

उदाहरण 2:

 // explicit types Stream<String> paths = Files.lines(Path.of("...")); List<File> files = paths.map(p -> new File(p)).collect(toList()); // using var var paths = Files.lines(Path.of("...")); // inferred as Stream<String> var files = paths.map(p -> new File(p)).collect(toList()); // inferred as List<File> 

खंड 15: भागों में अभिव्यक्ति की बड़ी श्रृंखलाओं को तोड़ने के लिए स्थानीय चर घोषित करते समय var का उपयोग किया जा सकता है

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

एक बड़ी अभिव्यक्ति का एक उदाहरण:

 List<Integer> intList = List.of(1, 1, 2, 3, 4, 4, 6, 2, 1, 5, 4, 5); // AVOID int result = intList.stream() .collect(Collectors.partitioningBy(i -> i % 2 == 0)) .values() .stream() .max(Comparator.comparing(List::size)) .orElse(Collections.emptyList()) .stream() .mapToInt(Integer::intValue) .sum(); 

अपने घटक भागों में कोड को बेहतर तरीके से तोड़ें:

 List<Integer> intList = List.of(1, 1, 2, 3, 4, 4, 6, 2, 1, 5, 4, 5); // PREFER Map<Boolean, List<Integer>> evenAndOdd = intList.stream() .collect(Collectors.partitioningBy(i -> i % 2 == 0)); Optional<List<Integer>> evenOrOdd = evenAndOdd.values() .stream() .max(Comparator.comparing(List::size)); int sumEvenOrOdd = evenOrOdd.orElse(Collections.emptyList()) .stream() .mapToInt(Integer::intValue) .sum(); 

कोड का दूसरा संस्करण अधिक पठनीय और सरल लगता है, लेकिन पहले संस्करण में भी अस्तित्व का अधिकार है। हमारे दिमाग के लिए इतनी बड़ी अभिव्यक्तियों की समझ के अनुकूल होना और उन्हें स्थानीय चरों के लिए पसंद करना बिल्कुल सामान्य है। हालांकि, स्थानीय प्रकार घोषित करने के प्रयास को कम करके, var प्रकार का उपयोग करने से बड़ी संरचनाओं को तोड़ने में मदद मिल सकती है:

 var intList = List.of(1, 1, 2, 3, 4, 4, 6, 2, 1, 5, 4, 5); // PREFER var evenAndOdd = intList.stream() .collect(Collectors.partitioningBy(i -> i % 2 == 0)); var evenOrOdd = evenAndOdd.values() .stream() .max(Comparator.comparing(List::size)); var sumEvenOrOdd = evenOrOdd.orElse(Collections.emptyList()) .stream() .mapToInt(Integer::intValue) .sum(); 

खण्ड 16: var का उपयोग रिटर्न प्रकार या विधि तर्क प्रकार के रूप में नहीं किया जा सकता है

नीचे दिखाए गए दो कोड स्निपेट संकलन नहीं करेंगे।

वापसी प्रकार के रूप में var का उपयोग करना:

 // IT DOESN'T COMPILE public var countItems(Order order, long timestamp) { ... } 

एक प्रकार की विधि तर्क के रूप में var का उपयोग करना:

 // IT DOESN'T COMPILE public int countItems(var order, var timestamp) { ... } 

खण्ड 17: प्रकार के स्थानीय चर को विधि के मापदंडों के रूप में पारित किया जा सकता है या वे विधि द्वारा लौटाए गए मूल्य ले सकते हैं

निम्न कोड टुकड़े संकलन और ठीक से काम करेंगे:

 public int countItems(Order order, long timestamp) { ... } public boolean checkOrder() { var order = ...; // an Order instance var timestamp = ...; // a long representing a timestamp var itemsNr = countItems(order, timestamp); // inferred as int type ... } 

:

 public <A, B> B contains(A container, B tocontain) { ... } var order = ...; // Order instance var product = ...; // Product instance var resultProduct = contains(order, product); // inferred as Product type 

18: var

:

 public interface Weighter { int getWeight(Product product); } // AVOID Weighter weighter = new Weighter() { @Override public int getWeight(Product product) { ... } }; Product product = ...; // a Product instance int weight = weighter.getWeight(product); 

var :

 public interface Weighter { int getWeight(Product product); } // PREFER var weighter = new Weighter() { @Override public int getWeight(Product product) { ... } }; var product = ...; // a Product instance var weight = weighter.getWeight(product); 

19: var effectively final

, :

… Java SE 8, , final effectively final. , , effectively final .

, var effectively final. .

:

 public interface Weighter { int getWeight(Product product); } // AVOID int ratio = 5; // this is effectively final Weighter weighter = new Weighter() { @Override public int getWeight(Product product) { return ratio * ...; } }; ratio = 3; // this reassignment will cause error 

:

 public interface Weighter { int getWeight(Product product); } // PREFER var ratio = 5; // this is effectively final var weighter = new Weighter() { @Override public int getWeight(Product product) { return ratio * ...; } }; ratio = 3; // this reassignment will cause error 

20: var- final-

var ( , effectively final). , final .

:

 // AVOID // IT DOESN'T COMPILE public void discount(int price) { final int limit = 2000; final int discount = 5; if (price > limit) { discount++; // this reassignment will cause error, which is ok } } 

:

 // PREFER // IT DOESN'T COMPILE public void discount(int price) { final var limit = 2000; final var discount = 5; if (price > limit) { discount++; // this reassignment will cause error, which is ok } } 

21:

var , . , var , :

 // IT DOESN'T COMPILE // lambda expression needs an explicit target-type var f = x -> x + 1; // method reference needs an explicit target-type var exception = IllegalArgumentException::new; 

:

 // PREFER Function<Integer, Integer> f = x -> x + 1; Supplier<IllegalArgumentException> exception = IllegalArgumentException::new; 

Java 11 var - . Java 11:

 // Java 11 (var x, var y) -> x + y // or (@Nonnull var x, @Nonnull var y) -> x + y 

22: var null'

var - .

( null ):

 // IT DOESN'T COMPILE var message = null; // result in an error of type: variable initializer is 'null' 

( ):

 // IT DOESN'T COMPILE var message; // result in: cannot use 'var' on variable without initializer ... message = "hello"; 

:

 // PREFER String message = null; // or String message; ... message = "hello"; 

23: var

var , .

:

 // IT DOESN'T COMPILE public class Product { private var price; // error: 'var' is not allowed here private var name; // error: 'var' is not allowed here ... } 

:

 // PREFER public class Product { private int price; private String name; ... } 

24: var catch

, try-with-resources

catch

, , .

:

 // IT DOESN'T COMPILE try { TimeUnit.NANOSECONDS.sleep(5000); } catch (var ex) { ... } 

:

 // PREFER try { TimeUnit.NANOSECONDS.sleep(5000); } catch (InterruptedException ex) { ... } 

Try-with-resources

, var try-with-resources .

, :

 // explicit type try (PrintWriter writer = new PrintWriter(new File("welcome.txt"))) { writer.println("Welcome message"); } 

var :

 // using var try (var writer = new PrintWriter(new File("welcome.txt"))) { writer.println("Welcome message"); } 

25: var

, :

 public <T extends Number> T add(T t) { T temp = t; ... return temp; } 

, var , T var :

 public <T extends Number> T add(T t) { var temp = t; ... return temp; } 

, var :

 codepublic <T extends Number> T add(T t) { List<T> numbers = new ArrayList<>(); numbers.add((T) Integer.valueOf(3)); numbers.add((T) Double.valueOf(3.9)); numbers.add(t); numbers.add("5"); // error: incompatible types: String cannot be converted to T ... } 

List<T> var :

 public <T extends Number> T add(T t) { var numbers = new ArrayList<T>(); // DON'T DO THIS, DON'T FORGET THE, T var numbers = new ArrayList<>(); numbers.add((T) Integer.valueOf(3)); numbers.add((T) Double.valueOf(3.9)); numbers.add(t); numbers.add("5"); // error: incompatible types: String cannot be converted to T ... } 

26: var Wildcards (?),

? Wildcards

var :

 // explicit type Class<?> clazz = Integer.class; // use var var clazz = Integer.class; 

Foo<?> var , , var .

, , , , . , ArrayList , Collection<?> :

 // explicit type Collection<?> stuff = new ArrayList<>(); stuff.add("hello"); // compile time error stuff.add("world"); // compile time error // use var, this will remove the error, but I don't think that this is // what you had in mind when you wrote the above code var stuff = new ArrayList<>(); strings.add("hello"); // no error strings.add("world"); // no error 

(Foo <? extends T>) (Foo <? super T>)

, :

 // explicit type Class<? extends Number> intNumber = Integer.class; Class<? super FilterReader> fileReader = Reader.class; 

, , :

 // IT DOESN'T COMPILE // error: Class<Reader> cannot be converted to Class<? extends Number> Class<? extends Number> intNumber = Reader.class; // error: Class<Integer> cannot be converted to Class<? super FilterReader> Class<? super FilterReader> fileReader = Integer.class; 

var :

 // using var var intNumber = Integer.class; var fileReader = Reader.class; 

, . – :

 // this will compile just fine var intNumber = Reader.class; var fileReader = Integer.class; 

निष्कर्ष

« var », Java 10. , . , var , .

var Java!