2008-08-02 22 views
40

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

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

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

उत्तर

24

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

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

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

4

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

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

3

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

8

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

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

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

1

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

0

एक कारण यह नेस्टेड वर्गों से बचने के लिए

आपका एनकोडर/विकोडक वर्ग लगता है अगर तुम कभी अन्य भाषाओं के साथ उपयोग के लिए बड़ा घूँट (http://www.swig.org) के साथ कोड लपेटो करने का इरादा है। स्विग में वर्तमान में नेस्टेड कक्षाओं में समस्याएं हैं, इसलिए किसी भी नेस्टेड कक्षाओं का पर्दाफाश करने वाले पुस्तकालयों के साथ इंटरफेसिंग वास्तविक दर्द बन जाता है।

3

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

0

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

4

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

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

यहां PIMPL pattern (सेक्शन 3.1.1) पर अधिक जानकारी है।