एक अमूर्त वर्ग में एक सार्वजनिक निर्माता है जो एक कोडमेल है? कन्स्ट्रक्टर संरक्षित करना उन सभी पहुंच प्रदान करता है जिनके आप कोई उपयोग कर सकते हैं। इसे बनाने के लिए केवल एकमात्र अतिरिक्त पहुंच प्रदान करने के लिए कक्षा के उदाहरणों को उन क्षेत्रों में चर के रूप में घोषित किया जाएगा जो अपने संरक्षित सदस्यों तक नहीं पहुंच सकते हैं, लेकिन अमूर्त वर्गों के उदाहरणों को बिल्कुल घोषित नहीं किया जा सकता है।एक अमूर्त वर्ग में एक सार्वजनिक निर्माता है जो एक कोडमेल है?
मेरी राय यह होगी कि सार्वजनिक निर्माता को भ्रमित करने के लिए देखा जा सकता है, और जैसा कि आप कहते हैं कि इसे संरक्षित करना सही होगा। मैं कहूंगा कि एक संरक्षित कन्स्ट्रक्टर इंप्रेशन को सही ढंग से मजबूत करता है कि एक अमूर्त वर्ग का एकमात्र समझदार उपयोग इसे प्राप्त करना है।
असल में, आपको केवल कुछ करने की आवश्यकता होने पर एक अमूर्त वर्ग में एक कन्स्ट्रक्टर घोषित करने की आवश्यकता है, उदाहरण के लिए। अपने निजी सदस्यों को शुरू करें। तब मैं उम्मीद करता हूं कि वहां अन्य संरक्षित सदस्य कार्य हों जो कक्षाओं के लिए सहायक हों।
संपादित करें:
के बाद से कोई भी कोड पोस्ट किया गया है और @sbi ओ पी के लिए एक टिप्पणी में कुछ के लिए कहा, मैंने सोचा कि मैं कुछ पोस्ट होगा:
class Base:
{
public: // The question is: should the ctor be public or protected?
// protected:
Base():i(0){} // ctor is necessary to initialise private member variable
public:
virtual ~Base(){} // dtor is virtual (but thats another story)
// pure virtual method renders the whole class abstract
virtual void setValue(void)=0;
protected:
int getValue(void){ return i;}
private:
int i;
};
Base b1; // Illegal since Base is abstract, even if ctor is public
Base& b2=makeBase(); //We can point to, or refer to a Base
b2.setValue(); // We're not sure what this does, but we can call it.
b2.getValue(); // Illegal since getValue is protected
जैसा कि आप कहते हैं, अमूर्त वर्ग के सार्वजनिक निर्माता को प्रदान करने की कोई आवश्यकता नहीं है, न ही यदि आप सार्वजनिक निर्माता प्रदान करते हैं तो इसका दुरुपयोग किया जा सकता है।
हालांकि, आप कन्स्ट्रक्टर को जनता के रूप में घोषित करने वाले वर्गों की संरचना के लिए पुनर्मूल्यांकन के रूप में घोषित करने पर विचार कर सकते हैं।
क्या आप अपनी दूसरी वाक्य समझा सकते हैं? मुझे समझ में नहीं आता कि सिफारिश क्या हो सकती है। – quamrana
मुझे लगता है कि सार्वजनिक सीटीआर कक्षाओं को सार्वजनिक इंटरफेस को डिजाइन करने के साधनों को लागू करने की सिफारिश करेंगे। जैसे, एक अमूर्त "विंडो" कक्षा में सार्वजनिक ctor हो सकता है जिसमें "विंडो * पैरेंट" पैरामीटर हो। यह कक्षाओं को सार्वजनिक कन्स्ट्रक्टर के रूप में प्रदान करने की सिफारिश करेगा, जो इंटरफ़ेस का हिस्सा होगा। –
मैंने सोचा कि यह मामला हो सकता है - मैं कहूंगा कि यह गलत है। मैं कहूंगा कि एक सीटीओ के मामले में, इसे संरक्षित किया जाना चाहिए और इसे आवश्यक पैरामीटर लेना चाहिए, जो कि प्राप्त वर्गों के स्वतंत्र रूप से स्वतंत्र रूप से करना चाहिए। हालांकि, कोई अन्य सार्वजनिक शुद्ध वर्चुअल सदस्य फ़ंक्शंस ** ** ** को एक मजबूत संकेत होना चाहिए कि एक पत्ते वर्ग को इन्हें समान रूप से समान स्तर और पैरामीटर के साथ कार्यान्वित करने की आवश्यकता है। – quamrana
मैंने इसे कम से कम एक कोडिंग दिशानिर्देश में पढ़ा है कि अमूर्त वर्गों के निर्माता सार्वजनिक नहीं होना चाहिए - मुझे लगता है कि नियम आपके द्वारा दिए गए कारणों के लिए समझ में आता है।
हालांकि, मैं एक ऐसे परिदृश्य की कल्पना नहीं कर सकता जहां इसे सार्वजनिक बनाना गलत हो जाएगा। तो मैं अब तक यह नहीं कहूंगा कि यह एक कोड गंध है। मैं संरक्षित कन्स्ट्रक्टर को "अच्छी तरह से" संपत्ति के रूप में देखता हूं :)
सहमत हैं, संरक्षित कन्स्ट्रक्टर इस तथ्य की व्याख्या करता है कि कक्षा को सीधे चालू नहीं किया जा सकता है, इसलिए प्रोग्रामर के दृष्टिकोण से यह "अच्छी संपत्ति" है, भले ही संकलक वास्तव में इसकी परवाह नहीं करता हो। –
कोडिंग दिशानिर्देश आपको बुरी चीजों से बचाने के लिए माना जाता है जो हो सकता है। चूंकि आप एक अमूर्त वर्ग को कम नहीं कर सकते हैं, मुझे नहीं लगता कि यह दिशानिर्देश आपको किस प्रकार से बचा रहा है और इस प्रकार मध्यस्थ महसूस करता है। –
वे इसे सुरक्षित बनाकर कहते हैं, आप इसे स्पष्ट करते हैं कि इसका उपयोग व्युत्पन्न वर्गों द्वारा नहीं किया जा सकता है। मुझे संदेह है कि यह सदस्य ऑपरेटर के साथ एक समान तर्क है और हटाएं: वे स्पष्ट रूप से स्थिर सदस्य हैं, लेकिन उन्हें स्पष्ट रूप से स्थिर बनाना अच्छा होता है। दूसरी तरफ, सदस्य कार्यों की कक्षा में परिभाषा अंतर्निहित रूप से इनलाइन है, और मैं कहूंगा कि उन्हें स्पष्ट रूप से इनलाइन बनाने के लिए गरीब है। अंत में, मुझे लगता है कि यह संरक्षित-निर्माता मुद्दा स्वाद का विषय है। –
सावधान रहने की हालांकि स्पष्ट रूप से अपने संरक्षित/निजी प्रतिलिपि निर्माता को घोषित/परिभाषित करें। यदि आप संकलक नहीं करते हैं तो यह आपके लिए करेगा। स्कॉट मेयर्स देखें effective c++ आइटम 6.
मैं इसे दो कारणों से एक बुरा संकेत कहूंगा।
पहला यह है कि यह किसी को यह सोचने में गुमराह कर सकता है कि वे वास्तव में उस दिनचर्या को कॉल कर सकते हैं।
दूसरा यह है कि यह लेखक का तात्पर्य है कि आप इसे कॉल कर सकते हैं। अब आप नहीं जानते कि यह उनके डिजाइन का एक महत्वपूर्ण हिस्सा था या नहीं।
मुझे नहीं लगता कि वे वैध तर्क हैं। कोई भी जो ओओ डिज़ाइन या सी ++ के बारे में पहली चीज़ जानता है, उसे लगता है कि आप इसे कॉल कर सकते हैं और सभी कंपाइलर का दूसरा क्षण आपके द्वारा प्रयास किए जाने में त्रुटि देगा। –
मुझे पता है कि बहुत से लोग स्पष्ट रूप से असहमत हैं, लेकिन मुझे नहीं लगता कि एक अमूर्त वर्ग सीटीओआर को तब तक संरक्षित किया जाना चाहिए जब तक कि आप जिस इंटरफ़ेस को डिज़ाइन कर रहे हैं, उसके पास सभी व्युत्पन्न कक्षाओं के लिए एक संरक्षित सीटीआर भी नहीं है।
कारण यह है कि जब आप एक अमूर्त वर्ग तैयार करते हैं तो आप व्युत्पन्न कक्षाओं द्वारा कार्यान्वित करने के लिए एक इंटरफ़ेस तैयार कर रहे हैं। व्युत्पन्न कक्षाओं को इंटरफ़ेस को ठीक उसी तरह कार्यान्वित करना चाहिए जैसा कि यह बेस क्लास में डिज़ाइन किया गया है। एक सार आधार वर्ग द्वारा प्रस्तुत इंटरफेस एक अनुबंध है; उस अनुबंध को तोड़ो मत।
या दूसरे शब्दों में, यदि आप इंटरफ़ेस बदल रहे हैं, तो आप उस कक्षा से पहली जगह क्यों प्राप्त कर रहे हैं?
यह एक धार्मिक उत्तर का थोड़ा सा है, लेकिन बिल्ली क्या है। ;-)
@ रॉबर्ट: मैं यहां दिया गया आपका कारण समझता हूं, लेकिन मेरा मानना है कि यह ctor पर लागू नहीं होता है। हां, अन्य सार्वजनिक और संरक्षित सदस्य कार्य (सीटीओआर और डीटीओ को छोड़कर) इंटरफेस प्रदान करते हैं जो एक अनुबंध हैं और आपको उन्हें बदलने से पहले दो बार सोचना चाहिए। – quamrana
सार वर्ग को शुद्ध वर्चुअल विधियों की घोषणा के कारण सीधे तत्काल नहीं किया जा सकता है। इसलिए, संरक्षक को संरक्षित घोषित करना सिर्फ प्रोग्रामर के लिए अतिरिक्त सुझाव जोड़ता है।
मैंने Google शैली मार्गदर्शिका में संरक्षक here के रूप में संरक्षक घोषित करने की सिफारिश देखी। और मैंने कुछ अन्य कॉर्पोरेट कोडिंग मानकों में समान सिफारिशें पूरी की हैं। तो यह एक अच्छा अभ्यास की तरह दिखता है।
आप एक अमूर्त वर्ग के चर घोषित कैसे कर सकते हैं? क्या मैं कुछ भूल रहा हूँ? – sbi
मुझे लगता है कि ओपी का अर्थ है 'संरक्षित सदस्य विधियों' में। – quamrana
मुझे अभी भी यह नहीं मिला है। क्या आप एक उदाहरण दिखा सकते हैं? – sbi