यह कैसे तय करें कि कोई विधि निजी, संरक्षित, आंतरिक या सार्वजनिक होगी या नहीं?

Question

मैं एक कक्षा तैयार कर रहा हूं जहां कुछ तरीकों से सार्वजनिक रूप से उजागर होने पर कोई नुकसान नहीं पहुंचाएगा। लेकिन वे निजी भी हो सकते हैं, क्योंकि उनका उपयोग केवल मेरी परियोजना में एक ही कक्षा से किया जाएगा।

1. यूनिट accessors की आवश्यकता के बिना Testable:

   उन्हें बनाना सार्वजनिक निम्न लाभ हैं।

2. लचीलापन।
   1. सार्वजनिक प्रलेखन सरलीकरण:

   उन्हें निजी बनाने से निम्न लाभ हैं।

3. कुछ अज्ञात बग का खुलासा नहीं किया गया है।

इस मामले में सामान्य दिशानिर्देश कौन सा हैं?

Answer 1

ओह, कृपया कृपया च पढ़ें। स्टीव मैककोनेल द्वारा कोड पूर्ण 2 के 06, यदि आपके पास इसका उपयोग है। वह आपके प्रश्न का पूरी तरह उत्तर देगा।

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

यदि आपको इसकी आवश्यकता नहीं है, तो विधि को सार्वजनिक करने की कोई आवश्यकता नहीं है।

परीक्षण के लिए, जॉन सैंडर्स को +1।

लेकिन मैं वास्तव में आपको यहां समझा नहीं सकता क्योंकि स्टीव ने सीसी 2 में समझाया है।

मुझे उम्मीद है कि सैककोवरफ्लो पर पुस्तक संदर्भ पोस्ट करना ठीक है? (कृपया टिप्पणी करें।)

Answer 2

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

Answer 3

हमेशा जितना संभव हो सके निजी बनाएं।

इकाई परीक्षण के लिए, मैं कभी कभी एक सदस्य आंतरिक करना होगा, फिर आंतरिक सदस्यों के लिए इकाई परीक्षण विधानसभा पहुंच की अनुमति के लिए AssemblyInfo.cs में InternalsVisibleTo विशेषता का उपयोग।

Answer 4

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

Answer 5

एक प्रकार का एकमात्र सार्वजनिक सदस्य प्रकार के सार्वजनिक इंटरफ़ेस का हिस्सा होना चाहिए। आपका लक्ष्य सदस्यों के कम से कम संख्या में इंटरफ़ेस को कम करना और अंतर्निहित कार्यान्वयन में से कोई भी छोटा नहीं होना चाहिए।

Answer 6

मैं अपने निजी जनता को कभी नहीं बनाऊंगा! अवधि।

Answer 7

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

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

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

Answer 8

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

कभी-कभी यह समझ में आता है, अन्य बार ऐसा नहीं होता है। सिर्फ एक विचार।