c# - आप फ़ाइलों में सी#कोड कैसे व्यवस्थित कर सकते हैं?




code-organization (6)

एक दर्जन से कम कक्षाओं के साथ छोटी परियोजनाओं के लिए, प्रति फ़ाइल केवल एक वर्ग

उद्यम परियोजनाओं के लिए मेरे पास एक समाधान में कई परियोजनाएं हैं I वे उद्देश्यों (व्यवसाय वर्ग, इंटरफेस, यूआई) द्वारा समूहबद्ध हैं। प्रत्येक वर्ग की अपनी फाइल है

सी # में, किस प्रकार के बनाने के प्रश्न, उनके सदस्यों को क्या होना चाहिए, और किन नामों को उन्हें रखना चाहिए, ओ ओ डिज़ाइन के प्रश्न हैं वे प्रश्न नहीं हैं जिनके बारे में मुझे दिलचस्पी है I

इसके बजाय, मैं पूछना चाहता हूं कि आप इन डिस्क कलाकृतियों में कैसे स्टोर करते हैं। यहां कुछ उदाहरण नियम दिए गए हैं:

  • एक एकल स्रोत फ़ाइल में एक विधानसभा के सभी प्रकार को रखें। एक मित्र ने यह कहते हुए कहा कि "फाइलें एक आकाशीय कोड संगठन उपकरण हैं, आज मैं क्लाउडव्यू और मेरे कोड को ब्राउज़ करने के लिए परिभाषाओं का संकलन" का उपयोग करता हूं।

  • अपने सभी कोड को एक विधानसभा में रखें तैनाती और संस्करण आसान बना देता है

  • निर्देशिका संरचना नाम स्थान संरचना दर्शाती है

  • प्रत्येक नाम स्थान का अपना असेंबली होता है।

  • प्रत्येक प्रकार अपनी विधानसभा में चला जाता है (एक चरम उदाहरण के रूप में सूचीबद्ध है।)

  • प्रत्येक प्रकार की अपनी स्वयं की स्रोत फ़ाइल होती है

  • प्रत्येक सदस्य को अपनी फाइल मिली; प्रत्येक प्रकार की अपनी निर्देशिका हो जाती है (एक चरम उदाहरण के रूप में सूचीबद्ध है।)


मैं इस तरह के संगठन को जो भी भाषा में पसंद करता हूं

अपनी फाइल (फाइलें) में संबंधित छोटे वर्ग

अपनी फाइल में बड़ी कक्षाएं

अलग उपप्रोजेक्ट के लिए निर्देशिकाएं


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

नेस्टेड प्रकारों के लिए अलग-अलग फ़ाइलों का उपयोग करना ओवरकिल जैसा लगता है, कम से कम अगर नेस्टेड क्लास अपेक्षाकृत सरल 'सहायक' वर्ग हैं, और खासकर इसलिए यदि वे निजी हैं

अपने दोस्त की "एक बड़ी फाइल में सब कुछ" योजना के मुख्य व्यावहारिक आक्षेप यह है कि विजुअल स्टूडियो बहुत लंबी कोड फाइलों से निपटने की कोशिश करता है, बहुत धीमा होता है


मैं यह काफी इसी तरह करते हैं एक बिंदु जहां मैं अलग होता हूं:

  • प्रति फ़ाइल एक प्रकार

मैं उन प्रतिनिधियों के प्रकारों को घोषित करता हूं जहां मुझे उनकी ज़रूरत है, अर्थात् उनकी अपनी फ़ाइल में नहीं, बल्कि उन वर्गों में जो उनका उपयोग करता है


कोई भी प्रकार कितना छोटा नहीं है, प्रत्येक प्रकार को एक अलग फ़ाइल में रखें- अपवाद: नेस्टेड क्लासेस और प्रतिनिधि

वैसे, आंशिक कक्षा का उपयोग करके अपनी फाइल में एक नेस्टेड प्रकार को रखने के एकमात्र उद्देश्य के लिए अलग करना एक ओपेकिल जैसा लगता है आंशिक कक्षाओं को विवेकानुसार उपयोग किया जाना चाहिए और आम तौर पर फाइल पीढ़ी के उपकरणों के लिए उपयोग किया जाना चाहिए - आपको नेस्टेड क्लासेस के लिए "आंशिक" नाम कैसे "नाम" करना है भौतिक नेस्टेड फ़ाइल के लिए सहज ज्ञान युक्त नाम के साथ चलना चुस्त और हो सकता है और यह निश्चित रूप से एक सरल कार्य नहीं है।

परियोजनाओं के लिए, नामस्थानों को प्रदर्शित करने के लिए अपनी परियोजनाओं को नाम दें- अपवाद: जब नेस्टेड नेमस्पेस बड़ा हो जाता है, तो मैं नेस्टेड फ़ोल्डर को एक और प्रोजेक्ट में माइग्रेट कर दूंगा।


जो भी आप करते हैं, कृपया इसे लगातार करें। मुझे विश्वास नहीं होता कि कोई एक भी जवाब है (हालांकि कुछ गलत हैं)। लेकिन सिर्फ यह सुनिश्चित कर लें कि आप अपने फॉर्म में सही रहें क्योंकि यह आपके उत्तराधिकारी (चीजों) के लिए चीजें आसानी से खोजने के लिए महत्वपूर्ण होगी।





code-organization