एक बार फिर से जावा में ImmutableList के बारे में

मेरे पिछले लेख में, " जावा में इम्युनटेबलिस्ट के आसपास क्लोकिंग, " मैंने जावा में अपरिवर्तनीय सूचियों की अनुपस्थिति की समस्या का समाधान प्रस्तावित किया था, जो कि जावा में अब और न ही कभी तय हुई है।

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

समस्या का बयान

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

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

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

हम एक पुस्तकालय बनाएंगे जो जावा में मौजूदा संग्रह के साथ सफलतापूर्वक सहयोग कर सकता है।

पुस्तकालय के मुख्य विचार:

• MutableList और MutableList । प्रकार कास्टिंग करके एक से दूसरे को प्राप्त करना असंभव है।
• हमारी परियोजना में, जिसे हम पुस्तकालय का उपयोग करके सुधारना चाहते हैं, हम इन दो इंटरफेसों में से एक के साथ सभी List एस को प्रतिस्थापित करते हैं। यदि कुछ बिंदु पर आप List बिना नहीं कर सकते हैं, तो पहले अवसर पर हम List को / से दो इंटरफेस में से एक में बदल देंगे। यह List का उपयोग करके तीसरे पक्ष के पुस्तकालयों को डेटा प्राप्त / प्रसारित करने के क्षणों पर लागू होता है।
• MutableList , MutableList , List बीच आपसी रूपांतरण को यथाशीघ्र निष्पादित किया जाना चाहिए (अर्थात, यदि संभव हो तो सूचियों की नकल के बिना)। "सस्ते" गोल-यात्रा रूपांतरणों के बिना, पूरा विचार संदिग्ध लगने लगता है।

यह ध्यान दिया जाना चाहिए कि केवल सूचियों पर विचार किया जाता है, क्योंकि फिलहाल उन्हें केवल पुस्तकालय में लागू किया जाता है। लेकिन कुछ भी नहीं पुस्तकालय को Set और Map साथ पूरक होने से रोकता है।

एपीआई

ImmutableList

ImmutableList ReadOnlyList का उत्तराधिकारी है (जो कि पिछले लेख के अनुसार, एक कॉपी List गई List इंटरफ़ेस है जिसमें से सभी उत्परिवर्तन विधियाँ डाली गई हैं)। जोड़े गए तरीके:

 List<E> toList(); MutableList<E> mutable(); boolean contentEquals(Iterable<? extends E> iterable); 

toList विधि एक toList को List प्रतीक्षा कर रहे कोड के टुकड़ों को पास करने की क्षमता प्रदान करती है। एक रैपर लौटाया जाता है जिसमें सभी संशोधित विधियाँ एक UnsupportedOperationException वापस करती हैं, और शेष विधियाँ मूल ImmutableList पुनर्निर्देशित की जाती हैं।

mutable विधि एक MutableList को MutableList । एक रैपर लौटाया जाता है जिसमें पहले बदलाव तक सभी तरीकों को मूल ImmutableList पुनर्निर्देशित किया जाता है। परिवर्तन से पहले, आवरण मूल ImmutableList से ImmutableList , इसकी सामग्री को आंतरिक ArrayList कॉपी करता है, जिससे सभी ऑपरेशन फिर पुनर्निर्देशित किए जाते हैं।

contentEquals विधि की सूची की सामग्री की तुलना एक मनमाने ढंग से पारित होने की सामग्री के साथ की गई (निश्चित रूप से, यह ऑपरेशन केवल उन Iterable कार्यान्वयनों के लिए सार्थक है जिनके पास तत्वों के कुछ अलग क्रम हैं)।

ध्यान दें कि ReadOnlyList हमारे कार्यान्वयन में, listIterator और listIterator मानक java.util.Iterator / java.util.ListIterator वापस करती हैं। इन पुनरावृत्तियों में संशोधन करने के तरीके शामिल हैं जिन्हें UnsupportedOperationException को फेंकने से दबाया जाना होगा। यह हमारा ReadOnlyIterator बनाने के लिए बेहतर होगा, लेकिन इस मामले में हम for (Object item : immutableList) नहीं लिख सकते हैं, जो लाइब्रेरी का उपयोग करने के सभी खुशी को तुरंत खराब कर देगा।

MutableList

MutableList नियमित List का वंशज है। जोड़े गए तरीके:

 ImmutableList<E> snapshot(); void releaseSnapshot(); boolean contentEquals(Iterable<? extends E> iterable); 

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

Mutabor

Mutabor वर्ग स्थिर तरीकों का एक सेट प्रदान करता है जो पुस्तकालय में "प्रवेश बिंदु" हैं।

हाँ, इस परियोजना को अब "म्यूटाबोल" कहा जाता है (यह "म्यूटेबल" के साथ संगत है, और अनुवाद में इसका अर्थ है "मैं रूपांतरित करूंगा", जो अच्छी तरह से दूसरों में कुछ प्रकार के संग्रह "बदलने") के विचार के साथ है।

 public static <E> ImmutableList<E> copyToImmutableList(E[] original); public static <E> ImmutableList<E> copyToImmutableList(Collection<? extends E> original); public static <E> ImmutableList<E> convertToImmutableList(Collection<? extends E> original); public static <E> MutableList<E> copyToMutableList(Collection<? extends E> original); public static <E> MutableList<E> convertToMutableList(List<E> original); 

copyTo* तरीके प्रदान किए गए डेटा की प्रतिलिपि बनाकर उपयुक्त संग्रह बनाने के लिए डिज़ाइन किए गए हैं। convertTo* विधियाँ वांछित प्रकार को हस्तांतरित संग्रह के त्वरित रूपांतरण के लिए convertTo* , और यदि यह जल्दी से परिवर्तित करना संभव नहीं था, तो वे धीमी नकल करते हैं। यदि त्वरित रूपांतरण सफल रहा, तो मूल संग्रह साफ़ हो जाता है, और यह माना जाता है कि भविष्य में इसका उपयोग नहीं किया जाएगा (हालांकि यह हो सकता है, लेकिन यह शायद ही समझ में आता है)।

MutableList / MutableList कार्यान्वयन ImmutableList MutableList लिए कॉल छिपा हुआ है। यह माना जाता है कि उपयोगकर्ता केवल इंटरफेस के साथ व्यवहार करता है, वह इस तरह की वस्तुओं का निर्माण नहीं करता है, और संग्रह को बदलने के लिए ऊपर वर्णित विधियों का उपयोग करता है।

कार्यान्वयन का विवरण

ImmutableListImpl

वस्तुओं की एक सरणी encapsulates। कार्यान्वयन लगभग ArrayList कार्यान्वयन से मेल खाता है, जिसमें से समवर्ती संशोधन के लिए सभी संशोधित तरीकों और जांचों को फेंक दिया गया है।

toList और contentEquals कार्यान्वयन भी काफी तुच्छ है। toList विधि एक रैपर देता है जो किसी दिए गए toList को पुनर्निर्देशित करता है, डेटा की धीमी प्रतिलिपि उत्पन्न नहीं होती है।

mutable विधि इस MutableListImpl के आधार पर बनाया गया MutableListImpl देता है। डाटा कॉपी तब तक नहीं होती है जब तक कि प्राप्त MutableList पर किसी भी संशोधित विधि को नहीं बुलाया जाता है।

MutableListImpl

ImmutableList और List लिंक Encapsulates। एक वस्तु बनाते समय, इन दोनों में से केवल एक लिंक हमेशा भरा रहता है, दूसरा null रहता है।

 protected ImmutableList<E> immutable; protected List<E> list; 

यदि यह null नहीं है, और अन्यथा List , अपरिवर्तनीय विधियों को ImmutableList पुनर्निर्देशित करता है।

शुरुआती तरीकों को संशोधित करने के बाद, सूचियों को पुर्ननिर्देशित करता है

 protected void beforeChange() { if (list == null) { list = new ArrayList<>(immutable.toList()); } immutable = null; } 

snapshot विधि इस तरह दिखती है:

 public ImmutableList<E> snapshot() { if (immutable != null) { return immutable; } immutable = InternalUtils.convertToImmutableList(list); if (immutable != null) { //    //   ,  . //     immutable     . list = null; return immutable; } immutable = InternalUtils.copyToImmutableList(list); return immutable; } 

releaseSnapshot और contentEquals कार्यान्वयन का releaseSnapshot तुच्छ है।

यह दृष्टिकोण आपको "साधारण" उपयोग के दौरान डेटा की प्रतियों की संख्या को कम करने की अनुमति देता है, तेजी से रूपांतरण के साथ प्रतियों को प्रतिस्थापित करता है।

फास्ट सूची रूपांतरण

ArrayList या Arrays$ArrayList वर्गों ( Arrays.asList() पद्धति का परिणाम Arrays.asList() लिए तेज़ रूपांतरण संभव है। व्यावहारिक रूप से, अधिकांश मामलों में, यह इन वर्गों के ठीक विपरीत है।

इन वर्गों के अंदर तत्वों की एक सरणी होती है। एक त्वरित रूपांतरण का सार प्रतिबिंबों के माध्यम से इस सरणी के लिए एक संदर्भ प्राप्त करना है (यह एक निजी क्षेत्र है) और इसे खाली सरणी के संदर्भ में बदलें। यह सुनिश्चित करता है कि सरणी का एकमात्र संदर्भ हमारी वस्तु के साथ बना रहे, और सरणी अपरिवर्तित रहे।

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

समतुल्य / हैशकोड की समस्या

जावा संग्रह equals और hashCode विधियों को लागू करने के लिए एक बहुत ही अजीब दृष्टिकोण का उपयोग करता है।

तुलना सामग्री के अनुसार की जाती है, जो तर्कसंगत लगती है, लेकिन सूची के वर्ग को ध्यान में नहीं रखा जाता है। इसलिए, उदाहरण के लिए, एक ही सामग्री के साथ ArrayList और LinkedList समान होंगे।

 public boolean equals(Object o) { if (o == this) return true; if (!(o instanceof List)) return false; ListIterator<E> e1 = listIterator(); ListIterator e2 = ((List) o).listIterator(); while (e1.hasNext() && e2.hasNext()) { E o1 = e1.next(); Object o2 = e2.next(); if (!(o1==null ? o2==null : o1.equals(o2))) return false; } return !(e1.hasNext() || e2.hasNext()); } public int hashCode() { int hashCode = 1; for (E e : this) hashCode = 31*hashCode + (e==null ? 0 : e.hashCode()); return hashCode; } 

इस प्रकार, अब पूरी तरह से सभी List कार्यान्वयनों को समान समान कार्यान्वयन की आवश्यकता equals है (और, परिणामस्वरूप, hashCode )। अन्यथा, आप ऐसे हालात प्राप्त कर सकते हैं जब a.equals(b) && !b.equals(a) , जो अच्छा नहीं है। ऐसी ही स्थिति Set और Map ।

पुस्तकालय के लिए आवेदन में, इसका मतलब है कि MutableList के लिए समान और MutableList कार्यान्वयन पूर्वनिर्धारित है, और इस तरह के कार्यान्वयन में, समान सामग्री के साथ MutableList और MutableList समान नहीं हो सकते हैं (क्योंकि MutableList एक List नहीं है)। इसलिए, contentEquals तुलना करने के लिए contentEquals विधियाँ जोड़ी गई हैं।

hashCode के लिए equals और hashCode विधियों का कार्यान्वयन AbstractList से संस्करण के समान है, लेकिन ReadOnlyList द्वारा List के प्रतिस्थापन के साथ।

कुल मिलाकर

पुस्तकालय स्रोतों और परीक्षणों को मावेन परियोजना के रूप में संदर्भ द्वारा पोस्ट किया जाता है ।

यदि कोई पुस्तकालय का उपयोग करना चाहता है, तो उसने "फीडबैक" के लिए एक समूह बनाया है।

पुस्तकालय का उपयोग करना बहुत स्पष्ट है, यहाँ एक छोटा उदाहरण है:

 private boolean myBusinessProcess() { List<Entity> tempFromDb = queryEntitiesFromDatabase("SELECT * FROM my_table"); ImmutableList<Entity> fromDb = Mutabor.convertToImmutableList(tempFromDb); if (fromDb.isEmpty() || !someChecksPassed(fromDb)) { return false; } //... MutableList<Entity> list = fromDb.mutable(); //time to change list.remove(1); ImmutableList<Entity> processed = list.snapshot(); //time to change ended //... if (!callSideLibraryExpectsListParameter(processed.toList())) { return false; } for (Entity entity : processed) { outputToUI(entity); } return true; } 

सभी को शुभकामनाएँ! बग रिपोर्ट भेजें!