सार्वजनिक, संरक्षित, निजी का उपयोग करने के लिए सर्वोत्तम अभ्यास?

Question

क्या यह कहना उचित है कि किसी चीज को privateकोड करते समय सामने वाले को सब कुछ डिफ़ॉल्ट करने के लिए अच्छा अभ्यास है?

और उसके बाद ही इसे अपग्रेड करें protectedयदि एक उपवर्ग को इसकी आवश्यकता है, या publicयदि किसी अन्य वर्ग को इसकी आवश्यकता है?

Comments

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

— user2023861

क्या आपके सभी चरों के

— gnat

Answer 1

संक्षिप्त उत्तर: हां

दीर्घ उत्तर:

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

क्लास डिजाइन करते समय विचार करने के लिए सबसे महत्वपूर्ण पहलुओं में से एक यह है कि इसका उपयोग कैसे किया जाएगा; जिसमें निजी / कार्यान्वयन विवरण के बारे में सोचने से पहले अपने सार्वजनिक तरीकों के बारे में सोचना शामिल है।

इसके अलावा, यह दृष्टिकोण आमतौर पर अपने आप को पूछने के लिए याद आ रहा है "मैं इस वर्ग के लिए एक इकाई परीक्षण कैसे लिखूंगा?" - यदि आप वास्तव में यूनिट टेस्ट नहीं लिख रहे हैं, तो भी यह एक महत्वपूर्ण सवाल है। (संबंधित: "परीक्षण कोड को बढ़ावा देने वाले डिजाइन सिद्धांत क्या हैं?" )

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

Comments

इसलिए अगर मैं यह बताने की कोशिश कर रहा था कि आप जो कह रहे हैं उसे वापस देखें (यह देखने के लिए कि क्या मुझे समझ में आता है), तो पहले सार्वजनिक रूप से सामने वाले इंटरफेस के बारे में सोचना एक अच्छा विचार है (यानी यह वर्ग वास्तव में कैसे इस्तेमाल किया जा रहा है? बाहर के साथ शुरू करने के लिए?) और फिर सब कुछ निजी?

— AJJ

@ArukaJ एक अच्छा तरीका कोड लिखना है जो कार्यान्वयन के निर्माण से पहले आपकी कक्षाओं का उपयोग करेगा। जब तक आप पहले यूनिट परीक्षण लिखना शुरू नहीं करते हैं, तब तक यह चिकन या अंडे की समस्या का एक सा हो सकता है।

— जिम्मीजम्स

@ArukaJ मोटे तौर पर हाँ; जो पहली बार में करने के लिए और अधिक कठिन लग सकता है, हालांकि जिमीजैम का उल्लेख है, जब आप इकाई परीक्षण लिख रहे हैं तो यह बहुत अधिक सहज महसूस करता है। इसमें थोड़ी अलग मानसिकता शामिल हो सकती है, लेकिन लक्ष्य यह है कि आपकी कक्षा क्या दर्शाती है और आपके इनपुट / आउटपुट क्या दिखते हैं, इस बारे में अधिक ध्यान से सोचना है - कुल मिलाकर यह डिज़ाइन के बारे में सोचने का एक बहुत "OO" तरीका है; अधिक सामंजस्य के साथ बड़े करीने से वर्गीकृत कक्षाओं में परिणाम की संभावना है।

— बेन कॉटरेल

मैं आपकी कक्षा को डिजाइन करने के लिए इकाई परीक्षणों का उपयोग करने की कोशिश कर रहा हूं, क्योंकि इकाई परीक्षण वे नहीं हैं जो वास्तव में इसका उपयोग करेंगे। हालांकि, वे निश्चित रूप से यह सोचने में बेहतर नहीं हैं कि कक्षा का उपयोग कैसे किया जाएगा।

— user949300

Answer 2

"और उसके बाद ही इसे संरक्षित करने के लिए अपग्रेड करें यदि उपवर्ग को इसकी आवश्यकता है, या यदि किसी अन्य वर्ग को इसकी आवश्यकता है, तो सार्वजनिक करें?"

यह गलत तरीका है। डिज़ाइन समय पर, आपको पता होना चाहिए कि आप किस सार्वजनिक पहुँच को देना चाहते हैं। आमतौर पर आप सार्वजनिक पहुँच देते हैं क्योंकि यह आपकी कक्षा का पूरा उद्देश्य है। और आप संरक्षित पहुंच देते हैं क्योंकि आप चीजों को एक्सेस करने के लिए उपवर्ग चाहते हैं। और आप निजी चीजों का उपयोग करते हैं जो किसी और के व्यवसाय नहीं हैं।

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

Comments

चलो कहते हैं कि तुम एक वर्ग है कि आप इस समय उपवर्ग करने का इरादा नहीं है (और है हो सकता है की जरूरत कभी नहीं) और एक विधि है कि यदि आप थे अपने वर्ग उपवर्ग के लिए, उपयोगी होगा / उपवर्ग से / करने के लिए आवश्यक। क्या आप वह विधि करेंगे privateया protected?

— lfk

स्वीकृत उत्तर होना चाहिए, मुझे लगता है / डिजाइन नहीं करना चाहते हैं जैसे पहले लगता है पर सब कुछ निजी बना।

— 1946

Answer 3

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

एक कार के पहिए की तरह एक इंटरफेस के बारे में सोचो। आप तय करते हैं कि पहिया घुमाते हुए कार किस दिशा में जाती है, लेकिन कवर के नीचे रोटरी वाल्व, हाइड्रॉलिक्स, पुलीज़ आपके पहियों के रोटेशन को बदलते हैं, लेकिन आपको कार चलाने के लिए मैकेनिकल इंजीनियर की आवश्यकता नहीं है।

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