खराब जावा या यह कैसे नहीं करना है

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

HashSet

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

// Dummy value to associate with an Object in the backing Map private static final Object PRESENT = new Object(); 

इसका मतलब है कि हैशसेट के अंदर आपका कोई भी मान इस ऑब्जेक्ट के लिंक के साथ जुड़ा होगा। यह समान है:

 Map.put(key, PRESENT); 

ऐसा लगता है, लगता है - 8 बाइट्स, जो सभी द्वारा उपयोग किया जाएगा। लेकिन यह मत भूलो कि हर बार जब आप हैशसेट में डालते हैं, तो Map.Entry बनाया जाता है, जिसमें 4 लिंक होते हैं (प्रति तत्व 16 अतिरिक्त बाइट्स)। व्यर्थ, आप नहीं हैं? ऐसा क्यों? एक बड़ा रहस्य ... धन्यवाद कम से कम विरासत में तो नहीं मिला।

डिफ़ॉल्ट लकड़हारा

प्रोजेक्ट में log4j का उपयोग कौन नहीं करता है? क्या आप ऐसे पुस्तकालयों को नाम दे सकते हैं जो इसके बिना भी करते हैं? मुझे लगता है कि ये कठिन प्रश्न हैं। मैं समझता हूं कि जावा को प्रत्येक विशिष्ट कार्य के लिए समायोजित नहीं किया जा सकता है, लेकिन उन्होंने मानक लकड़हारा जोड़ा है, इसलिए लॉग 4j के अस्तित्व के 10 वर्षों में, जावा ने इसे सबसे अच्छा क्यों नहीं लिया है? कल्पना करें कि सभी अनुप्रयोग, विशेष रूप से जटिल वाले, कम हो जाएंगे, जहां अंतिम विधानसभा में लकड़हारे के कई अलग-अलग संस्करण दिखाई दे सकते हैं।

Clonable

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

serializable

स्थिति क्लोंएबल के समान है, लेकिन यहां कम से कम एक तर्क दे सकता है - ज्यादातर मामलों में
हम व्यवहार को मैन्युअल रूप से परिभाषित नहीं करते हैं, लेकिन मानक कार्यान्वयन पर भरोसा करते हैं और यह लगातार कुछ क्रमांकन विधियों को फिर से परिभाषित करने के लिए बहुत असुविधाजनक होगा + नए क्षेत्रों के जोड़ की लगातार निगरानी करें, उन्हें विधियों में जोड़ें। खैर, इन उद्देश्यों के लिए विशेष रूप से एक्सट्रैटेबल है। हालाँकि, हम जानते हैं कि आप writeObject () और readObject () को पूर्वनिर्धारित करके मानक क्रमांकन व्यवहार को बदल सकते हैं। किसी तरह OOPshny पर नहीं।

गुण

एक तरीका या दूसरा, हम सभी गुण वर्ग के साथ काम करते हैं। हम स्रोत कोड खोलते हैं और हम क्या देखते हैं?

 class Properties extends Hashtable<Object,Object> 

क्यों? किसी को भी पता है कि रचना विरासत से बेहतर है, खासकर अगर इस विरासत का कोई तार्किक अर्थ नहीं है और यह आवेदन मॉडल को सरल नहीं करता है। लोड के बारे में क्या है (InputStream inStream) और load0 (LineReader lr) विधियाँ? लेकिन विधि अधिभार के बारे में क्या? ऐसा ही store0 () के साथ है, भले ही वे कक्षा के अंदर छिपे हों। वैसे, इस तरह के तरीके कोर जावा में हर जगह पाए जाते हैं, किसी की शैली के समान।

आदिम प्रकार शैल वर्ग

शेल कक्षाएं निरर्थक हैं, यह प्राथमिकताओं के साथ काम करने के लिए बहुत अधिक सुविधाजनक होगा और उन्हें शून्य मान प्रदान करने में सक्षम होगा। यदि एक साधारण इंट 4 बाइट्स लेता है, तो इंटेगर ऑब्जेक्ट पहले से ही पूर्णांक 16 है। लगातार कास्टिंग, बराबर की तुलना में। यह सब क्यों? अगले:

 Boolean.getBoolean(); Long.getLong(); Integer.getInteger() 

रहस्यमय तरीके। मुझे अभी भी समझ नहीं आ रहा है कि उन्हें क्या भूमिका निभानी चाहिए और वे तरीके क्यों
check System.getProperty () शेल के वर्गों में हैं, और वर्ग गुणों में नहीं।

स्विच

बेशक, हर जावा डेवलपर जानता है कि स्विच स्टेटमेंट केवल पूर्णांक प्रकार के साथ काम करता है, और 7 वीं जावा के साथ और तार के साथ शुरू होता है। लेकिन ये प्रतिबंध क्यों? संस्करण 7 में स्विच के कार्यान्वयन से देखते हुए, यह हैशोड () और बराबर () के आधार पर एक स्ट्रिंग के साथ काम करता है। फिर सवाल है - केवल तार क्यों? किसी भी ऑब्जेक्ट के लिए ऑपरेटर को लागू करना आसान था, लेकिन किसी कारण से ऐसा नहीं किया गया था। एक और पहेली।

संग्रह

सूची और सेट में एक अच्छा अनुरक्षण है () विधि - सेट को काटना, लेकिन किसी कारण से अंतर सेट के लिए कोई विधि नहीं है। बेशक, आप इसे आसानी से स्वयं लागू कर सकते हैं:

 List first = someList(); List second = someList(); diff = first.clone(); diff.removeAll(second); 

लेकिन मैं इस तरह के एक बुनियादी ऑपरेशन को मुख्य डेटा प्रकारों में से एक से बाहर रखना चाहूंगा।

इसके अलावा, संग्रह के साथ काम करते समय सबसे आम कार्यों में से एक संग्रह में वांछित वस्तु को ढूंढना है। Why List में indexOf (Object o) है, और HashSet को (Object o) नहीं मिलता है, जो हैश कोड द्वारा संग्रह से ऑब्जेक्ट के लिए एक संदर्भ लौटाता है और बराबर करता है। हां, जब हैश कोड को फिर से परिभाषित नहीं किया जाता है, तो इसका कोई मतलब नहीं है, लेकिन जब यह नहीं है, तो उपयोग के लिए पहले से ही अवसर हैं। हो सकता है, मैं निश्चित रूप से, बहुत अधिक दोष ढूंढता हूं, लेकिन अक्सर ऐसा काम उठता है।

उसी श्रेणी से - कुछ संपत्ति के अनुसार वस्तुओं को फ़िल्टर करने का कोई तरीका नहीं है। आपको हमेशा इसे मैन्युअल रूप से करना होगा। बुरा, बहुत बुरा।

जेनेरिक्स

 Map<MyKeyObject, PersistedPlan> plansById = new HashSet<MyKeyObject, PersistedPlan>(); 

जैसा कि पहले ही उल्लेख किया गया है, इस तरह के निर्माण कोड में हर जगह पाए जाते हैं - वर्ग विवरणों में, कंस्ट्रक्टरों में, विधियों में, हर जगह ... वे बहुत अधिक कोड को लोड करते हैं और इसकी धारणा को जटिल करते हैं। सौभाग्य से, 7 वीं जावा में यह तय हो गया था। यह केवल स्पष्ट नहीं है - उन्होंने इतने लंबे समय तक इंतजार क्यों किया?

बहु सूत्रण

पहली बार जब मैंने एरलंग में मल्टीथ्रेडिंग के बारे में पढ़ा, तो मुझे महसूस हुआ कि जटिल जावा मल्टीथ्रेडिंग तंत्र कितने जटिल हैं। ये सभी लॉक, मॉनिटर, सिंक्रोनाइज़ेशन, डेडलॉक, थ्रेड्स, रनवेबल, मेमोरी बैरियर। क्यों? क्यों हमारे जीवन को जटिल बनाते हैं, क्योंकि जावा 20 साल से अधिक पुराना है, क्या वास्तव में हमारे समय के रुझानों पर विचार करना मुश्किल है? आखिरकार, जावा का मुख्य लक्ष्य हमारे लिए जीवन को आसान बनाना था - सरल डेवलपर्स।
पीएस I ने यहां सहयोगियों के साथ बात की, जानकारी है कि इस दिशा में प्रगति छोटी नहीं है, इसलिए हमें उम्मीद है।

शॉर्ट सर्किट

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

रनटाइम और सिस्टम

यह पूरी तरह से इन वर्गों के तार्किक अलगाव को स्पष्ट नहीं करता है, यह मुझे लगता है, एक काफी पर्याप्त होगा। सिस्टम से जुड़ी कुछ अन्य विषमताएँ हैं - उदाहरण के लिए, बाहर और वर्ग के क्षेत्रों में - अंतिम। लेकिन एक ही समय में setOut और setIn विधियाँ हैं। बुरा उदाहरण है, है ना?

तार

बहुत ही अयोग्य, न केवल प्रत्येक चरित्र 2 बाइट्स पर कब्जा करता है, इसलिए प्रत्येक पंक्ति स्ट्रिंग क्लास का एक ऑब्जेक्ट है, और यह बदले में हेडर के प्रति 8 बाइट्स है + 1 सरणी संदर्भ के अंदर 3 पूर्णांक मान == अतिरिक्त 24 बाइट्स प्रत्येक लाइन! फिर भी थोड़ा महंगा। यह कम से कम 2 वैरिएंट बनाने के लिए संभव होगा: सस्ते और महंगे। कम से कम एक विकल्प होगा।

नंबर

 Long l = 2; //compilation error Map<int, Object> a = new HashMap<int, Object>(); //compilation error Map<Object, int> a = new HashMap<Object, int>(); //compilation error Set<int> b = new HashSet<int>(); //compilation error 

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

 //(metric.getValue() * 100 / prevMetric.getValue()) + metric.getOffset() BigDecimal result =BigDecimal.valueOf(metric.getValue() * 100).divide(BigDecimal.valueOf(prevMetric.getValue()).add(metric.getOffset())); 

ठीक है, अगर गणना सरल है, जटिल के साथ, सब कुछ बहुत दुखी है। एक डेटा प्रकार क्यों न पेश करें जो दोहरे और फ्लोट के साथ संख्या के साथ अच्छी तरह से काम करता है?

निष्कर्ष

यह मत सोचो कि यह किसी प्रकार की शरद ऋतु की वृद्धि है। कोई रास्ता नहीं। मुझे वास्तव में जावा पसंद है और मैं चाहता हूं कि यह हमारे समय के रुझानों के साथ विकसित हो। और मैं इसे इन सभी छोटी चीजों के बिना खुशी के साथ कार्यक्रम करने में सक्षम होना चाहता हूं जो केवल एक मनोरंजक और दिलचस्प नौकरी से परेशान और विचलित हैं।