2012-03-20 7 views
9

के रूप में रखना चाहिए यदि मैं ITestInterface इंटरफ़ेस को परिभाषित करता हूं और फिर तुरंत उस वर्ग को बनाता हूं जो किसी एप्लिकेशन के उपयोग के लिए उस इंटरफ़ेस को लागू करता है, तो उसी नामस्थान में कक्षा और इंटरफ़ेस रखना ठीक है या वे अलग होना चाहिए। यानी Test.Interfaces और Test.Interfaces.Implementationक्या मुझे अपनी इंटरफ़ेस परिभाषा को उसी कार्यान्वयन में

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

यह विशेष रूप से सी # से संबंधित है, हालांकि मुझे लगता है कि यह किसी भी भाषा को कवर कर सकता है।

+1

टेस्ट। इंटरफेस। कार्यान्वयन थोड़े विरोधाभासी प्रतीत होता है कि इंटरफेस और कार्यान्वयन पारस्परिक रूप से अनन्य हैं। – Robbie

+4

मैं उन चीज़ों के प्रकार के आधार पर नामस्थानों को व्यवस्थित नहीं करता, बल्कि उनके उद्देश्य से। – davisoa

उत्तर

13

.NET पूर्वनिर्धारित कक्षाओं के स्थापित सम्मेलनों का उपयोग करना शायद बेहतर है। उदाहरण के लिए, System.Collections.Generic नामस्थान में देखकर हम देख सकते हैं कि IDictionary और Dictionary दोनों हैं। तो शायद उन्हें एक ही नामस्थान में डालने का सबसे अच्छा विचार है।

इसके अलावा, चूंकि इंटरफेस और कार्यान्वयन दोनों ही एक ही उद्देश्य की सेवा करते हैं, इसलिए उन्हें समान नामस्थान में समूह करना बेहतर होता है।

+0

हाँ, यह पुष्टि है कि मैं देख रहा था, चीयर्स। – dreza

2

सिस्टम। चयन। एररेलिस्ट सिस्टम लागू करता है। चयन। सूची। यदि माइक्रोसॉफ्ट ऐसा करता है, तो आप क्यों नहीं?

+1

क्योंकि http: //en.wikipedia।संगठन/विकी/Cargo_cult_programming –

+0

@Tim मैं आपकी प्रासंगिकता को देखने में विफल रहता हूं। सवाल यह था कि इंटरफ़ेस कहां रखा जाए, गीले नहीं, इसकी आवश्यकता थी। –

1

यह एक बहुत ही अमूर्त सवाल है। इंटरफ़ेस का कारण क्या है? क्या यह एक सार्वजनिक एपीआई/ढांचा या एक साधारण आवेदन है? क्या आप एक ही इंटरफेस के कई कार्यान्वयन करने जा रहे हैं?

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

2

यह विशेष रूप से सी # से संबंधित है, हालांकि मुझे लगता है कि यह भाषा को कवर कर सकता है।

जावा में यह एक ही पैकेज में दो रखने के लिए सामान्य है। एक अपवाद जो मैं सोच सकता हूं, उसके तहत उप-पैकेजों में एक डीएओ इंटरफेस और उसके तहत उप-पैकेजों में विभिन्न कार्यान्वयन हो सकता है (उदाहरण के लिए जेडीबीसी, हाइबरनेट, जेडओ इत्यादि)

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

+0

चीयर्स। ऐसा लगता है कि @ ट्यूडर ने माइक्रोस्कोफ्ट प्रथाओं के बारे में भी क्या कहा। – dreza

0

आपका इरादा क्या है?

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

अन्यथा, एक ही नामस्थान में रहने वाले इंटरफ़ेस और कक्षा दोनों के लिए कोई समस्या नहीं है।

2

अलग असेंबली, समान नामस्थान के बारे में कैसे? मुझें यह पसंद है।

+0

यह एक समस्या का कारण बन सकता है जब आप इंटरफ़ेस लागू करने वाली कक्षा वाले असेंबली को संदर्भ जोड़ते हैं। यदि आपके पास इंटरफेस युक्त असेंबली का संदर्भ नहीं है तो संकलक एक त्रुटि फेंक देगा। कॉलर को इंटरफ़ेस युक्त असेंबली को ट्रैक करने के कार्य के साथ छोड़ दिया जाता है। – Ben

+2

मुझे लगता है कि समस्या इंटरफेस असेंबली के बिना कार्यान्वयन असेंबली जोड़ने वाला व्यक्ति है। आपको अपने समाधानों को अनिवार्य रूप से डिजाइन नहीं करना चाहिए कि कोई और उनके साथ गलती से क्या कर सकता है। – Chalky