मैं एक फ़ाइल के लिए एक वर्ग रखता था। उदाहरण के लिए car.cs में क्लास कार है । लेकिन जैसे-जैसे मैं और कक्षाएं आयोजित करता हूं, मैं उन्हें उसी फ़ाइल में जोड़ना चाहूंगा। उदाहरण के लिए car.cs में क्लास कार और डोर क्लास आदि हैं।
मेरा प्रश्न जावा, C #, PHP या किसी अन्य प्रोग्रामिंग भाषा के लिए अच्छा है। क्या मुझे एक ही फ़ाइल में कई कक्षाएं नहीं करने की कोशिश करनी चाहिए या यह ठीक है?
जवाबों:
मुझे लगता है कि आपको अपने कोड को प्रति फ़ाइल 1 कक्षा में रखने की कोशिश करनी चाहिए।
मैं यह सुझाव देता हूं क्योंकि बाद में आपकी कक्षा को ढूंढना आसान हो जाएगा। इसके अलावा, यह आपके स्रोत नियंत्रण प्रणाली के साथ बेहतर काम करेगा (यदि कोई फ़ाइल बदलता है, तो आप जानते हैं कि एक विशेष वर्ग बदल गया है)।
केवल एक बार जब मुझे लगता है कि प्रति फ़ाइल एक से अधिक वर्ग का उपयोग करना सही है, जब आप आंतरिक कक्षाओं का उपयोग कर रहे हैं ... लेकिन आंतरिक कक्षाएं किसी अन्य वर्ग के अंदर हैं, और इस प्रकार उसी फ़ाइल के अंदर छोड़ दिया जा सकता है। आंतरिक कक्षाएं भूमिकाएं बाहरी कक्षाओं से दृढ़ता से संबंधित हैं, इसलिए उन्हें एक ही फ़ाइल में रखना ठीक है।
जावा में, एक सार्वजनिक प्रति फ़ाइल वर्ग भाषा के काम करने का तरीका है। जावा फ़ाइलों के एक समूह को एक पैकेज में एकत्र किया जा सकता है।
पाइथन में, हालांकि, फाइलें "मॉड्यूल" हैं, और आमतौर पर कई संबंधित कक्षाएं हैं। जावा पैकेज की तरह ही पायथन पैकेज एक निर्देशिका है।
यह पायथन को कक्षा और पैकेज के बीच समूहीकरण का एक अतिरिक्त स्तर देता है।
भाषा-अज्ञेय का कोई एक सही उत्तर नहीं है। यह भाषा के साथ बदलता रहता है।
प्रति फ़ाइल एक वर्ग एक अच्छा नियम है, लेकिन कुछ अपवाद बनाना उचित है। उदाहरण के लिए, यदि मैं एक ऐसी परियोजना में काम कर रहा हूँ जहाँ अधिकांश वर्गों में संग्रह प्रकार जुड़े होते हैं, तो अक्सर मैं कक्षा और उसके संग्रह को एक ही फ़ाइल में रखूँगा, जैसे:
public class Customer { /* whatever */ }
public class CustomerCollection : List<Customer> { /* whatever */ }
अंगूठे का सबसे अच्छा नियम एक वर्ग को प्रति फ़ाइल रखना है, जब वह चीजों को आसान बनाने के बजाय कठिन बनाना शुरू करता है। चूंकि विजुअल स्टूडियो की फाइल्स फाइल्स में इतनी प्रभावी है, इसलिए आपको फ़ाइल संरचना के माध्यम से वैसे भी देखने में ज्यादा समय नहीं देना पड़ेगा।
नहीं, मुझे नहीं लगता कि यह पूरी तरह से बुरा व्यवहार है। मेरा मतलब है कि सामान्य रूप से प्रति कक्षा एक अलग फ़ाइल रखना सबसे अच्छा है, लेकिन निश्चित रूप से अच्छे अपवाद मामले हैं जहां एक फ़ाइल में कक्षाओं का एक गुच्छा होना बेहतर है। इसका एक अच्छा उदाहरण अपवाद वर्गों का एक समूह है, यदि आपके पास इनमें से कुछ दर्जन किसी दिए गए समूह के लिए हैं तो क्या यह वास्तव में प्रत्येक दो लाइनर वर्ग के लिए एक अलग फाइल रखने के लिए समझ में आता है? मैं बहस नहीं करूँगा। इस मामले में एक वर्ग में अपवादों का एक समूह बहुत कम बोझिल और सरल IMHO है।
मैंने पाया है कि जब भी मैं एक फ़ाइल में कई प्रकारों को संयोजित करने की कोशिश करता हूं, तो मैं हमेशा पीछे हट जाता हूं और उन्हें अलग कर देता हूं क्योंकि इससे उन्हें खोजने में आसानी होती है। जब भी मैं संयोजन करता हूं, तो हमेशा एक ऐसा क्षण होता है जहां मैं wtf का पता लगाने की कोशिश कर रहा हूं जो मैंने टाइप एक्स को परिभाषित किया है।
तो अब, मेरा व्यक्तिगत नियम यह है कि प्रत्येक व्यक्तिगत प्रकार (शायद बच्चों की कक्षाओं के लिए, जिसके द्वारा एक वर्ग के अंदर एक वर्ग है, न कि विरासत में मिला वर्ग) को अपनी फ़ाइल मिलती है।
चूँकि आपका IDE आपको " नेविगेट " कार्यक्षमता के साथ प्रदान करता है और आपके पास अपनी कक्षाओं के नाम स्थान पर कुछ नियंत्रण है तो उसी फ़ाइल के भीतर कई कक्षाएं होने के निम्न लाभ मेरे लिए इसके लायक हैं।
जनक - बाल वर्ग
कई मामलों में मुझे अपनी बेस क्लास फ़ाइल के भीतर इनहेरिट की गई कक्षाओं के लिए काफी मददगार लगता है ।
यह देखना काफी आसान है कि आपके बच्चे की विरासत में कौन से गुण और विधियाँ हैं और फ़ाइल समग्र कार्यक्षमता का तेज़ अवलोकन प्रदान करती है।
पब्लिक: स्माल - हेल्पर - डीटीओ क्लासेस
जब आपको एक विशिष्ट कार्यक्षमता के लिए कई सादे और छोटे वर्गों की आवश्यकता होती है, तो मुझे लगता है कि सभी संदर्भों के साथ फाइल रखने के लिए यह काफी बेमानी है और इसमें केवल 4-8 लाइनर वर्ग शामिल हैं .....
कोड नेविगेशन भी 10 फ़ाइलों के बीच स्विच करने के बजाय सिर्फ एक फ़ाइल पर स्क्रॉल करना आसान है ... इसका रिफ्लेक्टर भी आसान है जब आपको 10 के बजाय सिर्फ एक संदर्भ को संपादित करना होगा .....
कुल मिलाकर 1 वर्ग प्रति फ़ाइल का आयरन नियम तोड़ना आपके कोड को व्यवस्थित करने के लिए कुछ अतिरिक्त स्वतंत्रता प्रदान करता है ।
फिर क्या होता है, यह वास्तव में आपकी आईडीई, भाषा, टीम संचार और आयोजन कौशल पर निर्भर करता है।
लेकिन अगर आप चाहते हैं कि यह स्वतंत्रता लोहे के शासन के लिए बलिदान क्यों करे?
यदि आप एक टीम पर काम कर रहे हैं, तो अलग-अलग फ़ाइलों में कक्षाएं रखने से स्रोत को नियंत्रित करना आसान हो जाता है और संघर्ष की संभावना कम हो जाती है (कई डेवलपर्स एक ही समय में एक ही फ़ाइल को बदलते हैं)। मुझे लगता है कि जिस कोड को आप ढूंढ रहे हैं उसे ढूंढना आसान हो जाता है।
मेरे द्वारा हमेशा जाने वाला नियम एक ही नाम की फ़ाइल में एक मुख्य वर्ग है। मैं उस फ़ाइल में सहायक कक्षाओं को शामिल कर सकता हूँ या नहीं कर सकता हूँ जो इस बात पर निर्भर करता है कि वे फ़ाइल के मुख्य वर्ग के साथ कैसे युग्मित हैं। क्या सहायता वर्ग स्टैंडअलोन हैं, या क्या वे अपने आप उपयोगी हैं? उदाहरण के लिए, यदि किसी वर्ग में एक विधि को कुछ वस्तुओं को छांटने के लिए एक विशेष तुलना की आवश्यकता होती है, तो यह तुलना करने वाले फ़ंक्शनल वर्ग को उसी फ़ाइल में बंडल करने के लिए मुझे परेशान नहीं करता है, जिस तरीके से इसका उपयोग किया जाता है। मैं इसे कहीं और इस्तेमाल करने की उम्मीद नहीं करूंगा और इसका कोई मतलब नहीं है।
यह भविष्य के विकास और स्थिरता के दृष्टिकोण से खराब हो सकता है। यह याद रखना बहुत आसान है कि अगर आपके पास Car.cs क्लास है तो कार क्लास कहाँ है। अगर Widget.cs मौजूद नहीं है, तो आप विजेट वर्ग की तलाश कहाँ करेंगे? क्या यह एक कार विजेट है? क्या यह एक इंजन विजेट है? ओह शायद यह एक बैगेल विजेट है।
फ़ाइल स्थानों पर विचार करने का एकमात्र समय तब होता है जब मुझे नई कक्षाएं बनानी होती हैं। अन्यथा मैं कभी फ़ाइल संरचना द्वारा नेविगेट नहीं करता । मैं "कक्षा में जाता हूँ" या "परिभाषा पर जाएँ" का उपयोग करें।
मुझे पता है कि यह कुछ हद तक एक प्रशिक्षण मुद्दा है; परियोजनाओं की भौतिक फ़ाइल संरचना से खुद को मुक्त करने के लिए अभ्यास की आवश्यकता होती है। हालांकि यह बहुत फायदेमंद है;)
यदि उन्हें एक ही फाइल में रखना अच्छा लगता है, तो मेरे अतिथि बनें। खिचड़ी भाषा हालांकि जावा में सार्वजनिक वर्गों के साथ;)
जैसा कि प्रोग्रामिंग में इतना समय सच है, यह स्थिति पर बहुत निर्भर करता है।
उदाहरण के लिए, प्रश्न में कक्षाओं का सामंजस्य क्या है? क्या वे कसकर युग्मित हैं? क्या वे पूरी तरह से ऑर्थोगोनल हैं? क्या वे कार्यक्षमता से संबंधित हैं?
यह एक वेब फ्रेमवर्क के लिए एक सामान्य उद्देश्य की आपूर्ति करने के लिए लाइन से बाहर नहीं होगा। बेसवर्ट, टेक्स्टविडगेट, चारविडगेट, इत्यादि युक्त फ़ाइल।
फ्रेमवर्क का एक उपयोगकर्ता अपने विशिष्ट डोमेन स्थान के लिए फ्रेमवर्क विजेट से प्राप्त अतिरिक्त विजेट्स को शामिल करने के लिए एक अधिक_विजेट्स फ़ाइल को परिभाषित करने में लाइन से बाहर नहीं होगा।
जब कक्षाएं ऑर्थोगोनल होती हैं, और एक-दूसरे के साथ कोई लेना-देना नहीं होता है, तो एकल फ़ाइल में समूह बनाना वास्तव में कृत्रिम होगा। एक रोबोट कारखाने का प्रबंधन करने के लिए एक आवेदन मान लें जो कारों का निर्माण करता है। कारपार्ट्स और रोबोटपार्ट्स वाले भागों को एक फ़ाइल कहा जाता है, जो संवेदनहीन होगा ... रखरखाव के लिए स्पेयर पार्ट्स के ऑर्डर और कारखाने द्वारा निर्मित भागों के बीच बहुत अधिक संबंध होने की संभावना नहीं है। इस तरह के जुड़ने से आपके द्वारा डिज़ाइन किए जा रहे सिस्टम के बारे में कोई जानकारी या ज्ञान नहीं होगा।
शायद अंगूठे का सबसे अच्छा नियम अंगूठे के नियम से आपकी पसंद को बाधित नहीं करता है। अंगूठे के नियम पहले कट विश्लेषण के लिए बनाए जाते हैं, या उन लोगों की पसंद को बाधित करने के लिए जो अच्छे विकल्प बनाने में सक्षम नहीं हैं। मुझे लगता है कि अधिकांश प्रोग्रामर यह मानना चाहेंगे कि वे अच्छे निर्णय लेने में सक्षम हैं।
आपको ऐसा करने से बचना चाहिए, जब तक कि आपके पास एक अच्छा कारण न हो।
कई छोटे संबंधित वर्गों के साथ एक फ़ाइल कई फ़ाइलों की तुलना में अधिक पठनीय हो सकती है। उदाहरण के लिए, 'केस क्लासेस' का उपयोग करते समय, यूनियन प्रकारों का अनुकरण करने के लिए, प्रत्येक वर्ग के बीच एक मजबूत संबंध होता है। कई वर्गों के लिए एक ही फाइल का उपयोग करने से उन्हें पाठक के लिए एक साथ समूहबद्ध करने का लाभ मिलता है।
आपके मामले में, एक कार और एक दरवाजा बिल्कुल संबंधित नहीं लगता है, और car.cs फ़ाइल में दरवाजा क्लास को ढूंढना अप्रत्याशित होगा, इसलिए नहीं।
फ़ाइल का एक वर्ग बनाए रखने के लिए सरल है और आपके कोड को देखने वाले किसी अन्य व्यक्ति के लिए बहुत अधिक स्पष्ट है। यह कुछ भाषाओं में अनिवार्य, या बहुत प्रतिबंधित है।
उदाहरण के लिए, आप प्रति फ़ाइल कई उच्च स्तरीय कक्षाएं नहीं बना सकते हैं, उन्हें अलग-अलग फ़ाइलों में होना चाहिए जहाँ क्लासनाम और फ़ाइल नाम समान हैं।
स्मॉलटाक उत्तर है: आपके पास (प्रोग्रामिंग के लिए) फाइलें नहीं होनी चाहिए। वे संस्करण और नेविगेशन को दर्दनाक बनाते हैं।