डेटाबेस या फाइल सिस्टम एक्सेस के लिए कॉन्स अर्थशास्त्र

Question

मैं नियमित रूप से const का उपयोग करता हूं जब इन-मेमोरी डेटा संरचनाओं के साथ काम करता है और मेरा कोड कॉन्स्ट-सही रखता है, लेकिन मुझे यकीन नहीं है कि const को और अधिक जटिल वस्तुओं पर लागू होना चाहिए, जैसे कि निम्न:

• वस्तुओं दूरस्थ सिस्टम के लिए कनेक्शन का प्रतिनिधित्व करने
• वस्तुओं एक डेटाबेस द्वारा समर्थित (कि मांग पर डेटाबेस से भागों लोड कर सकते हैं)
• वस्तुओं एक पर डिस्क निर्देशिका वृक्ष द्वारा समर्थित (निर्देशिका वृक्ष के उपयोग के साथ एक अलग वस्तु पदानुक्रम द्वारा नियंत्रित)

const विधियों को इन तरह की वस्तुओं के लिए क्या संकेत देना चाहिए? मैं कुछ संभावनाओं के बारे में सोच सकता हूं:

• "सख्त" कॉन्स्ट - विधि जो किसी भी स्मृति स्थिति को संशोधित नहीं करती हैं। हालांकि, यह encapsulation तोड़ने लगते हैं, क्योंकि कॉलर्स को यह जानने की आवश्यकता होगी कि कौन से तरीके कनेक्शन स्थिति को संशोधित करते हैं और जो नहीं करते हैं।
• "लॉजिकल" कॉन्स्ट - ऑब्जेक्ट्स की लॉजिकल स्टेटस को संशोधित नहीं करने वाले तरीके हैं। हालांकि, यह संभावित रूप से mutable के रूप में बहुत सारे राज्य और कैशिंग चर को चिह्नित करने की आवश्यकता होगी। हालांकि मुझे एहसास है कि mutable के लिए डिज़ाइन किया गया है, इसका उपयोग करके यह हैक की तरह लगता है। इसके अलावा, उस कॉन्स का मतलब है "मैं इसे संशोधित करने का वादा करता हूं," यह लागू करने का अधिकार प्रतीत नहीं होता है जब विधियां अजीब और अद्भुत तरीकों से कनेक्शन की स्थिति को संशोधित कर सकती हैं (जब तक वे encapsulation बनाए रखते हैं), कैश के परिणाम के रूप में परिणाम जितना चाहें उतना चाहते हैं, कनेक्शन विफल होने पर अपवाद फेंक दें, आदि
• कोई कॉन्स - पिछली समस्याओं के प्रकाश में, क्या अधिक जटिल वस्तुओं के लिए बस इतना अर्थ नहीं है?

कौन सा दृष्टिकोण सबसे उपयोगी है? सबसे आम कौन सा है?

Answer 1

यह एक कठिन सवाल है। मैं वास्तव में अभी एक ही चीज़ पर काम कर रहा हूं। मेरे पास एक MySQL डेटाबेस द्वारा समर्थित एक बड़ी इन-मेमोरी डेटा संरचना है। मैंने "जहां भी संभव हो" दृष्टिकोण शुरू किया, लेकिन यह अभ्यास में अक्सर नहीं होता है:

• आप तृतीय-पक्ष लाइब्रेरी का उपयोग कर रहे हैं जो कि सही नहीं है।
• सभी SELECT कथन वास्तव में केवल पढ़ने के लिए नहीं हैं। उदाहरण के लिए, SELECT GET_LOCK निश्चित रूप से डीबी पक्ष पर राज्य को संशोधित करता है।
• मुझे कई सी ++ प्रोग्रामर नहीं मिले हैं जो mutable का उपयोग कर सकते हैं। मुझे निश्चित रूप से इसके साथ ज्यादा अनुभव नहीं है। भविष्य के रखरखाव करने वाले म्यूटेबल की तुलना में अधिक समस्याएं पैदा कर सकते हैं। आप अपनी टीम को सर्वश्रेष्ठ जानते हैं, इसलिए यह आप पर निर्भर करता है कि आप उस मार्ग पर जाना चाहते हैं या नहीं।

मुझे लगता है कि डेटाबेस में एक एकल परिवर्तनीय हैंडल के साथ एक कॉन्स ऑब्जेक्ट सबसे सुंदर समाधान हो सकता है। तय करें कि एक कॉन्स्ट ऑब्जेक्ट को उचित रूप से करने में सक्षम होना चाहिए, और उन सभी कार्यों को कॉन्स्ट करना चाहिए। आपकी कक्षा के उपयोगकर्ताओं को केवल यह जानने की जरूरत है कि कौन से फ़ंक्शन हैं और जो नहीं हैं। हेडर फ़ाइल उन्हें वह देगी। उन्हें जानने की आवश्यकता नहीं है क्यों एक विशेष कार्य कॉन्स्ट या गैर-कॉन्स है। मैं सहमत हूं कि म्यूटेबल सदस्यों का ढेर हैकिश दिखना शुरू कर देता है।

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