मेरे पास एक फ़ाइल के लिए एक वर्ग होता था। उदाहरण के लिए car.cs कक्षा कार है। लेकिन जैसे ही मैं अधिक कक्षाओं को प्रोग्राम करता हूं, मैं उन्हें एक ही फाइल में जोड़ना चाहता हूं। उदाहरण के लिए car.cs वर्ग कार और दरवाजा वर्ग, आदिक्या यह एक ही फाइल में एकाधिक कक्षाएं रखने का एक बुरा अभ्यास है?
मेरा प्रश्न के लिए जावा, सी #, पीएचपी या किसी अन्य प्रोग्रामिंग भाषा अच्छा है। क्या मुझे एक ही फाइल में एकाधिक कक्षाएं रखने की कोशिश नहीं करनी चाहिए या यह ठीक है?
मुझे लगता है कि आपको अपना कोड 1 वर्ग प्रति फ़ाइल में रखने का प्रयास करना चाहिए।
मैं इसका सुझाव देता हूं क्योंकि बाद में आपकी कक्षा को ढूंढना आसान होगा। साथ ही, यह आपके स्रोत नियंत्रण प्रणाली के साथ बेहतर काम करेगा (यदि कोई फ़ाइल बदलती है, तो आप जानते हैं कि एक विशेष वर्ग बदल गया है)।
एक बार जब मुझे लगता है कि प्रति वर्ग एक से अधिक कक्षाओं का उपयोग करना सही है, तो आप आंतरिक कक्षाओं का उपयोग कर रहे हैं ... लेकिन आंतरिक कक्षाएं किसी अन्य वर्ग के अंदर हैं, और इस प्रकार एक ही फ़ाइल के अंदर छोड़ी जा सकती है। आंतरिक कक्षाओं की भूमिका बाहरी वर्गों से दृढ़ता से संबंधित होती है, इसलिए उन्हें एक ही फाइल में रखना ठीक है।
मुझे पता चला है कि जब भी मैं एक ही फ़ाइल में एकाधिक प्रकारों को गठबंधन करने का प्रयास करता हूं, तो मैं हमेशा वापस जा रहा हूं और उन्हें अलग कर रहा हूं क्योंकि इससे उन्हें ढूंढना आसान हो जाता है। जब भी मैं गठबंधन करता हूं, अंत में हमेशा एक पल होता है जहां मैं wtf को परिभाषित करने की कोशिश कर रहा हूं जिसे मैंने टाइप किया है x।
तो अब, मेरा व्यक्तिगत नियम यह है कि प्रत्येक व्यक्तिगत प्रकार (शायद बच्चे वर्गों के लिए छोड़कर, जिसके माध्यम से कक्षा के भीतर एक वर्ग, विरासत वर्ग नहीं है) अपनी फ़ाइल प्राप्त करता है।
यह भविष्य के विकास और रखरखाव के परिप्रेक्ष्य से बुरा हो सकता है। यह याद रखना बहुत आसान है कि कार श्रेणी कहां है यदि आपके पास Car.cs क्लास है। यदि विजेट.cs मौजूद नहीं है तो आप विजेट क्लास को कहां देखेंगे? क्या यह एक कार विजेट है? क्या यह एक इंजन विजेट है? ओह शायद यह एक bagel विजेट है।
यदि आप किसी टीम पर काम कर रहे हैं, तो अलग-अलग फाइलों में कक्षाओं को रखने से स्रोत को नियंत्रित करना आसान हो जाता है और विवादों की संभावना कम हो जाती है (एक ही समय में एक ही फाइल को बदलने वाले कई डेवलपर्स)। मुझे लगता है कि यह उस कोड को ढूंढना आसान बनाता है जिसे आप ढूंढ रहे हैं।
केवल मुझे लगता है कि फ़ाइल स्थानों पर विचार है जब मुझे नई कक्षाएं बनाना है। अन्यथा मैं कभी भी फ़ाइल संरचना द्वारा नेविगेट नहीं करता हूं। मैं "कक्षा में जाना" या "परिभाषा पर जाना" का उपयोग करता हूं।
मुझे पता है कि यह कुछ प्रशिक्षण समस्या है; परियोजनाओं की भौतिक फ़ाइल संरचना से खुद को मुक्त करने के लिए अभ्यास की आवश्यकता है। हालांकि यह बहुत फायदेमंद है;)
यदि उन्हें एक ही फ़ाइल में रखना अच्छा लगता है, तो मेरा अतिथि बनें। हालांकि जावा में सार्वजनिक वर्गों के साथ ऐसा करना चाहिए;)
अंगूठे के नियम के रूप में, एक वर्ग/एक फ़ाइल जाने का रास्ता है। हालांकि, मैं अक्सर एक फ़ाइल में कई इंटरफ़ेस परिभाषाओं को रखता हूं। एक फाइल में कई कक्षाएं? सिर्फ अगर वे कर रहे हैं बहुत बारीकी से किसी भी तरह से संबंधित है, और बहुत छोटे (< 5 तरीकों और सदस्य) फ़ाइल प्रति
एक वर्ग बनाए रखने के लिए सरल और अपने कोड को देखकर किसी और के लिए और अधिक स्पष्ट है। यह कुछ भाषाओं में भी अनिवार्य है, या बहुत प्रतिबंधित है।
उदाहरण के लिए जावा में, आप प्रति फ़ाइल एकाधिक शीर्ष स्तर कक्षाएं नहीं बना सकते हैं, उन्हें अलग-अलग फाइलों में होना चाहिए जहां क्लासनाम और फ़ाइल नाम समान हैं।
जावा में, एक सार्वजनिक प्रति फ़ाइल कक्षा भाषा काम करने का तरीका है। जावा फ़ाइलों का एक समूह पैकेज में एकत्र किया जा सकता है।
पाइथन में, हालांकि, फ़ाइलें "मॉड्यूल" हैं, और आमतौर पर कई करीबी संबंधित कक्षाएं होती हैं। एक पायथन पैकेज एक जावा पैकेज की तरह एक निर्देशिका है।
इससे पायथन क्लास और पैकेज के बीच समूह का एक अतिरिक्त स्तर प्रदान करता है।
कोई भी सही उत्तर नहीं है जो भाषा-अज्ञेयवादी है। यह भाषा के साथ बदलता है।
नियम जो मैं हमेशा जाता हूं वह एक ही नाम वाली फ़ाइल में मुख्य कक्षा है। मैं उस फ़ाइल में सहायक वर्गों को शामिल कर सकता हूं या नहीं, इस पर निर्भर करता हूं कि वे फ़ाइल की मुख्य कक्षा के साथ कितनी कसकर हैं। क्या समर्थन वर्ग स्टैंडअलोन हैं, या वे स्वयं पर उपयोगी हैं? उदाहरण के लिए, यदि किसी वर्ग में किसी विधि को कुछ ऑब्जेक्ट्स को सॉर्ट करने के लिए विशेष तुलना की आवश्यकता होती है, तो यह मुझे तुलना करने वाले तरीके के समान फ़ाइल में तुलना करने वाले फ़ैक्टर क्लास को बंडल करने के लिए थोड़ा परेशान नहीं करता है। मैं इसे कहीं और इस्तेमाल करने की उम्मीद नहीं करता हूं और इसके लिए यह समझ में नहीं आता है कि यह स्वयं ही है।
प्रति फ़ाइल एक वर्ग एक अच्छा नियम है, लेकिन कुछ अपवाद बनाना उचित है। उदाहरण के लिए, अगर मैं एक परियोजना जहां अधिकांश वर्गों संग्रह प्रकार संबद्ध कर दिया है में काम कर रहा हूँ, कई बार मैं कक्षा और एक फ़ाइल में अपने संग्रह, जैसे रखेंगे:
public class Customer { /* whatever */ }
public class CustomerCollection : List<Customer> { /* whatever */ }
अंगूठे का सबसे अच्छा शासन करने के लिए है प्रति वर्ग एक वर्ग रखें, सिवाय इसके कि जब चीजों को आसान बनाने के बजाय कठिन बनाना शुरू हो जाता है। चूंकि विजुअल स्टूडियो की फाइलों में खोजें बहुत प्रभावी है, इसलिए आपको शायद फ़ाइल संरचना के माध्यम से देखने में ज्यादा समय नहीं लगेगा।
नहीं। यह बुरी सलाह है। स्वीकृत उत्तर की सलाह लें। आपको ऑब्जेक्ट रिपोजिटरी को आपके द्वारा सहेजने वाले वर्ग से अलग करना चाहिए। यह बस अनजान भ्रम पैदा करता है। – Hudson
प्रोग्रामिंग में इतना समय सच है, यह स्थिति पर काफी निर्भर करता है।
उदाहरण के लिए, प्रश्नों में कक्षाओं की समेकन क्या है? क्या वे कसकर युग्मित हैं? क्या वे पूरी तरह से ऑर्थोगोनल हैं? क्या वे कार्यक्षमता से संबंधित हैं?
यह एक वेब रूपरेखा BaseWidget, TextWidget, CharWidget युक्त फ़ाइल widgets.whatever एक सामान्य प्रयोजन की आपूर्ति करने, आदि
ढांचे के एक उपयोगकर्ता को परिभाषित करने में लाइन से बाहर नहीं होगा के लिए लाइन से बाहर नहीं होगा एक और_विजेट्स फ़ाइल को उनके विशिष्ट डोमेन स्पेस के लिए फ्रेमवर्क विगेट्स से प्राप्त अतिरिक्त विजेट्स को शामिल करने के लिए फ़ाइल।
जब कक्षाएं ऑर्थोगोनल होती हैं, और एक-दूसरे के साथ कुछ लेना-देना नहीं है, तो एक फ़ाइल में समूह करना वास्तव में कृत्रिम होगा। कार बनाने वाले रोबोट फैक्ट्री को प्रबंधित करने के लिए एक एप्लिकेशन मानें। कार्पर्ट्स और रोबोटपार्ट्स वाले हिस्सों नामक एक फ़ाइल बेवकूफ होगी ... रखरखाव के लिए स्पेयर पार्ट्स के ऑर्डर और कारखाने के निर्माण के हिस्सों के बीच संबंधों के बीच अधिक संबंध होने की संभावना नहीं है। इस तरह की एक जॉइनिंग आपके द्वारा डिजाइन की जा रही प्रणाली के बारे में कोई जानकारी या ज्ञान नहीं जोड़ती है।
शायद अंगूठे का सबसे अच्छा नियम अंगूठे के नियम द्वारा आपके विकल्पों को बाधित नहीं करता है। अंगूठे के नियम पहले कट विश्लेषण के लिए बनाए जाते हैं, या उन लोगों के विकल्पों को बाधित करने के लिए जो अच्छे विकल्प बनाने में सक्षम नहीं हैं। मुझे लगता है कि ज्यादातर प्रोग्रामर यह मानना चाहते हैं कि वे अच्छे निर्णय लेने में सक्षम हैं।
नहीं, मुझे नहीं लगता कि यह पूरी तरह से खराब अभ्यास है। इसका मतलब यह है कि सामान्य रूप से प्रति वर्ग एक अलग फ़ाइल होना सर्वोत्तम होता है, लेकिन निश्चित रूप से अच्छे अपवाद मामले हैं जहां एक फ़ाइल में कक्षाओं का समूह होना बेहतर होता है। इसका एक अच्छा उदाहरण अपवाद वर्गों का एक समूह है, यदि आपके पास किसी दिए गए समूह के लिए इनमें से कुछ दर्जन हैं, तो क्या वास्तव में यह समझ में आता है कि प्रत्येक दो लाइनर वर्ग के लिए अलग फ़ाइल अलग करनी है? मैं बहस नहीं करता। इस मामले में एक वर्ग में अपवादों का एक समूह बहुत कम बोझिल और सरल IMHO है।
स्मॉलटॉक उत्तर है: आपके पास फाइलें (प्रोग्रामिंग के लिए) नहीं होनी चाहिए। वे संस्करण और नेविगेशन दर्दनाक बनाते हैं।
आपको ऐसा करने से बचना चाहिए, जब तक कि आपके पास कोई अच्छा कारण न हो।
कई छोटी संबंधित कक्षाओं वाली एक फ़ाइल कई फाइलों की तुलना में अधिक पठनीय हो सकती है। उदाहरण के लिए, यूनियन प्रकारों को अनुकरण करने के लिए 'केस क्लास' का उपयोग करते समय, प्रत्येक वर्ग के बीच एक मजबूत संबंध होता है। एकाधिक वर्गों के लिए एक ही फ़ाइल का उपयोग पाठक के लिए उन्हें एक साथ समूहबद्ध करने का लाभ है।
आपके मामले में, कार और दरवाजा बिल्कुल संबंधित नहीं लगता है, और car.cs फ़ाइल में द्वार वर्ग ढूंढना अप्रत्याशित होगा, इसलिए नहीं।
के बाद से अपने आईडीई " को नेविगेट करें" कार्यक्षमता एक साथ आप प्रदान करता है और आप पर कुछ नियंत्रण नेमस्पेसिंग अपनी कक्षाओं के भीतर तो एक ही फ़ाइल के भीतर कई वर्गों होने के लिए नीचे दिए गए लाभ है मेरे लिए यह काफी लायक हैं ।
जनक - बाल वर्ग
कई मामलों में मैं इसे काफी उपयोगी उनके बेस कक्षा फ़ाइल के भीतर कक्षाओं पारंपरिक रूप से प्राप्त करने के लिए लगता है।
यह देखने के लिए काफी आसान है कि आपके बच्चे वर्ग के कौन से गुण और तरीके विरासत में हैं और फ़ाइल समग्र कार्यक्षमता का एक तेज़ अवलोकन प्रदान करती है।
लोक: छोटा - सहायक - डीटीओ वर्ग
जब आप एक विशिष्ट कार्यक्षमता के लिए कई सादा और छोटे वर्गों की जरूरत है मैं यह काफी सभी संदर्भों के साथ एक फ़ाइल के लिए निरर्थक पाते हैं और सिर्फ एक 4-8 लाइनर वर्ग के लिए भी शामिल है .....
कोड नेविगेशन सिर्फ ओ से अधिक स्क्रॉल भी आसान होता है बजाय 10 के बीच फ़ाइलों स्विच करने का ne फ़ाइल ... इसकी भी आसान करने के लिए refactor जब आप 10 के बजाय सिर्फ एक संदर्भ ..... संपादित करने के लिए
फ़ाइल प्रति 1 वर्ग के आयरन नियम को तोड़ने कुल मिलाकर अपने कोड को व्यवस्थित करने के लिए कुछ अतिरिक्त स्वतंत्रता प्रदान करता है।
तब क्या होता है, वास्तव में आपके आईडीई, भाषा, टीम संचार और आयोजन कौशल पर निर्भर करता है।
लेकिन यदि आप स्वतंत्रता चाहते हैं तो इसे लौह शासन के लिए क्यों त्यागें?
जैसा कि http://stackoverflow.com/questions/360643/is-it-a-bad-practice-to-have-multiple-classes-in-the-same-file/360675#360675 में बताया गया है, आम के साथ नेविगेशन टूल्स जिन्हें आपको फाइल द्वारा नेविगेट करने की ज़रूरत नहीं है। आप इसके बजाए कक्षाओं/सदस्यों द्वारा नेविगेट करते हैं। – Suma