क्या किसी ImmutableMap या मैप को वापस करना बेहतर है?

Question 1

मान लीजिए कि मैं एक ऐसी विधि लिख रहा हूं, जिसमें एक नक्शा वापस आ जाना चाहिए । उदाहरण के लिए:

public Map<String, Integer> foo() {
  return new HashMap<String, Integer>();
}

कुछ समय के लिए इसके बारे में सोचने के बाद, मैंने फैसला किया है कि इस मैप को बनाते समय इसे संशोधित करने का कोई कारण नहीं है। इस प्रकार, मैं एक ImmutableMap वापस करना चाहूंगा ।

public Map<String, Integer> foo() {
  return ImmutableMap.of();
}

क्या मुझे रिटर्न टाइप को जेनेरिक मैप के रूप में छोड़ना चाहिए, या क्या मुझे यह निर्दिष्ट करना चाहिए कि मैं एक इम्यूटेबल मैप लौटा रहा हूं?

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

Question 2

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

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

मेरा निष्कर्ष यह होगा कि स्पष्ट अच्छा है, चीजों को मौका न छोड़ें।

Question 3

आपको ImmutableMapअपने रिटर्न प्रकार के रूप में होना चाहिए । Mapऐसे तरीके शामिल हैं जो ImmutableMap(जैसे put) के कार्यान्वयन से समर्थित नहीं हैं और में चिह्नित @deprecatedहैं ImmutableMap।

पदावनत विधियों का उपयोग करने पर एक संकलक चेतावनी होगी और अधिकांश आईडीई चेतावनी देगा जब लोग पदावनत विधियों का उपयोग करने का प्रयास करेंगे।

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

Question 4

दूसरी ओर, अगर मैं इसे इस तरह छोड़ दूंगा, तो अन्य डेवलपर्स इस तथ्य को याद कर सकते हैं कि यह ऑब्जेक्ट अपरिवर्तनीय है।

आपको यह उल्लेख करना चाहिए कि javadocs में। डेवलपर्स उन्हें पढ़ते हैं, आप जानते हैं।

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

कोई भी डेवलपर अपने कोड को अप्रकाशित नहीं करता है। और जब वह इसका परीक्षण करता है, तो उसे एक अपवाद मिलता है जहां वह न केवल कारण देखता है, बल्कि उस फ़ाइल और लाइन को भी देखता है जहां उसने एक अपरिवर्तनीय मानचित्र पर लिखने की कोशिश की थी।

हालांकि ध्यान दें, केवल वही Mapअपरिवर्तनीय होगा, न कि उसमें मौजूद वस्तुएं।

Question 5

अगर मैं इसे इस तरह छोड़ दूंगा, तो अन्य डेवलपर्स इस तथ्य को याद कर सकते हैं कि यह ऑब्जेक्ट अपरिवर्तनीय है

यह सच है, लेकिन अन्य डेवलपर्स को अपने कोड का परीक्षण करना चाहिए और यह सुनिश्चित करना चाहिए कि यह कवर किया गया है।

फिर भी आपके पास इसे हल करने के लिए 2 और विकल्प हैं:

जावदोक का उपयोग करें
```
@return a immutable map
```
वर्णनात्मक विधि नाम का चयन करें
```
public Map<String, Integer> getImmutableMap()
public Map<String, Integer> getUnmodifiableEntries()
```
एक ठोस उपयोग के मामले के लिए आप बेहतर तरीकों का नाम भी दे सकते हैं। उदाहरण के लिए
```
public Map<String, Integer> getUnmodifiableCountByWords()
```

आप और क्या कर सकते हैं?!

आप वापसी कर सकते हैं

प्रतिलिपि
```
private Map<String, Integer> myMap;

public Map<String, Integer> foo() {
  return new HashMap<String, Integer>(myMap);
}
```
इस दृष्टिकोण का उपयोग किया जाना चाहिए यदि आप उम्मीद करते हैं कि बहुत सारे ग्राहक मानचित्र को संशोधित करेंगे और जब तक कि मानचित्र में केवल कुछ प्रविष्टियां न हों।
CopyOnWriteMap

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

इस मामले में आपको अपने नक्शे के चारों ओर एक पतली आवरण की आवश्यकता होती है, जो कि म्यूटेटिव ऑपरेशंस को छोड़कर अंतर्निहित मानचित्र में सभी विधि चालन को दर्शाता है। यदि एक म्यूटेटिव ऑपरेशन का आह्वान किया जाता है, तो यह अंतर्निहित मानचित्र की एक प्रति बनाता है और आगे के सभी चालान इस प्रति को सौंप दिए जाएंगे।

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

दुख की बात है कि जावा में ऐसा नहीं है CopyOnWriteMap। लेकिन हो सकता है कि आप किसी तीसरे पक्ष को खोज लें या उसे स्वयं लागू कर दें।

अंत में आपको यह ध्यान रखना चाहिए कि आपके नक्शे में तत्व अभी भी परिवर्तनशील हो सकते हैं।

Question 6

निश्चित रूप से एक ImmutableMap लौटाएँ, औचित्य:

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

Question 7

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

public ImmutableMap<String, Integer> foo() {
    return ImmutableMap.copyOf(internalMap);
}

अमरूद हर बार नक्शे की नकल करेगा। वह धीमा है। लेकिन अगर internalMapपहले से ही एक था ImmutableMap, तो यह पूरी तरह से ठीक है।

यदि आप अपनी कक्षा को लौटने के लिए प्रतिबंधित नहीं करते हैं ImmutableMap, तो आप इसके बदले वापसी कर सकते हैं Collections.unmodifiableMap:

public Map<String, Integer> foo() {
    return Collections.unmodifiableMap(internalMap);
}

ध्यान दें कि यह मानचित्र में एक अपरिवर्तनीय दृश्य है । यदि internalMapपरिवर्तन होता है, तो इसकी एक कैश्ड प्रति होगी Collections.unmodifiableMap(internalMap)। मैं अभी भी इसे पाने वालों के लिए पसंद करता हूं।

Question 8

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

public Integer fooOf(String key) {
    return map.get(key);
}

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

public Stream<Map.Entry<String, Integer>> foos() {
    map.entrySet().stream()
}

फिर ग्राहक अपनी जरूरत के अनुसार अपना अपरिवर्तनीय या परिवर्तनशील मानचित्र बना सकता है या प्रविष्टियों को अपने मानचित्र में जोड़ सकता है। यदि ग्राहक को यह जानना होगा कि क्या मूल्य मौजूद है, तो इसके बजाय वैकल्पिक लौटाया जा सकता है:

public Optional<Integer> fooOf(String key) {
    return Optional.ofNullable(map.get(key));
}

Question 9

अपरिवर्तनीय मानचित्र एक प्रकार का मानचित्र है। इसलिए मैप का रिटर्न प्रकार छोड़ना ठीक है।

यह सुनिश्चित करने के लिए कि उपयोगकर्ता लौटी हुई वस्तु को संशोधित नहीं करते हैं, विधि का प्रलेखन लौटी हुई वस्तु की विशेषताओं का वर्णन कर सकता है।

Question 10

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

निम्नलिखित लेख पर एक नज़र डालें:

एंडी गिब्सन