मुझे लगता है कि शीर्षक खुद के लिए बोलता है - मुझे एक इंटरफ़ेस क्यों लिखना चाहिए और फिर एक ठोस वर्ग को लागू करना चाहिए यदि उस इंटरफ़ेस के केवल 1 ठोस कार्यान्वयन के लिए कभी भी हो?क्या मुझे अभी भी इंटरफ़ेस को कोड करना चाहिए, भले ही मैं कभी भी एक कार्यान्वयन करने जा रहा हूं?
मुझे लगता है कि आप नहीं करना चाहिए;)
इसी इंटरफेस के साथ अपने सभी वर्गों और परछाई की कोई जरूरत नहीं है।
भले ही आप बाद में अधिक कार्यान्वयन करने जा रहे हैं, आप हमेशा आवश्यक होने पर इंटरफ़ेस निकाल सकते हैं।
सवाल यह है कि, यदि केवल एक ठोस कार्यान्वयन होने वाला है, तो क्या एक इंटरफ़ेस होना चाहिए?
सही, लेकिन यह एक सवाल है, जवाब नहीं। –
@ जेसन: एक अच्छा सवाल अक्सर सबसे अच्छा जवाब होता है (लड़का मैं इसे एक प्रश्न के रूप में लिखने के लिए प्रेरित था ;-)) –
यह ग्रैन्युलरिटी का प्रश्न है। आप अनावश्यक इंटरफेस के साथ अपने कोड को अव्यवस्थित नहीं कर सकते हैं लेकिन वे परतों के बीच सीमाओं पर उपयोगी हैं।
किसी दिन आप इस कक्षा पर निर्भर कक्षा का परीक्षण करने का प्रयास कर सकते हैं। तो यह अच्छा है कि आप इसे नकल कर सकते हैं।
मैं लगातार बना रहा हूं और इंटरफेस को हटा रहा हूं। कुछ प्रयास के लायक नहीं थे और कुछ वास्तव में जरूरी हैं। मेरा अंतर्ज्ञान ज्यादातर सही है लेकिन कुछ रिफैक्टरिंग आवश्यक हैं।
इन दिनों हम कक्षाओं को नकल करने के लिए मॉकिटो (या समान परीक्षण ढांचे) का उपयोग करते हैं । क्या उन दिनों के लिए इंटरफेस बनाने का यह अभ्यास था जब आपको मैन्युअल रूप से स्टब क्लास बनाना था, और निर्भरता का नकल करने के लिए अपने यूनिट टेस्ट (केवल मॉकिटो का उपयोग करने के बजाय) पर निर्भरता इंजेक्ट करना था? इससे मुझे बहुत समझ आती है अगर यह मामला – Atif
प्रसिद्ध अंतिम शब्द
यह बहुत खर्च नहीं करना पड़ता एक इंटरफेस बनाने के लिए == "ही कभी एक कार्यान्वयन करने जा" और फिर इसे से एक ठोस वर्ग निकाले जाते हैं। ऐसा करने की प्रक्रिया आपको अपने डिजाइन पर पुनर्विचार कर सकती है और अक्सर बेहतर अंत उत्पाद की ओर ले जाती है। और एक बार ऐसा करने के बाद, यदि आप कभी भी उन शब्दों को खा रहे हैं - जैसे अक्सर होता है - आपको इसके बारे में चिंता करने की ज़रूरत नहीं होगी। आप पहले ही सेट हैं जबकि अन्यथा आपके पास करने के लिए refactoring का ढेर है और यह एक दर्द होने वाला है।
स्पष्ट करने के लिए संपादित: मैं इस धारणा पर काम कर रहा हूं कि यह वर्ग अपेक्षाकृत दूर और व्यापक रूप से फैल जाएगा। यदि यह एक ही पैकेज में एक या दो अन्य वर्गों द्वारा उपयोग की जाने वाली एक छोटी उपयोगिता कक्षा है तो हाँ, इसके बारे में चिंता न करें। यदि यह एक वर्ग है जो एकाधिक पैकेजों में एकाधिक पैकेजों में उपयोग किया जा रहा है तो मेरा पिछला उत्तर लागू होता है। अपने प्रश्न का
आपकी सलाह के बाद, आपके पास व्यर्थ इंटरफेस और कारखानों का एक बड़ा ढेर होगा, और यह दर्द होगा। "एक इंटरफेस के लिए प्रोग्रामिंग" के लिए सिर्फ अपनी कक्षा की गिनती को त्रिकोणीय करना * * आपको रखरखाव में काफी महंगा लगेगा। –
@ माइकल बोर्गवर्ड: हाँ, मुझे एहसास हुआ कि मैं वर्ग पैमाने की संभावित झूठी धारणा पर काम कर रहा था। * हर * छोटी कक्षा के लिए इंटरफेस खराब है। लेकिन अधिक महत्वपूर्ण लोगों के लिए इंटरफेस जो चारों ओर फैल रहे हैं वह अच्छा है - भले ही आपको लगता है कि आपके पास कभी भी एक कार्यान्वयन होगा। उस पर गलत सिद्ध होना इतना आसान है कि यह भी मजेदार नहीं है - और रिफैक्टरिंग हमेशा आसान नहीं होती है। –
दो कुछ हद तक परस्पर विरोधी जवाब:
अधिकांश सिस्टम (यहां तक कि "फेंकने वाला कोड") विकसित होता है और उनके मूल डिजाइन के लिए जो कुछ भी उनके लिए लक्षित है, उससे बहुत दूर बदल जाता है। इंटरफेस उन्हें युग्मन को कम करके flexibly विकसित करने में मदद करते हैं।
यदि आप इन सभी सवालों के ईमानदारी से "नहीं" का उत्तर दे सकते हैं, तो एक इंटरफ़ेस अधिक हो सकता है। हो सकता है। लेकिन फिर, अप्रत्याशित परिणाम प्रोग्रामिंग में खेल का नाम हैं।
प्रश्न यह होना चाहिए: "आप कभी भी कैसे सुनिश्चित हो सकते हैं कि केवल एक ठोस कार्यान्वयन होने वाला है?"
आप पूरी तरह से कैसे सुनिश्चित हो सकते हैं?
जब तक आपने इसे सोचा था, तब तक आप पहले ही इंटरफ़ेस बना चुके हैं और बिना किसी धारणा के आपके रास्ते पर रह सकते हैं जो गलत हो सकता है।
आज के कोडिंग टूल (जैसे रिशेर्पर) के साथ, वास्तव में आपके वर्गों के साथ इंटरफेस बनाने और बनाए रखने में अधिक समय नहीं लगता है, जबकि यह पता चलता है कि अब आपको अतिरिक्त कार्यान्वयन की आवश्यकता है और सभी ठोस संदर्भों को प्रतिस्थापित करने के लिए लंबे समय तक और कोई मजा नहीं है - मेरा विश्वास करो।
सार्वजनिक कार्यों को निर्दिष्ट करके आपको यह तय करने की आवश्यकता है कि प्रोग्रामिंग इंटरफ़ेस क्या है। यदि आप इसका अच्छा काम नहीं करते हैं, तो कक्षा का उपयोग करना मुश्किल होगा।
इसलिए, यदि आप बाद में तय आप एक औपचारिक इंटरफेस बनाने की जरूरत है, तो आप डिजाइन जाने के लिए तैयार होना चाहिए।
तो, आप एक इंटरफेस डिजाइन करने के लिए की जरूरत है, लेकिन आप एक इंटरफेस के रूप में यह लिखने के लिए और उसके बाद इसे लागू की जरूरत नहीं है। http://www.infoq.com/presentations/integration-tests-scam
वहाँ एक वर्ग के लिए 3 कारण हैं::
इस का एक बहुत InfoQ पर बात करते हैं एक Rainsberger से लिया जाता है
अधिकांश सेवाओं को एच एवी इंटरफेस। यह एक सीमा बनाता है, कार्यान्वयन छुपाता है, और आपके पास पहले से ही दूसरा ग्राहक है; सभी परीक्षण जो उस सेवा के साथ बातचीत करते हैं।
मूल रूप से अगर तुम कभी एक इकाई परीक्षण में यह पता उपहास करने के लिए चाहते हो जाएगा यह एक अंतरफलक होना चाहिए। आप गोना जो लोग YAGNI दृष्टिकोण की वकालत के अनुसार से Wikipedia
की आवश्यकता नहीं है, यह, प्रलोभन कोड उस पल में आवश्यक नहीं है लिखने के लिए, लेकिन भविष्य में हो सकता है, है -
YAGNI निम्नलिखित नुकसान:
* The time spent is taken from adding, testing or improving necessary functionality.
* The new features must be debugged, documented, and supported.
* Any new feature imposes constraints on what can be done in the future, so an unnecessary feature now may prevent implementing a necessary feature later.
* Until the feature is actually needed, it is difficult to fully define what it should do and to test it. If the new feature is not properly defined and tested, it may not work right, even if it eventually is needed.
* It leads to code bloat; the software becomes larger and more complicated.
* Unless there are specifications and some kind of revision control, the feature may not be known to programmers who could make use of it.
* Adding the new feature may suggest other new features. If these new features are implemented as well, this may result in a snowball effect towards creeping featurism.
मैं अपना कोड बनाने के लिए एक परीक्षण संचालित दृष्टिकोण का उपयोग करता हूं। यह अक्सर मुझे इंटरफेस बनाने के लिए नेतृत्व करेगा जहां मैं अपने परीक्षण स्थिरता के हिस्से के रूप में एक नकली या डमी कार्यान्वयन की आपूर्ति करना चाहता हूं।
मैं सामान्य रूप से कोई भी कोड नहीं बनाऊंगा जब तक कि मेरे परीक्षणों में कुछ प्रासंगिकता न हो, और चूंकि आप आसानी से एक इंटरफ़ेस का परीक्षण नहीं कर सकते हैं, केवल एक कार्यान्वयन, जिससे मुझे इंटरफेस बनाने की ओर ले जाता है यदि मुझे परीक्षण मामले के लिए निर्भरता की आपूर्ति करते समय उन्हें आवश्यकता होती है ।
मैं कभी-कभी डुप्लिकेशंस को हटाने या कोड पठनीयता में सुधार करने के लिए रीफैक्टरिंग करते समय इंटरफ़ेस भी बनाउंगा।
यदि आप पाते हैं कि आपको बाद में आवश्यकता है तो आप इंटरफ़ेस को पेश करने के लिए हमेशा अपने कोड को दोबारा कर सकते हैं।
यह एकमात्र अपवाद होगा यदि मैं किसी तृतीय पक्ष को रिलीज के लिए एपीआई डिज़ाइन कर रहा था - जहां एपीआई परिवर्तन करने की लागत अधिक है। इस मामले में मैं भविष्य में होने वाले परिवर्तनों के प्रकार की भविष्यवाणी करने की कोशिश कर सकता हूं और भविष्य में असंगत परिवर्तनों को कम करने के लिए अपना एपीआई बनाने के तरीकों का काम कर सकता हूं।
एक चीज जिसे अभी तक कोई भी उल्लेख नहीं किया गया है, यह है कि कभी-कभी यह निर्भरता मुद्दों से बचने के लिए आवश्यक है। आप कुछ निर्भरताओं के साथ एक आम परियोजना में इंटरफेस और कई निर्भरताओं के साथ एक अलग परियोजना में कार्यान्वयन कर सकते हैं।
+100 यदि मैं कर सकता, तो यह हर जगह अप्रयुक्त इंटरफेस बनाने के लिए प्रति-उत्पादक है। जब (यदि) आपको इसकी आवश्यकता होती है, तो यह एक प्रतिबिंबित करने और निकालने के लिए तुच्छ है। – slf
सहमत हुए। एक कार्यान्वयन के साथ एक आंतरिक वर्ग को एक इंटरफेस की आवश्यकता नहीं है। इंटरफ़ेस * दिलचस्प हो सकता है यदि यह बाहरी एपीआई का हिस्सा बनता है - इसलिए इंटरफ़ेस का उपयोग करने वाले लोगों को जिन तरीकों से आपने भविष्यवाणी नहीं की है, वे आपके कार्यान्वयन को बढ़ाने के लिए मजबूर नहीं हैं ... –
परीक्षण के बारे में कैसे? मेरा मतलब है, EasyMock केवल इंटरफेस के लिए mocks बनाता है। – folone