क्या .cs फ़ाइल के भीतर कई कक्षाएं बनाना उचित है या प्रत्येक .cs फ़ाइल में एक अलग वर्ग होना चाहिए?
उदाहरण के लिए:
public class Items
{
public class Animal
{
}
public class Person
{
}
public class Object
{
}
}एक मिनट के लिए इस तथ्य को दरकिनार करते हुए कि यह अच्छी वास्तुकला का एक खराब उदाहरण है, क्या एक कोड गंध में एकल वर्ग से अधिक एकल कोड है?
जवाबों:
आपके द्वारा दिया गया उदाहरण वास्तव में मेरी राय में ठीक है। आप आंतरिक कक्षाओं की घोषणा कर रहे हैं , इसलिए उन्हें एक ही फाइल में रखना पूरी तरह से समझदारी है । इसका एक ही तरीका है कि आपकी Itemsकक्षा को एक आंशिक वर्ग बनाया जाए और इसे कई फाइलों में विभाजित किया जाए। मैं इस बुरे अभ्यास पर विचार करता हूं। नेस्टेड वर्गों के लिए मेरी सामान्य नीति यह है कि वे छोटे और निजी होने चाहिए। इसके दो अपवाद हैं:
यदि आप प्रश्न को थोड़ा अलग करते हैं और "क्या मुझे प्रत्येक नेमस्पेस- क्लास को अपनी फ़ाइल में रखना चाहिए" के बारे में पूछते हैं, तो मेरा उत्तर "हाँ" होगा।
कक्षाएं डिजाइन करते समय हम एकल जिम्मेदारी सिद्धांत का सम्मान करते हैं। पठन कोड बहुत आसान हो जाता है यदि इसका आकार इसके शब्दार्थों का अनुसरण करता है, इसलिए कक्षा द्वारा फ़ाइलों को विभाजित करना समझदारी है।
एक यांत्रिक दृष्टिकोण से, प्रति वर्ग फ़ाइल होने के कई फायदे हैं। आप अलग-अलग विंडो में एक ही समय में कई कक्षाएं खोल सकते हैं। यह विशेष रूप से महत्वपूर्ण है क्योंकि कोई भी गंभीर डेवलपर दो से कम स्क्रीन के साथ काम नहीं करता है। मेरे सिर के सामने अधिक संदर्भ होने में सक्षम होने का मतलब है कि मैं अपने सिर में अधिक संदर्भ रख सकता हूं। (अधिकांश आईडीई की इच्छा आपको एक ही फाइल को दो बार खोलने की अनुमति देगी, लेकिन मुझे यह अजीब लगता है)।
अगला महत्वपूर्ण पहलू स्रोत नियंत्रण और विलय है। अपनी कक्षाओं को अलग रखकर, आप बहुत परेशानी से बचते हैं जब एक ही फाइल में बदलाव किए जाते हैं क्योंकि अलग-अलग कक्षाओं को बदलना पड़ता है।
क्रूरतापूर्वक ईमानदार होने के लिए, कृपया एक फ़ाइल में एक से अधिक रूट क्लास न जोड़ें। मेरी आखिरी नौकरी में, न केवल कई वर्गों के साथ फाइलें थीं, बल्कि कई नाम स्थान थे और यह कोड की कई हजारों लाइनों में फैला था। पालन करने की कोशिश करना बहुत मुश्किल है।
यदि ऐसी कक्षाएं हैं जो बारीकी से संबंधित हैं, तो या तो उनकी फ़ाइलों को समान रूप से नाम दें या उन्हें एक सबफ़ोल्डर में रखें।
वर्ग फ़ाइलों की भौतिक पृथक्करण से मदद मिलती है (ध्यान दें, अंत में सब कुछ नहीं होना चाहिए) चिंताओं का अलगाव और अधिक ढीली युग्मन।
दूसरी ओर, आपका उदाहरण एक से अधिक रूट क्लास नहीं दिखा रहा है। कई नेस्टेड क्लासेस हैं (ध्यान दें: नेस्टेड क्लासेस को कुछ भी बनाने की कोशिश न करें लेकिन privateअगर आप इसे डिज़ाइन कर सकते हैं) और यह एक फाइल में होना पूरी तरह से ठीक है।
यदि फाइलें अत्यधिक सामंजस्यपूर्ण हैं, उदाहरण के लिए, जहां यह कई बहुत छोटी, समान रूप से नामित फ़ाइलों के लिए एक विकल्प है, तो यह एक अच्छा विचार हो सकता है।
उदाहरण के लिए, मुझे पता है कि धाराप्रवाह NHibernate का उपयोग करते समय यह आसान है अगर मैं रखता हूं Entityऔर EntityMapएक ही फाइल में है, इसके बावजूद कि मेरे उपकरणों के बारे में क्या कहना है।
ज्यादातर मामलों में, यह सिर्फ कक्षाओं को खोजने में कठिन बनाता है। संयम और सावधानी के साथ उपयोग करें।
सीधे शब्दों में कहें, ऐसा करने के लिए इसका अच्छा रूप नहीं है और मैं आपको बताता हूं कि क्यों, थोड़ा बाद में जब आपका समाधान बड़ा हो जाता है तो आप भूल जाएंगे कि कक्षाएं कहां हैं क्योंकि फ़ाइल नाम अब प्रतिनिधित्व नहीं करेगा कि सामग्री क्या है, फ़ाइल नाम क्या है AnimalPersonObject.cs सिर्फ संभव नहीं है।
यकीन है कि आप इसे टाइप करने के लिए उपकरणों में सुविधाओं का उपयोग करके इसके आसपास प्राप्त कर सकते हैं, लेकिन टाइप करने के लिए कूदने के लिए, लेकिन 1 फ़ाइल प्रति फ़ाइल (इंटरफेस सहित) वास्तव में किसी भी कोड मानक की रीढ़ है जो मैंने कभी भी देखा है, न केवल नेट में बल्कि जावा और में। c ++ और बहुत सी अन्य भाषाएं, जिनके पास अक्सर रखरखाव के मुद्दे नहीं होते हैं और आपको जूनियर देवों को कोड को समझना मुश्किल होगा।
लगभग सभी कोड अनुकूलन उपकरण आपको एक अलग फ़ाइल में कक्षाओं को स्थानांतरित करने के लिए कहेंगे, इसलिए मेरे लिए हाँ यह एक कोड गंध है और इसे बेअसर करने के लिए कुछ बेदखल करने की आवश्यकता है :)
एक और मुद्दा यह है कि एक ही फ़ाइल में बहुत बड़ी और समान कक्षाओं के साथ - जब आप हर समय कक्षा की घोषणा को नहीं देख सकते हैं - तो आप गलत कक्षा में ब्रेकप्वाइंट लगा सकते हैं और सोच सकते हैं कि वे हिट क्यों नहीं होते ... ओह! :)