क्या मुझे इस मामले में नेस्टेड कक्षाओं का उपयोग करना चाहिए?

मैं वीडियो प्लेबैक और रिकॉर्डिंग के लिए इस्तेमाल कक्षाओं के संग्रह पर काम कर रहा हूं। मेरे पास एक मुख्य वर्ग है जो सार्वजनिक इंटरफ़ेस की तरह कार्य करता है, जैसे play() , stop() , रोकें() , रिकॉर्ड() आदि ... फिर मेरे पास वर्कहोर वर्ग हैं जो वीडियो डिकोडिंग और वीडियो एन्कोडिंग करते हैं।

मैंने सी ++ में घोंसला वाले वर्गों के अस्तित्व के बारे में सीखा है, और मुझे यह जानकर उत्सुकता है कि प्रोग्रामर उन्हें इस्तेमाल करने के बारे में क्या सोचते हैं। मैं थोड़ा सावधान हूं और वास्तव में यह सुनिश्चित नहीं करता कि लाभ / कमी क्या हैं, लेकिन वे मेरे जैसे मामलों में इस्तेमाल होने के लिए प्रतीत होते हैं (पुस्तक जो मैं पढ़ रहा हूं) के अनुसार।

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

0
जोड़ा संपादित
विचारों: 2

9 उत्तर

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

मेरा दर्शन आगे बढ़ना होगा और दोनों संरचनाओं को क्लाइंट के लिए एक पॉलिश तरीके से सुलभ बनाना होगा, बस अनुमान के तहत उनका उपयोग किया जाएगा।

मैं Qt में QTextDocument जैसे कुछ का संदर्भ दूंगा। आप नंगे धातु डेटा हैंडलिंग के लिए एक सीधा इंटरफ़ेस प्रदान करते हैं, लेकिन मैनिपुलेशन करने के लिए QTextEdit जैसे किसी ऑब्जेक्ट के साथ प्राधिकरण को पास करते हैं।

0
जोड़ा

sounds like a case where you could use the strategy pattern

0
जोड़ा

नेस्टेड कक्षाओं का उपयोग करना है या नहीं, यह तय करने का एक तरीका यह है कि यह वर्ग एक सहायक भूमिका निभाता है या नहीं, यह स्वयं का हिस्सा है या नहीं।

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

0
जोड़ा

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

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

यहां PIMPL पैटर्न (अनुभाग 3.1.1) पर अधिक जानकारी दी गई है।

0
जोड़ा

आपको केवल एक आंतरिक वर्ग का उपयोग करना चाहिए जब आप इसे बाहरी वर्ग 'सार्वजनिक इंटरफ़ेस का उपयोग करके एक अलग वर्ग के रूप में लागू नहीं कर सकते हैं। आंतरिक वर्ग एक वर्ग की आकार, जटिलता और जिम्मेदारी को बढ़ाते हैं ताकि उन्हें कम से कम इस्तेमाल किया जाना चाहिए।

Your encoder/decoder class sounds like it better fits the Strategy Pattern

0
जोड़ा

आप मुख्य श्रेणी को लागू करने के लिए आवश्यक एक (छोटी) सहायक वर्ग बनाने के लिए एक नेस्टेड कक्षा का उपयोग करेंगे। या उदाहरण के लिए, एक इंटरफ़ेस परिभाषित करने के लिए (सार विधियों वाला एक वर्ग)।

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

इसके बजाए, अन्य वर्गों को अलग .h / .cpp फ़ाइलों में रखें, जिन्हें आप अपने वीडियोप्लेयर क्लास में उपयोग कर सकते हैं। वीडियोप्लेयर के क्लाइंट को केवल उस फ़ाइल को शामिल करने की आवश्यकता है जो वीडियोप्लेयर घोषित करता है, और अभी भी यह जानने की आवश्यकता नहीं है कि आपने इसे कैसे कार्यान्वित किया है।

0
जोड़ा

कभी-कभी उपयोगकर्ता से कार्यान्वयन कक्षाओं को छिपाना उचित होता है - इन मामलों में सार्वजनिक कक्षा परिभाषा के अंदर उन्हें foo_internal.h में रखना बेहतर होता है। इस तरह, आपके foo.h के पाठक यह नहीं देख पाएंगे कि आप क्या चाहते हैं कि वे परेशान न हों, लेकिन आप अभी भी अपने इंटरफ़ेस के प्रत्येक ठोस कार्यान्वयन के खिलाफ परीक्षण लिख सकते हैं।

0
जोड़ा

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

0
जोड़ा

ध्यान में रखना एक और बात यह है कि क्या आपने कभी अपने कार्य कार्यों (जैसे डीकोडिंग और एन्कोडिंग) के विभिन्न कार्यान्वयन की कल्पना की है। उस स्थिति में, आप निश्चित रूप से कार्यों को लागू करने वाले विभिन्न ठोस वर्गों के साथ एक सार आधार वर्ग चाहते हैं। यह वास्तव में प्रत्येक प्रकार के कार्यान्वयन के लिए एक अलग उपclass घोंसला करने के लिए उपयुक्त नहीं होगा।

0
जोड़ा