OOP: इंटरफ़ेस आधारित एक की तुलना में कक्षा के डिजाइन में कौन सी स्थितियाँ बेहतर हैं?


10

मैं JDOM की वेबसाइट पढ़ रहा था ।

JDOM API को इंटरफेस के बजाय कंक्रीट कक्षाओं के संदर्भ में क्यों परिभाषित किया गया है?

जेसन हंटर JDOM के लिए एक इंटरफ़ेस आधारित एपीआई के खिलाफ तर्कों को सारांशित करता है:

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

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

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

कुछ स्थानों पर ठोस कक्षाओं का उपयोग उचित हो सकता है। क्या कोई सामान्य वर्ग की समस्याएं हैं जिनके लिए डिजाइन में कंक्रीट कक्षाओं का उपयोग करना ठीक है?


आप इस पर एक नज़र रखना चाहते हैं: javaworld.com/javaworld/jw-09-2001/jw-0921-interface.html
NoChance

आप "अपनी सीमाओं को
henginy

"हमने किया, और डिजाइन इसके लिए बहुत बेहतर था।" - यह कैसे बेहतर था?
कोडार्ट

जवाबों:


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

[संपादित करें] JDOM की वेबसाइट java.io.File को एक उदाहरण के रूप में लेती है, लेकिन यह निश्चित रूप से एक इंटरफ़ेस आधारित डिजाइन है क्योंकि एक java.io.File उदाहरण को हेरफेर कर सकता है जैसे कि यह केवल एक सीरियल है। इस स्थिति में केवल "रचनाकारों" को ठोस वर्ग का पता होगा


"मूल्य वस्तु" की दो परस्पर विरोधी परिभाषाएँ तैर रही हैं। आपका कम आम लगता है, जिसे "डेटा ट्रांसफर ऑब्जेक्ट" के रूप में भी जाना जाता है।
माइकल बोर्गवर्ड

@MichaelBorgwardt Thx इसे इंगित करने के लिए क्योंकि मेरा मतलब केवल "डेटा ट्रांसफर ऑब्जेक्ट" नहीं था: मैं अपना उत्तर संपादित करता हूं
मैथियास जोआन

1
एलएसपी किसी भी उप-संबंध संबंध, इंटरफ़ेस कार्यान्वयन और विरासत के लिए महत्वपूर्ण है।

3

JDOM साइट से:

जेसन (हंटर) ने 2000 की शुरुआत में ब्रेट मैकलॉघलिन के साथ JDOM प्रोजेक्ट की स्थापना की

यानी, उस समय के आसपास जावा 1.3 को पेश किया जा रहा था। जावा विकास के समय परिपक्वता के रास्ते में कुछ भी नहीं था - सबसे अनुभवी डेवलपर्स के पास केवल 4 साल का था जावा का सबसे अच्छा उपयोग करते हुए। व्यापक रूप से इस्तेमाल किए गए IoC कंटेनर, कोई हाइबरनेट नहीं थे। Apache Struts बस इसकी शुरुआत हो रही थी।

जो सभी कहना है कि जेसन और ब्रेट सिर्फ गलत थे। बहुत सारे लोगों ने अभी तक इसे "प्राप्त नहीं" किया है। यदि उनके पास C ++ पृष्ठभूमि है, तो ठीक है, आपको C ++ में इंटरफेस की आवश्यकता नहीं थी (ठीक है, वे वहां C ++ में थे, लेकिन आपको वास्तव में उनकी आवश्यकता नहीं थी, ठीक है?), क्यों जावा में उनका उपयोग किया जाता है? खैर, बहुत सारे अच्छे कारण हैं, जो दूसरे आपको निर्देशित कर सकते हैं।

वे निश्चित रूप से गलत थे

कुछ भी जो इंटरफेस के साथ किया जा सकता है, सबक्लासिंग के साथ किया जा सकता है

जावा कई वर्गों की विरासत की अनुमति नहीं देता है, लेकिन यह कई इंटरफेस के कार्यान्वयन की अनुमति देता है। जो वास्तविक अंतर ला सकता है।


3

कृपया याद रखें, आपके प्रश्न के संबंध में, कि सॉफ़्टवेयर डेवलपमेंट में किसी समस्या को हल करने के कई तरीके हैं, और यदि कुछ डेवलपर आपसे अलग तकनीक का उपयोग करते हैं, तो इसका मतलब यह नहीं है कि यह समाधान गलत है।

उन मामलों में से एक "इंटरफेस" बनाम (आधार) "कक्षाएं" है। ऐसी परिस्थितियां हैं जहां दोनों तकनीकों के साथ एक ही लक्ष्य प्राप्त किया जा सकता है।

चीजों को और अधिक जटिल बनाने के लिए, इंटरफेस के कई उपयोग हैं, सिर्फ उल्लेख करने के लिए:

  • एक "अनुबंध" या "विनिर्देश" को "कार्यान्वयन" के बिना डिजाइन करना है
  • अन्य, वर्गों के एक मौजूदा , नए, वर्ग या पदानुक्रम के लिए functionaluonality जोड़ने के लिए नहीं
  • पिछले के पूरक, विभिन्न वस्तुओं, प्रौद्योगिकियों, उदाहरण के लिए साझा पहुंच की अनुमति देने के लिए: एंटरप्राइज़ बीन्स, CORBA, COM, WebServices
  • कई विरासत का अनुकरण करने के लिए

आपका प्रश्न पहले बिंदु पर लागू होता है।

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

और, अन्य परिदृश्यों के लिए इंटरफेस छोड़ दें।

एक अच्छा उदाहरण विजेट्स (नियंत्रण) लाइब्रेरी हैं।

मेरा सुझाव है, कि अन्य प्रोग्रामिंग भाषाओं पर एक नज़र डालें कि वे कैसे इंटरफेस और कक्षाओं का उपयोग करते हैं जैसे: PHP, डेल्फी (ऑब्जेक्ट पास्कल), सी #।

चीयर्स।


1

एपीआई डिजाइन नियम वास्तव में एक विशिष्ट चीज हैं। मुझे यकीन नहीं है कि आपको उस एफएक्यू से कुछ भी निष्कर्ष निकालना चाहिए कि आपको अपने दिन-प्रतिदिन के कोड को कैसे डिज़ाइन करना चाहिए।

आपके नियमित कोड के लिए, यह अभी भी सही है कि आप इंटरफ़ेस या एब्स्ट्रैक्ट क्लास इनहेरिटेंस का उपयोग वेनिला इनहेरिटेंस आईएमओ की तुलना में अधिक बार करेंगे।

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

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


0

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

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.