2008-10-07 11 views
8

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

उदाहरण के लिए, मान लें कि मैं एक एडाप्टर पैटर्न को कार्यान्वित कर रहा हूं जहां मैं एक अपरिवर्तनीय वस्तु को लपेटकर java.util.Map लागू करता हूं और इसके डेटा को कुंजी/मूल्य जोड़े के रूप में उजागर करके java.util.Map लागू करता हूं। इस मामले में विधियों को डाल दिया गया है और सभी को समझ में नहीं आता है क्योंकि मेरे पास अंतर्निहित वस्तु को संशोधित करने का कोई तरीका नहीं है। तो सवाल यह है कि उन तरीकों को क्या करना चाहिए?

उत्तर

17

इंटरफ़ेस के अर्थशास्त्र के अनुसार लागू नहीं किया जा सकता कोई भी तरीका UnsupportedOperationException फेंक देना चाहिए।

+0

असमर्थितऑपरेशन अपवाद आमतौर पर जाने का तरीका है, जब तक कि आपको पता न हो कि विधि को वैसे भी कहा जाएगा, और आप "नो-ऑप" के अधिक से अधिक करना चाहते हैं, जिसमें मामला शून्य या समान होता है जो आप कर सकते हैं । – skaffman

+0

अच्छी तरह से ... ऐसा लगता है कि आपने वहां अपने स्वयं के प्रश्न का उत्तर दिया, माइक .. – Sandman

+0

तथ्य यह है कि आपको ऐसा करने की आवश्यकता है एक डिजाइन मुद्दा माना जा सकता है। – Aidos

10

यह आपके व्यापार के मामले पर निर्भर करता है। 2 विकल्प:

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

ध्यान दें कि जावा लाइब्रेरी read-only संग्रह के विशिष्ट मामले में अपवाद मार्ग चलाती है।


यह नीचे दिया गया था कि असमर्थितऑपरेशन अपवाद जावा संग्रह ढांचे का एक हिस्सा है। यदि आपकी स्थिति संग्रह से बाहर है, और अर्थशास्त्र आपको परेशान करते हैं, तो आप अपना खुद का NotImplementedException रोल कर सकते हैं, या यदि आप पहले ही कॉमन्स-लैंग का उपयोग कर रहे हैं, तो आप theirs का उपयोग कर सकते हैं।

3

आपका दो विकल्प वास्तव में ही कर रहे हैं:

  1. कुछ न करें।
  2. अपवाद फेंको।

दोनों के नुकसान हैं। पहले मामले में, एक खाली विधि करके, आप प्रोग्रामर को अपने डेटा के साथ कुछ सोचने में गुमराह कर सकते हैं। दूसरा मामला इंटरफेस में अंतर्निहित बहुरूपता के पूरे विचार को तोड़ देता है।

2

ध्यान दें कि असमर्थितऑपरेशन अपवाद केवल जावा संग्रह फ्रेमवर्क की विशेष संपत्ति के कारण ठीक है, कि कार्यान्वयन को इंटरफ़ेस के कार्यान्वयन भाग को "गुमराह करने" की अनुमति है क्योंकि वे अपरिवर्तनीय हैं।

तो यह() (सभी म्यूटेटर विधियों को एक ही काम करने के लिए मानते हैं) के लिए ठीक है, लेकिन आकार() विधि से असमर्थितऑपरेशन अपवाद को फेंकने वाला एक मानचित्र तोड़ा जाएगा। यदि आप एक प्रकार का नक्शा लागू करने की कोशिश कर रहे हैं जो यह नहीं जानता कि यह कितना बड़ा है, तो आप परेशानी में पड़ सकते हैं (हालांकि कभी-कभी आप Integer.MAX_VALUE वापस कर सकते हैं)।

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

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

5

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

+0

आप अभी भी एक ऐसी समस्या में भाग लेंगे जहां एपीआई को पढ़ने/लिखने के इंटरफ़ेस की परिस्थितियों में भी आवश्यकता होगी जहां केवल पढ़ने के लिए ही किया जाएगा। लेकिन मैं सहमत हूं, लचीलापन अच्छा होगा। –

+0

यदि यह डिज़ाइन निर्णय लिया गया था, तो यह संग्रह API एक अपठनीय गड़बड़ी समाप्त कर दिया होगा। –

+0

जावा के विशिष्ट मामले में समस्या इंटरफेस के साथ नहीं आती है, लेकिन सारकोलेक्शन इत्यादि के साथ आप सारस्ट्रोकोलेक्शन और सारस्ट्रॉक्कोलेक्शन दोनों से प्राप्त नहीं हो सकते हैं, इसलिए कक्षा पदानुक्रम शीर्ष पर दो में विभाजित किया जाएगा। वेक्टर और ReadOnlyVector बहुत दूर से संबंधित होगा। –

संबंधित मुद्दे

 संबंधित मुद्दे