नेस्टेड क्लासेस: एक उपयोगी उपकरण या एक एनकैप्सुलेशन उल्लंघन?

Question

तो मैं अभी भी बाड़ पर हूं कि मुझे इनका उपयोग करना चाहिए या नहीं।

मुझे लगता है कि यह एनकैप्सुलेशन का एक चरम उल्लंघन है, हालांकि मुझे लगता है कि मैं अपने कोड में अधिक लचीलापन प्राप्त करते हुए कुछ हद तक इनकैप्सुलेशन प्राप्त करने में सक्षम हूं।

पिछले जावा / स्विंग प्रोजेक्ट्स में मैंने कुछ हद तक नेस्टेड क्लास का उपयोग किया था, हालांकि अब मैं सी # में अन्य प्रोजेक्ट में स्थानांतरित हो गया हूं और मैं इसके उपयोग से बच रहा हूं।

आप नेस्टेड क्लासेस के बारे में कैसा महसूस करते हैं?

Comments

वास्तव में नेस्टेड कक्षाएं एनकैप्सुलेशन का उल्लंघन कैसे होती हैं? यदि किसी चीज को वे अधिक एनकैप्सुलेटेड करते हैं, क्योंकि वे दूसरे वर्ग के अंदर 'एनकैप्सुलेटेड' हैं, और वैकल्पिक रूप से निजी बनाया जा सकता है।

— स्टीवन ज्यूरिस

Answer 1

खैर, इसे भी सीधे शब्दों में कहें: नेस्टेड क्लासेस एनकैप्सुलेशन का उल्लंघन नहीं करते हैं और सामान्य तौर पर, भाषा की विशेषताएं प्रोग्रामिंग सिद्धांतों का उल्लंघन नहीं करती हैं। प्रोग्रामर प्रोग्रामिंग सिद्धांतों का उल्लंघन करते हैं।

मजेदार रूप से पर्याप्त है, यह दावा किया जाता है कि नेस्टेड कक्षाएं एनकैप्सुलेशन बढ़ाती हैं :

एन्कैप्सुलेशन में वृद्धि - दो शीर्ष-स्तरीय कक्षाओं पर विचार करें, ए और बी, जहां बी को ए के सदस्यों तक पहुंच की आवश्यकता है जो अन्यथा निजी घोषित किए जाएंगे। कक्षा बी को कक्षा ए के भीतर छिपाकर, ए के सदस्यों को निजी घोषित किया जा सकता है और बी उन्हें एक्सेस कर सकते हैं। इसके अलावा, बी खुद को बाहरी दुनिया से छिपाया जा सकता है।

उसमें कुछ सच्चाई है।

आमतौर पर B, SRP को A. B पर लागू करने का एक परिणाम है। हालांकि, संभवतः कई सिद्धांतों का उल्लंघन करता है, विशेष रूप से, अगर यह सब करता है तो A के निजी सदस्यों के साथ चक्कर लगाना है: D

मुझे लगता है कि छिपी हुई कक्षाएं उपयोगी हो सकती हैं। लेकिन इसके दुरुपयोग की बहुत संभावना है।

Answer 2

हम हर समय नेस्टेड कक्षाओं का उपयोग करते हैं। बहुत सारी स्थितियों में, व्यवसाय सॉफ़्टवेयर / प्रक्रियाओं में व्यावसायिक वस्तुओं का नेस्टेड होता है। हम सभी ने ऑर्डर ऑब्जेक्ट का उदाहरण देखा है, जिसमें ऑर्डरइमेट्स का नेस्टेड संग्रह है।

लब्बोलुआब यह है कि यह कोड को पढ़ना / लिखना आसान बनाता है और शायद ही कभी ऐसा मामला होता है जहां आपको अपने ऑर्डर वर्ग की आवश्यकता होती है और ऑर्डरआईटम्स के बारे में जानने की आवश्यकता नहीं होती है।

Answer 3

व्यक्तिगत रूप से, मुझे लगता है कि उन्हें बचा जाना चाहिए क्योंकि वे आपके डिज़ाइन को विभिन्न (आमतौर पर प्रतिकूल) तरीके से करते हैं।

हालाँकि, यदि आपकी परियोजना में एक निर्धारित गुंजाइश है और एक वर्ग (जैसे कि एक नोड वर्ग या किसी प्रकार की वस्तु जो किसी विशिष्ट वर्ग के डेटास्ट्रक्चर को पार करने के लिए उपयोग की जाती है) को एनकैप्सुलेट करना है तो मुझे नुकसान नहीं दिखता है।

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

Answer 4

(सी # में) आम तौर पर मैं उनसे बचता हूं, हालांकि यह निर्भर कर सकता है कि कक्षा का उद्देश्य क्या है।

मैं उन्हें कभी भी किसी भी प्रकार के डोमेन मॉडल वर्ग के लिए उपयोग नहीं करूंगा, बस मुझे इससे कोई मतलब नहीं है।

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

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