क्यूटी: क्या QObject पर मेरे डोमेन ऑब्जेक्ट्स को आधार देना एक अच्छा विचार है?

Question

मैं यथोचित सी ++ के साथ संयोजन में क्यूटी ढांचे का उपयोग कर के लिए नया हूँ। मैं सोच रहा था: क्या QObject पर मेरे डोमेन कक्षाओं का आधार बनाना अच्छा विचार है? या क्या मुझे केवल पदानुक्रम में उच्च वर्गों के लिए ऐसा करना चाहिए? (उपयोगकर्ता इंटरफ़ेस स्तर के करीब)। क्यूटी प्रलेखन इस पर स्पष्ट नहीं है:

क्यूटी प्रलेखन से लिया:

मेटा-वस्तु प्रणाली एक सी ++ विस्तार बेहतर सच घटक जीयूआई प्रोग्रामिंग के लिए अनुकूल भाषा बनाता है।

स्पष्ट रूप से मैं अपने आवेदन को एक अच्छी तरह से संरचित तरीके से बनाना चाहता हूं। पिछले कुछ दिनों में मैं इस प्रश्न का उत्तर खोजने के लिए क्यूटी दस्तावेज के माध्यम से ब्राउज़ कर रहा हूं। मैं कुछ प्राथमिक गलती नहीं करना चाहता हूं जो मेरे आवेदन को अनंत काल के लिए सीमित कर देगा ;-)।

मैं पहले से ही QObject और क्यूटी वस्तु मॉडल के लिए बुनियादी प्रलेखन पर ध्यान दिया है। मुझे freshmeat article भी मिला जिसने मदद की लेकिन वास्तव में मुझे निष्कर्ष तक पहुंचने में मदद नहीं की। कुछ और है कि मुझे confuses कि क्यूटी ही इस मामले पर संगत होना प्रतीत नहीं होता है, क्योंकि सभी क्यूटी कक्षाएं एक आधार वर्ग के रूप में QObject का उपयोग करें।

QObject एक आधार वर्ग के रूप में उपयोग करने के लाभों मैं उन्हें देखने के रूप में:

• पदानुक्रम
• सिग्नल और स्लॉट
• गुण
• पहरा संकेत
• उपयोग करने में सक्षम होने के नाते अंतर्राष्ट्रीयकरण

हालांकि, मैं requir नहीं है ई मेरे अधिकांश डोमेन वर्गों में इनमें से कोई भी कार्यक्षमता। क्या इसके लिए सबसे अच्छा अभ्यास नियम है? या नियम होना चाहिए: यदि आप ऊपर वर्णित किसी भी अंक की आवश्यकता है तो इसका उपयोग करें?

आशा मैं यह भी भ्रामक :-)

Answer 1

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

Answer 2

नहीं किया "यह प्रयोग करें यदि आप अंक ऊपर उल्लेख किया है की किसी भी आवश्यकता होती है" - यह बेहतर कहना मुश्किल है। प्रत्येक वर्ग में अनावश्यक कार्यक्षमता जोड़ने का कोई कारण नहीं है। साझा पुस्तकालयों में परिभाषित कक्षाओं के बारे में भी सोचें: वे, गैर क्यूटी ग्राहकों द्वारा इस्तेमाल किया जा सकता है, तो आप उन्हें QObject से निकाले जाते हैं नहीं है।

Answer 3

यह समस्या 'के रूप में बड़े' के रूप में आप सोच सकते हैं नहीं है। यह वास्तव में इतना मायने रखता नहीं है। मैं कहूंगा कि अगर आप ऐसा करते हैं या नहीं करते हैं तो यह वास्तव में अलग नहीं होगा। तो, अंगूठे के नियम के रूप में, बस चीजों को आसान बनाने के लिए नहीं। यदि, हालांकि, आपको सिग्नल-स्लॉट या कुछ भी क्यूटी की आवश्यकता है, आगे बढ़ें, वैसे भी यह सब कुछ भी खर्च नहीं करता है।

Answer 4

मैं लगभग आपके प्रश्न के विपरीत उत्तर देना चाहूंगा, यह एक बुरा विचार नहीं है। चाहे वे QObjects हो, आपको जरूरतों पर निर्भर करता है। मेरे लिए गुणों और प्रतिबिंबों का उपयोग करने की क्षमता लगभग सिग्नल और स्लॉट के बराबर है।QMetaObject लचीली प्रोग्रामिंग रणनीतियों के लिए बहुत उपयोगी हो सकता है

Answer 5

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

Answer 6

क्यूओब्जेक्ट से अनावश्यक रूप से प्राप्त नहीं होने का एक अच्छा कारण है, और यह right there in the documentation है।

कोई प्रतिलिपि निर्माता या असाइनमेंट ऑपरेटर

QObject न एक प्रति निर्माता है और न ही एक असाइनमेंट ऑपरेटर है। [...]

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