यदि मैं छोटे कार्यों के साथ एक वर्ग बना रहा हूं जो अधिक नहीं करता है, तो क्या यह केवल उन्हें हेडर फ़ाइल में रखने के लिए स्वीकार्य है? तो एक विशेष वर्ग के लिए, यह केवल इतना ही है। एचपी के साथ जाने के लिए।(सी ++) .h फ़ाइल में पूरी कक्षा?
हां, यह स्वीकार्य है। यह निश्चित रूप से संकलित होगा। लेकिन, अगर यह कोड संगठन क्लीनर बनाता है, तो यह अच्छा हो सकता है। अधिकांश टेम्पलेट परिभाषाएं पहले से ही इस तरह की आवश्यकता से बाहर हैं, इसलिए आप कुछ भी अनदेखा नहीं कर रहे हैं। उस कक्षा के कुछ दोष हो सकते हैं हालांकि अन्य वर्गों पर निर्भर करता है। यदि आप कक्षा का उपयोग करने वाली अन्य फ़ाइलों में पूरी परिभाषा को शामिल करना चाहते हैं, तो केवल संक्षिप्त कक्षा घोषणा के मुकाबले अतिरिक्त संकलन समय लग सकता है।
यदि आप वास्तविक चिंता प्रतीत होते हैं तो आप अपने संकलन के समय को माप सकते हैं।
यदि आप एक प्रति प्राप्त कर सकते हैं, The c++ Programming Language (और कई अन्य पुस्तकों) में स्रोत कोड संगठन और कोड को अलग करने के विशिष्ट लाभ हैं .h और .cpp फ़ाइलों में।
हां, यह स्वीकार्य है। इसके अलावा, यदि आप टेम्पलेट्स करते हैं और आपके पास export समर्थन वाला कंपाइलर नहीं है तो आपके पास कोई विकल्प नहीं है।
हालांकि, ध्यान दें कि यह निर्भरता में वृद्धि कर सकता है और इस प्रकार संकलन धीमा कर सकता है।
यह ठीक होगा अगर आप अपने भविष्य के कोड या परियोजनाओं में उस हेडर फ़ाइल का उपयोग करेंगे, और यदि आप इसे दूसरों के साथ साझा करना चाहते हैं।
इस पर निर्भर करता है कि आप कैसे लिंक कर रहे हैं। ब्लाह के पुनर्वितरण जैसे संदेशों को देखने से बचने के लिए, लाइन 13 पर फ़ाइल blah.h में पिछली परिभाषा बस सब कुछ डालें लेकिन एक .cpp में घोषणा।
यह निर्भर करता है कि आप क्या लक्ष्य कर रहे हैं।
एक पालतू परियोजना के लिए, यह स्वीकार्य है, लेकिन फिर कुछ भी वास्तव में है।
कोई वास्तविक परियोजना के लिए, आप अपने आप को कई सवाल पूछने की आवश्यकता? (हाँ)
यदि प्रतिक्रियाएं आपको संतुष्ट करती हैं, तो आगे बढ़ें।
यह मुख्य रूप से निर्भरता प्रबंधन का विषय है। शीर्षलेख में विधियों की परिभाषा डालने से, उन्हें कंपाइलर द्वारा रेखांकित होने की संभावना है, जिसका अर्थ है कि प्रत्येक बार जब वे बदलते हैं तो आपको इस वर्ग पर निर्भर होने वाली सभी चीज़ों को फिर से संकलित करना होगा।
टेम्पलेट्स ऐसा करते हैं, हालांकि टेम्पलेट्स में आम तौर पर कुछ निर्भरताएं होती हैं (अन्य शामिल हैं) और आपको अपेक्षाकृत आगे बढ़ने के लिए मजबूर होना पड़ता है (हालांकि आप निर्भरता पर कटौती करने के लिए गैर-टेम्पलेट आश्रित कोड को बाहरी कर सकते हैं)।
वास्तविक बड़ी परियोजनाओं के लिए जहां निर्भरता प्रबंधन सबसे प्रमुख है, तो मैं इसके खिलाफ सलाह दूंगा। उन परियोजनाओं में एक स्थिर एबीआई और द्विआधारी संगत परिवर्तन को बढ़ावा देने की क्षमता मुद्दे के मामले में जीवन-बचतकर्ता हैं और वे डेवलपर के लिए "मामूली" असुविधा के लायक हैं।
किसी भी मामले में, कृपया कक्षा के बीच में विधियों को परिभाषित न करें। यहां तक कि रेखांकित भी आप वर्ग घोषणा के बाद उन्हें परिभाषित कर सकते हैं। इंटरफ़ेस को समझने के लिए यह लोगों को पढ़ने के लिए इसे आसान बनाता है (स्वयं कुछ महीनों में)।
आईएमओ, यदि आपकी विधियां अधिकतर एक-लाइनर हैं, तो कक्षा के अंदर विधि परिभाषा वास्तव में बहुत अधिक विचलित नहीं होती है और कभी-कभी कोड की समझदारी को बढ़ा सकती है; और वास्तव में एकमात्र कारण है कि कोई अलग .cpp फ़ाइल बनाना नहीं चाहेगा क्योंकि वर्ग छोटा है और विधियां सभी छोटी हैं। –
@ ली रयान: मैं मानता हूं कि एक-लाइनर (जैसे 'खाली'/'आकार') को वर्ग के बीच में बहुत अधिक परेशान किए बिना परिभाषित किया जा सकता है ... लेकिन फिर एक-एक के बीच की सीमा को परिभाषित करना मुश्किल है। लाइनर, एक-लाइनर जो लपेटा गया है क्योंकि यह स्क्रीन में फिट नहीं हुआ है, एक दो-लाइनर जो लपेटे हुए एक-लाइनर से छोटा है ... उसके बाद, यह सब कॉल करते हैं। –
लेकिन आपको हार्ड सीमा को परिभाषित करने की आवश्यकता नहीं है, बस अपनी आंत भावनाओं का पालन करें। अंत में, कंपाइलर अभी भी वही या समकक्ष आउटपुट उत्पन्न करेगा। कई प्रोग्रामिंग स्टाइलम मार्गदर्शिकाएं लगातार शैली को बढ़ावा देती हैं क्योंकि स्थिरता को मापना आसान होता है, अगर कुछ हमेशा समान दिखता है तो यह लगातार होता है; हालांकि कई मामलों में, स्थिरता के लिए यह जुनून संभावित लाभों को अनदेखा करने की लागत पर है जो मात्रा को मापना मुश्किल है। पठनीयता और समझदारी को मापना उतना आसान नहीं है; और नतीजतन, अक्सर स्टाइल दिशानिर्देशों में साइड-रेखांकित होते हैं। –