जावा में क्लॉक अराउंड इमैटेबलिस्ट

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

(यह एक उत्तर लेख है, पहले मूल लेख पढ़ें।)

अनमॉडिबिलिस्टिक बनाम इम्यूटेबलिस्ट

पहला सवाल जो उठता है वह यह है: मुझे एक UnmodifiableList आवश्यकता क्यों है, अगर कोई ImmutableList ? चर्चा के परिणामस्वरूप, मूल लेख की टिप्पणियों में UnmodifiableList के अर्थ के बारे में दो विचार देखे गए हैं:

• विधि एक UnmodifiableList प्राप्त करती है, वह इसे स्वयं नहीं बदल सकती है, लेकिन यह जानती है कि सामग्री को दूसरे धागे से बदला जा सकता है (और यह जानता है कि इसे सही तरीके से कैसे संभालना है)
• अन्य सूत्र प्रभावित नहीं करते हैं, UnmodifiableList और ImmutableList एक विधि के लिए बराबर हैं, लेकिन UnmodifiableList अधिक "हल्के" के रूप UnmodifiableList उपयोग किया जाता है।

पहला विकल्प व्यवहार में बहुत कम लगता है। इस प्रकार, यदि आप ImmutableList का "आसान" कार्यान्वयन कर सकते हैं, तो UnmodifiableList बहुत आवश्यक नहीं हो जाता है। इसलिए, भविष्य में हम इसके बारे में भूल जाएंगे और केवल ImmutableList लागू करेंगे।

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

हम ImmutableList विकल्प को लागू करेंगे:

• एपीआई "रीडिंग" भाग में नियमित List एपीआई के समान होना चाहिए। "लेखन" भाग अनुपस्थित होना चाहिए।
• ImmutableList और List को वंशानुक्रम संबंधों से संबंधित नहीं होना चाहिए। ऐसा क्यों - मूल लेख को समझता है।
• यह ArrayList साथ सादृश्य द्वारा कार्यान्वयन करने के लिए समझ में आता है। यह सबसे आसान विकल्प है।
• कार्यान्वयन को जब भी संभव हो, सरणियों की नकल करने से बचना चाहिए।

इम्यूटेबलिस्ट कार्यान्वयन

सबसे पहले, हम एपीआई के साथ सौदा करते हैं। हम Collection और List इंटरफेस की जांच करते हैं और उनके "रीडिंग" भाग को हमारे नए इंटरफेस में कॉपी करते हैं।

 public interface ReadOnlyCollection<E> extends Iterable<E> { int size(); boolean isEmpty(); boolean contains(Object o); Object[] toArray(); <T> T[] toArray(T[] a); boolean containsAll(Collection<?> c); } public interface ReadOnlyList<E> extends ReadOnlyCollection<E> { E get(int index); int indexOf(Object o); int lastIndexOf(Object o); ListIterator<E> listIterator(); ListIterator<E> listIterator(int index); ReadOnlyList<E> subList(int fromIndex, int toIndex); } 

इसके बाद, ImmutableList वर्ग बनाएं। हस्ताक्षर ArrayList समान है (लेकिन List बजाय ReadOnlyList इंटरफ़ेस को लागू करता है)।

 public class ImmutableList<E> implements ReadOnlyList<E>, RandomAccess, Cloneable, Serializable 

हम ArrayList से कक्षा के कार्यान्वयन की नकल करते हैं और दृढ़ता से रिफ्लेक्टर करते हैं, "लेखन" भाग से संबंधित सभी चीजों को बाहर निकालते हैं, समवर्ती संशोधन के लिए जाँच करते हैं, आदि।

कंस्ट्रक्टर इस प्रकार होंगे:

 public ImmutableList() public ImmutableList(E[] original) public ImmutableList(Collection<? extends E> original) 

पहले एक खाली सूची बनाता है। दूसरा एरे को कॉपी करके लिस्ट बनाता है। यदि हम अपरिवर्तनीय हासिल करना चाहते हैं तो हम नकल किए बिना नहीं कर सकते। तीसरा अधिक दिलचस्प है। एक समान ArrayList निर्माता भी संग्रह से डेटा की प्रतिलिपि बनाता है। हम ऐसा ही करेंगे, जब तक कि orginal ArrayList या Arrays$ArrayList का एक उदाहरण है (यह वही है जो Arrays.asList() विधि द्वारा लौटाया गया है)। हम सुरक्षित रूप से मान सकते हैं कि ये मामले 90% कंस्ट्रक्टर कॉल को कवर करेंगे।

इन मामलों में, हम प्रतिबिंबों के माध्यम से original सरणी को "चोरी" करेंगे (आशा है कि यह गीगाबाइट संकेतन की नकल करने की तुलना में तेज है)। "चोरी" का सार:

• हम निजी क्षेत्र में आते हैं, जो सरणी को संग्रहीत करता है ( ArrayList.elementData )
• अपने आप को ऐरे से लिंक कॉपी करें
• स्रोत क्षेत्र शून्य में डाल दिया

 protected static final Field data_ArrayList; static { try { data_ArrayList = ArrayList.class.getDeclaredField("elementData"); data_ArrayList.setAccessible(true); } catch (NoSuchFieldException | SecurityException e) { throw new IllegalStateException(e); } } public ImmutableList(Collection<? extends E> original) { Object[] arr = null; if (original instanceof ArrayList) { try { arr = (Object[]) data_ArrayList.get(original); data_ArrayList.set(original, null); } catch (@SuppressWarnings("unused") IllegalArgumentException | IllegalAccessException e) { arr = null; } } if (arr == null) { //   ArrayList,      -  arr = original.toArray(); } this.data = arr; } 

एक अनुबंध के रूप में, हम मानते हैं कि जब निर्माता को बुलाया जाता है, तो उत्परिवर्तित सूची को एक ImmutableList में ImmutableList दिया जाता है। उसके बाद मूल सूची का उपयोग नहीं किया जा सकता है। उपयोग करने का प्रयास करते समय, एक NullPointerException आती है। यह सुनिश्चित करता है कि "चोरी हुई" सरणी नहीं बदलेगी और हमारी सूची वास्तव में अपरिवर्तनीय होगी (मामले को छोड़कर जब किसी को प्रतिबिंब के माध्यम से सरणी में मिलती है)।

अन्य वर्ग

मान लीजिए कि हम एक वास्तविक परियोजना में एक ImmutableList का उपयोग करने का निर्णय लेते हैं।

यह परियोजना पुस्तकालयों के साथ बातचीत करती है: उनसे प्राप्त होती है और उन्हें विभिन्न सूचियाँ भेजती है। अधिकांश मामलों में, ये सूचियाँ एक ArrayList होंगी। ImmutableList का वर्णित कार्यान्वयन ImmutableList परिणामी ArrayList को ImmutableList तेज़ी से परिवर्तित करने की अनुमति देता है। पुस्तकालयों को भेजी गई सूचियों के लिए रूपांतरण लागू करना भी आवश्यक है: List लिए ImmutableList । तेजी से रूपांतरण के लिए, आपको एक ImmutableList आवरण की आवश्यकता होती है जो List लागू करता है, अपवाद को सूची में लिखने की कोशिश करते समय फेंक देता है ( Collections.unmodifiableList समान Collections.unmodifiableList )।

इसके अलावा, परियोजना स्वयं किसी तरह सूचियों को संसाधित करती है। यह एक MutableList वर्ग बनाने के लिए समझ में आता है जो एक परिवर्तनशील सूची का प्रतिनिधित्व करता है, जो कि ArrayList पर आधारित कार्यान्वयन है। इस स्थिति में, आप सभी ArrayList को स्पष्ट रूप से इरादे की घोषणा करने वाले वर्ग के लिए प्रतिस्थापित करके परियोजना को फिर से शुरू कर सकते हैं: या तो MutableList या MutableList ।

MutableList से MutableList और इसके विपरीत में एक त्वरित रूपांतरण की आवश्यकता है। उसी समय, ArrayList को ImmutableList में रूपांतरित करने के विपरीत, हम अब मूल सूची को खराब नहीं कर सकते।

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

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

कुल मिलाकर

कोड के रूप में प्रयोग के परिणाम यहां पोस्ट किए गए हैं

ImmutableList ही ImmutableList , जिसे "अन्य वर्गों" खंड (अभी तक नहीं?) में वर्णित किया गया है।

हम मान सकते हैं कि मूल लेख, "जावा में अपरिवर्तनीय संग्रह नहीं होगा" का आधार गलत है।

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

एक बात: अगर कोई इच्छा है ... (ताहिती, ताहिती ... हम किसी ताहिती में नहीं थे! वे हमें यहाँ अच्छी तरह से खिलाते हैं।)