.NET में प्रति फ़ाइल नियम एक वर्ग? [बन्द है]

Question

मैं इस नियम का पालन करता हूं, लेकिन मेरे कुछ सहयोगी इससे सहमत नहीं हैं और तर्क देते हैं कि यदि एक वर्ग छोटा है तो इसे उसी फ़ाइल में अन्य कक्षा (एस) के साथ छोड़ा जा सकता है।

एक और तर्क जो मैंने सुना है वह यह है कि "यहां तक ​​कि माइक्रोसॉफ्ट भी ऐसा नहीं करता है, इसलिए हमें क्यों करना चाहिए?"

इस पर आम सहमति क्या है? क्या ऐसे मामले हैं जहां इससे बचा जाना चाहिए?

Comments

अलग-अलग फाइलों में C # कक्षाओं

इसे भी देखें: प्रोग्रामर.स्टैकएक्सचेंज.

— com/questions/121365/…

Answer 1

प्रति फ़ाइल एक वर्ग आपको एक बेहतर आइडिया भी देता है कि फ़ाइल के अलग-अलग हिस्सों को देखे बिना प्रत्येक चेक क्या बदल रहा है।

Comments

एक ही फाइल में अधिक कक्षाएं केवल एक ऑपरेशन में संबंधित कक्षाओं के बीच अंतर को बढ़ाती हैं।

— लुका

उचित भिन्न दर्शक आपको एक कमिट के सभी अंतरों को देखने देते हैं।

— डायकम

मुझे पूरी तरह से यकीन नहीं है कि यह विशेष उत्तर मूल पोस्ट के प्रश्न (एस) का उत्तर कैसे है। सुनिश्चित करें कि यह एक फ़ाइल को 1 वर्ग रखने का एक कारण प्रदान करता है (हालांकि लुका और डायकम अच्छे अंक बनाते हैं), लेकिन यह आम सहमति को प्रतिबिंबित नहीं करता है या ऐसे मामलों को प्रदान करता है जब इसे टाला जाना चाहिए।

— रॉबर्ट डेविस

यदि आप सर्वोत्तम प्रथाओं को मानते हैं तो वे केवल एक दिए गए संदर्भ पर लागू होते हैं। जैसा कि अन्य प्रतिक्रियाएं बताती हैं कि ऐसे समय हैं जब यह नियम वास्तव में कम बनाए रखने योग्य कोड बनाएगा। जैसा कि उपकरण बेहतर होते हैं यह नियम वास्तव में कम प्रासंगिक हो जाता है क्योंकि किसी परियोजना के भीतर कक्षाएं और प्रकार खोजने में बहुत आसान है।

— abombss

Answer 2

मुझे इससे नफरत है जब लोग निरपेक्षता में सोचते हैं और कहते हैं कि आपको कभी भी ऐसा नहीं करना चाहिए या कुछ इस तरह से व्यक्तिपरक और नाइट-पिकी के साथ, जैसे कि हम सभी को सही और गलत के मूर्ख विचार के अनुरूप होना चाहिए। नीचे पंक्ति: प्रति फ़ाइल एक से अधिक वर्ग होने पर यह पूरी तरह से ठीक है अगर यह समझ में आता है। समझ में आने से मेरा मतलब है जैसे:

1. कोड को पचाने और बनाए रखने में आसान बनाता है
2. समाधान को कम कष्टप्रद (अनगिनत अनावश्यक फ़ाइलों के माध्यम से स्क्रॉल करना) और कम धीमा बनाता है
3. देव टीम एक स्थानीय कोडिंग अभ्यास के रूप में इसके साथ ठीक है

क्यों मैं प्रति फ़ाइल कई वर्गों के लिए चाहते हो सकता है का एक बहुत अच्छा उदाहरण:

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

Comments

1000। सर्वोत्तम प्रथाओं के लिए तर्क को समझना और उनका उल्लंघन करने से पहले दो बार सोचना महान है। सुस्त पालन करना बुराई है।

— dsimcha

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

— जेफ सैंटर्न

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

— जेम्स

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

— क्रिस्टन सम्मान

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

— ओयबेक

Answer 3

static bool GeneralRuleShouldBeFollowed(IGeneralRule rule, IUseCase useCase)
{
    return (rule.Overhead(useCase) 
            < My.PersonalThresholds.ConformismVsPracticality);
}

Comments

क्या .NET में ऐसा कोई नियम है? मैं भी मैं सिर्फ बयान परिणाम वापस आ गया होता। : ओ

— जोन वेंज

Answer 4

मैं कभी-कभी एक फ़ाइल के भीतर एक से अधिक वर्ग का समूह करता हूं यदि वे कसकर युग्मित होते हैं और उनमें से कम से कम एक बहुत छोटा होता है।

सामान्य 'सर्वोत्तम अभ्यास' प्रति कक्षा एक फ़ाइल है।

Comments

यदि आप समझते हैं कि वे युग्मित हैं, तो आप उन्हें क्यों नहीं बदल रहे हैं?

— मैट

@ द मैट: इसे ओवरइंजीनियरिंग से परहेज कहा जाता है। यदि आपके पास कुछ कसकर युग्मित वर्ग हैं और उन्हें डिकॉप्ल करना बहुत अधिक जटिलता जोड़ देगा, तो यह व्यावहारिक लचीलेपन की मात्रा की तुलना में बहुत अधिक है?

— dsimcha

कभी-कभी मुझे मूल रूप से "डेटा" कक्षाएं पसंद होती हैं जो केवल इस एक वर्ग द्वारा उपयोग की जाती हैं, इसलिए मैं आमतौर पर उपयोगकर्ता के रूप में डेटा-क्लास को उसी फ़ाइल में डाल देता हूं क्योंकि डेटाैक-लास में आमतौर पर कोई तर्क नहीं होता है और ऐसा लगता है जैसे इसके लिए एक नई फ़ाइल बनाने के लिए बेकार।

— अर्लज़

@ द मैट: कभी-कभी ऐसे हेल्पर वर्ग होते हैं, जो मैं युग्मन-स्वीकार्य के रूप में बहस करेंगे। वे एक अन्य वर्ग के हिस्से के लिए जटिलता को कम करते हैं लेकिन फिर भी उस वर्ग के लिए एक बहुत ही विशिष्ट उद्देश्य की सुविधा देते हैं।

— जॉर्डन पैरा

@ TheMatt: इसे घटाएँ : msdn.microsoft.com/en-us/library/… मॉड्यूल के बीच युग्मन खराब है, लेकिन एक तार्किक विशेषता के भीतर वर्गों के बीच सहयोग अपरिहार्य है।

— बेन वोइगट

Answer 5

काल्पनिक तर्कों से परे और विजुअल स्टूडियो आईडीई और बढ़ते सॉफ्टवेयर प्रोजेक्ट्स के साथ विंडोज .NET पर ध्यान केंद्रित करने के बजाय, यह सिर्फ इस संदर्भ में समझ में आता है कि प्रति फ़ाइल एक वर्ग है।

---

सामान्य तौर पर, दृश्य संदर्भ के लिए प्रति फ़ाइल एक वर्ग कुछ भी नहीं धड़कता है। वास्तव में।

मुझे नहीं पता कि Microsoft ऐसा करता है या नहीं करता है, हालांकि उन्होंने कई फ़ाइलों पर एक वर्ग को विभाजित करने के लिए partialकीवर्ड बनाया (यह और भी गंभीर है)। यह अक्सर अपने कस्टम कोड से ऑटो-जनरेट किए गए डिज़ाइनर कोड को एक ही क्लास में विभाजित करने के लिए उपयोग किया जाता है (लेकिन कभी-कभी इसका उपयोग विभिन्न डेवलपर्स को अलग-अलग फ़ाइलों के माध्यम से एक ही समय पर क्लास में काम करने की अनुमति देने के लिए किया जाता है)। इसलिए Microsoft कई फ़ाइलों के लाभ देखता है और हर किसी के पास .NET के साथ सुनिश्चित करने के लिए कई फ़ाइल संगठन विचार होते हैं।

नेस्टेड कक्षाओं के लिए आपके पास एक फ़ाइल का उपयोग करने के लिए या उनमें कक्षाओं के कम से कम पहले भागों के अलावा कोई विकल्प नहीं है। इस मामले में एक फ़ाइल आवश्यक और ठीक है:

class BicycleWheel {
    class WheelSpoke {
    }
}

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

इसके अतिरिक्त अगर आप नेमस्पेस के लिए फोल्डर का उपयोग करते हैं तो आपके पास कभी भी क्लास फाइलनाम क्लैश नहीं होगा। विजुअल स्टूडियो जैसे विकास के माहौल के अंदर नहीं होने पर फ़ाइल सिस्टम पर फ़ाइल नाम से एक वर्ग का पता लगाना सुविधाजनक है (जैसे कि यदि आप किसी क्लास को नोटपैड या कुछ त्वरित / प्रकाश के साथ संपादित करना चाहते हैं )।

इतने अच्छे कारण ...

Comments

धन्यवाद, "कम से कम उनमें से पहले भाग" से आपका क्या तात्पर्य है? तुम्हारा मतलब है कि तुम भी नेस्टेड वर्गों को अलग कर सकते हो?

— जोन वेंज

partialमेरे द्वारा बताए गए कीवर्ड का अप्रत्यक्ष संदर्भ है ।

— जॉन के

partial रिकॉर्डेड नेस्टेड क्लासेस के लिए msdn.microsoft.com/en-us/library/wa80x488(VS.80).aspx हो सकता है मैंने इसे जिज्ञासा से बाहर देखा।

— जॉन के

यह केवल यह दिखाने के लिए जाता है कि डिफ़ॉल्ट दृश्य तार्किक (नाम स्थान / वर्ग) होना चाहिए न कि भौतिक (फाइलें)।

— डेविड श्मिट

@DavidSchmitt वह है जो विज़ुअल स्टूडियो में क्लास व्यू है।

— ज़ैक

Answer 6

अधिकांश मामलों में, मैं एक वर्ग प्रति फ़ाइल नियम का पालन करता हूं। एकमात्र अपवाद जो मैं नियमित रूप से करता हूं, वह एक एनम की परिभाषा है जो एक विशिष्ट वर्ग को कसकर जोड़ा जाता है। उस एक मामले में, मैं अक्सर उस वर्ग की फाइल में एनुम की परिभाषा को शामिल करूंगा।

Answer 7

मैं भी मानता हूं कि एक ही फाइल में एक प्रकार शामिल होना चाहिए।

इस नियम का एक अपवाद है जिसका उल्लेख किया जाना चाहिए: दो वर्ग जो केवल एक सामान्य तर्क से भिन्न होते हैं जैसे:

RelayCommand     

तथा

RelayCommand<T>

Comments

क्या आप इस मामले में स्टाइलकॉप को खुश करने के लिए वर्कअराउंड जानते हैं?

— जॉर्ज पोलोवॉय

असहमत, सामान्य वर्गों के लिए एक और सम्मेलन है, फू 1.cs for फू <टी> `और फू 2.cs for फू <टी, टी 1>`।

— ओयबेक

@ ओयबेक: क्या होगा यदि मेरे पास फू <टी>, फू <यू> और फू <यू, टी> है? अब क्या?

— आंद्रेई रोनेया

@AndreiRinea एक ही नाम स्थान पर होना Foo<T>और होना असंभव है Foo<U>। लेकिन अगर नामस्थान भिन्न होते हैं, तो वे आमतौर पर अलग-अलग फ़ोल्डरों में होते हैं। इस प्रकार के लिए Foo<T>और Foo<U>यह फू 1.cs and for फू <यू, टी> `फू`2.cs होना चाहिए । लेकिन अभी भी प्रति फ़ाइल एक वर्ग।

— ओयबेक

जानकारी के लिए धन्यवाद! :)

— आंद्रेई रोनेया

Answer 8

वास्तव में, यह व्यक्तिगत पसंद को उबालता है। हर व्यक्ति "एक वर्ग प्रति फ़ाइल" कहेगा, लेकिन हम सभी के पास कुछ विशेष परिस्थितियों से बचने के लिए हमारे कारण हैं। मेरे पास एक बड़ी परियोजना थी जिसमें लगभग 300 अलग-अलग एनम थे। कोई रास्ता नहीं है कि मेरे पास 300 अलग-अलग फाइलें हैं, प्रत्येक वर्ग के लिए एक, जब कुछ एनम केवल त्रिकोणीय थे।

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

Comments

पुन: ढूंढें - जब मैं एक प्रकार की परिभाषा खोज रहा हूं, तो मैं यह नहीं देखना चाहता कि इसका उपयोग कहां किया गया है। इसके अलावा, फाइल्स को वर्णानुक्रम में क्रमबद्ध रूप से उन फाइलों की सूची में स्क्रॉल करने में अधिक समय लगता है, जिन्हें मैंने शायद पहले ही नाम से विभाजित कर दिया है।

— जेफ सैंटर्न

मुझे लगता है कि आपने संकेत दिया है कि आप कुछ ऐसे नामों से काम कर रहे हैं जिन्हें आप नेमस्पेस से विभाजित किया है। हम उन सभी भाग्यशाली नहीं हैं जो हमेशा उन परियोजनाओं के साथ काम करते हैं जिन्हें हम प्रबंधित करने में सक्षम हैं, दुर्भाग्य से।

— जेसन एम

Answer 9

कोई फर्क नहीं पड़ता कि सामग्री कितनी हल्की है, मुझे लगता है कि प्रति फ़ाइल एक वर्ग / इंटरफ़ेस / आदि आवश्यक है।

अगर मैं विज़ुअल स्टूडियो में एक बड़े समाधान पर काम कर रहा हूं तो मैं फ़ाइलों को देखने में सक्षम होना चाहता हूं और देखने के लिए अंदर नहीं पहुंचना चाहिए। यहां तक ​​कि ReSharper जैसे नेविगेशन टूल के साथ, मुझे 1: 1 मैपिंग चाहिए।

यदि आपको बहुत कम या बिना सामग्री वाली बहुत सी स्रोत फाइलें मिलती हैं (हो सकता है कि किसी वर्ग का विस्तार कर रहे हों, लेकिन उसमें कुछ भी न मिला रहे हों) तो शायद आपको अपने डिजाइन पर फिर से विचार करना चाहिए।

Answer 10

मुझे लगता है कि एक कक्षा को उसी फ़ाइल में मानक कारखाना वर्ग के साथ समूहीकृत करना बहुत उपयोगी है।

Answer 11

मेरे पास सामान्य रूप से प्रति फ़ाइल एक वर्ग होगा, लेकिन आपको यह देखने के लिए सामान्य रूप से अपने विवेक का उपयोग करना होगा कि क्या फ़ाइल में संबंधित वर्ग जैसे आपके अपवादों को समूहित किया जा सकता है जो कि स्वयं और अन्य डेवलपर्स द्वारा फिर से उपयोग किया जा सकता है। इस स्थिति में, उपयोगकर्ता को कई फ़ाइलों के बजाय केवल एक फ़ाइल को शामिल करने की आवश्यकता होती है।

तो मुद्दा यह है: विवेक का इस्तेमाल किया जाना चाहिए !!!

Comments

सही ज्ञान, प्रोग्रामिंग में कोई नियम कठिन और तेज नहीं है।

— चोसपंडियन

Answer 12

बड़े समाधानों में मुझे लगता है कि प्रति फ़ाइल एक वर्ग होना बहुत मूल्यवान है और उस फ़ाइल को कक्षा के समान नाम दिया गया है। इससे आपको उस कोड का पता लगाना बहुत आसान हो जाता है जिसमें आपको काम करने की आवश्यकता होती है।

Comments

मैं इस तर्क को ReSharper जैसे टूल से कम मूल्यवान समझता हूं। मैं CTRL + T करता हूं और जिस प्रकार की तलाश कर रहा हूं उसका नाम लिखना शुरू करता हूं।

— मार्क

हां, लेकिन क्या आप चाहते हैं कि आपकी एप्लिकेशन संरचना किसी तृतीय पक्ष उपकरण पर निर्भर हो?

— मैगस

@ मैग्नस मैं यह नहीं कह रहा था कि यह नहीं करने का कोई कारण नहीं है, लेकिन किसी व्यक्ति के लिए इसे करने के लिए एक तर्क की एक कम सम्मोहक।

— मार्क

Answer 13

C # के लिए StyleCop टूल में मानक नियम हैं जिनके लिए एक नामस्थान में एक से अधिक स्तरीय स्तर की आवश्यकता नहीं है (साथ ही उस नाम स्थान में किसी भी संख्या में इंटरफेस, डेलिगेट्स और एनमेट्स)।

दो या दो से अधिक वर्गों के मामलों में जहां दूसरी और बाद की कक्षाएं केवल पहले से ही उपयोग की जाती हैं, वे आंतरिक वर्ग होनी चाहिए, जो केवल उपभोग वर्ग के लिए दिखाई देती हैं।

Comments

जब आप कहते हैं "एक नाम स्थान में एक से अधिक शीर्ष स्तरीय वर्ग नहीं", तो आपका मतलब एक namespaceब्लॉक में है, है ना?

— डेनियल प्रेडेन

SA1403 के नियमों के अनुसार: AC # दस्तावेज़ में केवल एक ही नाम स्थान हो सकता है। SA1402: AC # दस्तावेज़ में रूट स्तर पर केवल एक ही वर्ग हो सकता है जब तक कि सभी वर्ग आंशिक न हों और एक ही प्रकार के हों।

— स्टीव गिल्हम

Answer 14

शायद ही कभी प्रति फ़ाइल एक वर्ग, लेकिन ...

जब कई कक्षाएं सख्ती से संबंधित होती हैं, तो एक ही स्रोत फ़ाइल में एक से अधिक वर्ग, IMHO, प्रत्येक वर्ग के लिए एक संक्षिप्त स्रोत फ़ाइल समर्पित करने से बेहतर होता है। स्रोत अधिक पठनीय और कॉम्पैक्ट है (और #region का उपयोग करके उसी स्रोत को पहले की तुलना में अधिक संरचित किया जा सकता है)।

यह भी विचार करें कि कभी-कभी यह एक ही वर्ग को अलग-अलग फ़ाइलों ( आंशिक का उपयोग करके ) में फैलाने के लिए आवश्यक है , क्योंकि 20000+ लाइन स्रोत फ़ाइल होने के कारण भी RAM मेरे पास उपलब्ध नहीं है (लेकिन यह एक और सवाल है)।

Comments

बेशक, आपको कोड की कई पंक्तियों के साथ एक वर्ग होने से बचने की कोशिश करनी चाहिए। मैं कहूँगा कि 1000+ भी बड़ी हो रही है। मुझे यह भी एहसास है कि यह हमेशा विरासत कोड में संभव नहीं है।

— पीटर

यदि आप स्रोत कोड उत्पन्न करने की कोशिश करते हैं (मेरा मामला ओपन स्पेस के लिए सी # बाइंडिंग की पीढ़ी है, जिसके हजारों प्रवेश बिंदु हैं) तो बहुत अधिक डेटा के लिए थोड़ा वर्ग सोचना मुश्किल है ...

— लुका

Answer 15

मौके पर मैं एक छोटे वर्ग को एक बड़े वर्ग के साथ छोड़ दूंगा, लेकिन केवल तभी जब वे किसी वस्तु की तरह बहुत कसकर संबंधित हों और यह संग्रह वर्ग या कारखाना हो।

हालांकि इसके साथ एक समस्या है। अंततः छोटी कक्षा उस बिंदु तक बढ़ती है जिस पर यह अपनी फ़ाइल में होना चाहिए, यदि आप इसे नई फ़ाइल में स्थानांतरित करते हैं तो आप अपने संशोधन इतिहास तक आसान पहुंच खो देते हैं।

अर्थात।

• सोमवार को मैं अपनी कक्षाओं x और y को फ़ाइल y.css में परिवर्तन करता हूँ
• मंगलवार को मैं अपनी ही फ़ाइल x.css में कक्षा x को अलग कर देता हूं क्योंकि यह बड़ी हो गई है
• वेडनसडे को मेरा बॉस देखना चाहता है कि मैं सोमवार को दसवीं कक्षा में क्या बदल गया हूं, इसलिए वह x.css के लिए इतिहास को देखता है, केवल x.css इतिहास को बदलने से पहले नहीं दिखाता है।

Comments

क्या होगा यदि "छोटा वर्ग" EventArgs के व्युत्पन्न की तरह कुछ है, जो आपकी कक्षा की घटनाओं के प्राप्तकर्ताओं को जानकारी देने के लिए है? क्या कोड को किसी क्लीनर या किसी अन्य फ़ाइल में स्थानांतरित करके बनाए रखना आसान होगा? यकीनन, इस तरह की चीज को एक नेस्टेड पब्लिक क्लास होना चाहिए, लेकिन उन पर भी इसका असर पड़ने लगता है। संशोधन इतिहास के अनुसार, क्या चैंज में वर्ग कहीं से प्रकट नहीं हुआ है, और कोड नोट में कोई टिप्पणी नहीं होनी चाहिए कि यह कहां से आया है?

— सुपरकैट

मैं इसे एक very tightly relatedवर्ग के रूप में वर्गीकृत करूँगा और इसे छोड़ दूंगा क्योंकि यह केवल स्क्रीन स्पेस की एक छोटी राशि लेता है और किसी अन्य वर्ग द्वारा उसी उद्देश्य के लिए उपयोग नहीं किया जाता है।

— जिंजरब्रेडबॉय

Answer 16

क्या यह वास्तव में एक समस्या है? :)
वास्तव में छोटे वर्ग, जैसे कि एनम, दूसरों के साथ एक साथ रखा जा सकता है। इसका पालन करने के लिए एक नियम है: केवल उन वर्गों को एक साथ रखें जिनमें कुछ सामान्य है।

विषयांतर के रूप में - मेरी एक परियोजना में मेरे पास एक फ़ाइल है जिसमें 150 कक्षाएं हैं। फ़ाइल में कोड की 10000 लाइनें हैं। लेकिन यह स्वतः उत्पन्न होता है इसलिए यह पूरी तरह स्वीकार्य है :)

Comments

मेरे पास 120 कक्षाओं के साथ एक ही फाइल है और आधा मिलियन लाइनों के साथ 750 उपवर्ग हैं, यह ऑटोजेनरेटेड भी है। यह समस्या है: यदि मैं इस पर क्लिक करता हूं, तो मुझे रिबूट करना होगा क्योंकि सब कुछ बंद हो जाता है।

— बेहारोज़

Answer 17

एक फ़ाइल में कई संबंधित कक्षाएं लगाने का एक कारण यह है कि आपके एपीआई का उपयोग करने वाले गरीब कमीने को आयात घोषणा बायलरप्लेट टाइप करने के लिए आधा दिन नहीं बिताना पड़ता है और गरीब कमीने को जो कोड बनाए रखना पड़ता है उसे आधा खर्च नहीं करना पड़ता है आयात घोषणा बायलरप्लेट के माध्यम से एक दिन स्क्रॉल करना। मेरे अंगूठे का नियम यह है कि यदि आप हमेशा एक ही समय के बजाय एक ही समय में एक बड़े उपसमूह का उपयोग करते हैं तो कई वर्ग एक ही फ़ाइल में होते हैं।

Comments

"आयात घोषणा बॉयलरप्लेट" से आपका क्या मतलब है? "बयानों का उपयोग करना"? लेकिन क्या कक्षाएं एक ही नाम स्थान पर होने वाली नहीं हैं?

— जोन वेंज

@ जोआन: मेरा मतलब है कि वास्तव में कुछ सरल पूरा करने के लिए 15 विभिन्न लेकिन संबंधित मॉड्यूलों का आयात करना। शायद यह विशेष रूप से C # पर लागू नहीं होता है। मैं वास्तव में C # नहीं जानता, लेकिन अन्य भाषाओं में यह एक बहुत कष्टप्रद समस्या है।

— dsimcha

धन्यवाद हाँ, इसलिए मैं उलझन में था।

— जोन वैज

Answer 18

मैं ऐसा करता हूं, लेकिन केवल जब कक्षाएं एक बच्चे-माता-पिता के फैशन से संबंधित होती हैं और बच्चे की कक्षाएं केवल माता-पिता द्वारा उपयोग की जाती हैं।

Comments

धन्यवाद, लेकिन आप इसे किसी अन्य फ़ाइल में अलग क्यों नहीं करते? बस उत्सुक।

— जोन वैज

@ थैंचमैन ने कहा है कि मेरे पास यह बहुत अधिक स्पष्ट है, खासकर जब बच्चा वस्तु बहुत छोटा है। यह व्यावहारिक रूप से मामला है कि बच्चा वर्ग केवल थोड़े से तर्क के साथ ही गुण

— रखता है

Answer 19

मैं आमतौर पर प्रति फ़ाइल एक कक्षा के साथ रहता हूं। लेकिन मैं इसी तरह के निर्माणों के समूहों के लिए अपवाद बनाऊंगा जिनका उपयोग परियोजना-व्यापी है। उदाहरण के लिए:

• एक EventArgs.cs जिसमें कोई भी EventArgsउपवर्ग शामिल हैं , क्योंकि वे आमतौर पर प्रत्येक कोड की केवल 5-10 लाइनें हैं, लेकिन वे आमतौर पर कई अलग-अलग वर्गों द्वारा उपयोग किए जाते हैं। वैकल्पिक रूप से, मैं EventArgsकक्षाओं को उसी फ़ाइल में रख सकता हूँ जिस वर्ग में घटनाओं की घोषणा होती है।
• एक Delegates.cs जिसमें वे डेलीगेट्स शामिल हैं जो पूरे प्रोजेक्ट में उपयोग किए जाते हैं, क्योंकि वे आमतौर पर केवल 1 पंक्ति प्रत्येक होते हैं। फिर से, विकल्प उन्हें उसी फ़ाइल में कक्षा के साथ रखना है जो उन्हें उजागर / खपत करता है।
• एक Enums.cs जिसमें enumसंपूर्ण प्रोजेक्ट में उपयोग किया गया है। (यदि enumकेवल एक वर्ग द्वारा इसका उपयोग किया जाता है, तो मैं आमतौर पर इसे privateउस कक्षा में बनाऊंगा।)

Answer 20

फ़ाइल के साथ एक वर्ग प्रति फ़ाइल के लिए एक और वोट वर्ग के रूप में नामित किया जा रहा है। मेरे लिए, यह दीर्घकालिक स्थिरता के साथ मदद करता है। मैं आसानी से रिपॉजिटरी के माध्यम से देख सकता हूं और देख सकता हूं कि परियोजना या किसी भी फाइल को खोलने के बिना कौन से वर्ग समाधान का हिस्सा हैं।

Answer 21

मैं इसे 99% समय का पालन करता हूं। मानकों का पालन करना अच्छा है, लेकिन मेरा मानना ​​है कि लचीलेपन की अपनी जगह है। कभी-कभी यह बस चीजों को तोड़ने के लिए समय की मूर्खतापूर्ण बर्बादी की तरह लगता है। उन समयों में, मैं खुद पर हावी हो जाता हूं और सिर्फ अपना कोड लिखता हूं।

Answer 22

अब तक की प्रतिक्रियाएं लोगों के अपवादों को नियम के इर्द-गिर्द घूमती दिखती हैं, इसलिए यहाँ मेरा है: मैं .NET3.5 SP1 में DataAnnotations पैकेज का उपयोग करते समय कक्षाओं और उनके मेटाडेटा 'मित्र' वर्गों को एक साथ रखता हूँ। अन्यथा, वे हमेशा अलग फ़ाइलों में रहते हैं। आप जानते हैं, ज्यादातर समय। सिवाय जब वे नहीं हैं।

Answer 23

मैं केवल यह शायद ही कभी करता हूं। उदाहरण के लिए यदि एक संलयन या संरचना है जो वर्ग से निकटता से संबंधित है फिर भी अपने आप से अलग होने के लिए बहुत तुच्छ है।

या उस मुख्य वर्ग के लिए कुछ विस्तार विधियों को रखने के लिए एक अलग वर्ग।

Answer 24

One case could be:जब आपकी कक्षाएं संयुक्त रूप से बनती हैं module / unitजो कुछ मुख्य वर्गों की सेवा करती हैं helper classes, जैसे अन्य बुद्धिमान नहीं ।

ASP.NET MVC 2.0 परियोजना स्रोत कोड पर एक नज़र है । यह इस नियम का सख्ती से पालन करता है

Answer 25

मुझे छोटी कक्षाएं बनाने और यह सुनिश्चित करने का विचार पसंद है कि वर्ग केवल वही कर रहा है जो उसे करना चाहिए। यदि आपके पास कई वर्ग हैं जो एक ही समस्या को हल करने में योगदान दे रहे हैं तो उन्हें एक ही फाइल में एक साथ रखने में कोई बुराई नहीं है।

मैं एमएस प्रथाओं का पालन नहीं करूंगा क्योंकि वे सबसे अच्छे कारखाने नहीं हैं!

Answer 26

एक अन्य बिंदु जो मैंने किसी और का उल्लेख नहीं देखा है वह यह है कि जब आप एक वर्ग प्रति फ़ाइल नियम का उपयोग कर विकसित करते हैं तो आप आसानी से देख सकते हैं कि विशिष्ट वर्ग क्या उपयोग कर रहा है।

उदाहरण के लिए: आपके पास दो वर्ग हो सकते हैं जहां एक वर्ग Linq का उपयोग करता है और दूसरा नहीं करता है।

यदि ये कक्षाएं एक ही फ़ाइल में थीं, तो आप कोड के माध्यम से देखे बिना यह नहीं बता पाएंगे कि कौन सी कक्षा किस का उपयोग करती है। जब यह प्रति फ़ाइल एक वर्ग है, तो आपको केवल उस कक्षा में देखने के लिए फ़ाइल के शीर्ष पर देखना होगा जो उस कक्षा में उपयोग किया जा रहा है। मदद करता है अगर आप कभी भी एक नए दायित्व आदि के लिए पलायन कर रहे हैं

Answer 27

वन-क्लास-प्रति-फ़ाइल का एक और कारण जो अब तक पोस्ट किए गए उत्तरों में उल्लेख नहीं किया गया है, वह यह है कि एक-क्लास-प्रति-फ़ाइल एक कोड समीक्षा के दौरान पीआर के प्रभाव को समझना आसान बनाता है। यह मर्ज की उलझनों को भी कम करता है।

जब कोई प्रतिक्रिया के लिए एक पीआर पोस्ट करता है मैं बदल गई फ़ाइलों की सूची को देख सकता हूं और तुरंत किसी भी ओवरलैप को देख सकता हूं जो मैं काम कर रहा हूं। ओवरलैप के आधार पर मैं उनके कोड को अधिक गहराई से देखना चाहता हूं या इसे ठीक कर सकता हूं क्योंकि मुझे पूरा विश्वास है कि यह मेरे स्वयं के परिवर्तनों को प्रभावित नहीं करेगा।

जब दो लोग एक बहु-श्रेणी फ़ाइल में काम कर रहे हैं और दोनों एक निर्भरता जोड़ते हैं तो एक अच्छा मौका है कि आपको usingशीर्ष पर ब्लॉक में मर्ज संघर्ष मिलेगा । कक्षाओं को फाइलों में अलग करना निर्भरता को अलग करता है ताकि आप देख सकें कि प्रत्येक वर्ग क्या उपयोग कर रहा है और आपको इस तरह के संघर्ष नहीं मिलते हैं।

इस नियम (इंटरफ़ेस + कार्यान्वयन, enums, ...) के अपवाद हैं, लेकिन यह विपरीत की तुलना में एक बेहतर शुरुआती स्थान है जो आमतौर पर जूनियर डेवलपर्स को असंबंधित वर्गों के सभी तरीके को एक ही फ़ाइल में बंडल करने देता है।

एक-वर्ग-प्रति-फ़ाइल एक स्पष्ट अस्पष्ट नियम है जो व्याख्या के अधीन नहीं है।

---

संबंधित-क्लास-इन-द-फ़ाइल व्यक्तिगत प्राथमिकताओं और व्याख्या के अधीन है (जैसा कि आप यहां अन्य सभी उत्तरों से देख सकते हैं कि यह कब उपयोग करना ठीक है) और इस तरह एक खराब नियम है।

Answer 28

आगे और पीछे बहुत दिलचस्प है, और प्रतीत होता है अनिर्णायक है, हालांकि मेरी सामान्य धारणा यह है कि वर्गों और फ़ाइलों के बीच 1-1 मानचित्रण बहुमत की राय है, हालांकि कुछ व्यक्ति-दर-व्यक्ति अपवादों के साथ।

यदि आप हैं, तो आपके किसी भी उत्तर के आधार पर मैं उत्सुक हूं: (1) विंडोज फॉर्म, वेब ऐप, लाइब्रेरी या जो कुछ भी हो, उसे विकसित करना; या (2) विजुअल स्टूडियो या नहीं का उपयोग कर। वीएस का उपयोग करने में, यह प्रतीत होगा कि फ़ाइल नियम के प्रति एक वर्ग भी वीएस परियोजना के प्रति एक वर्ग को लागू करेगा क्योंकि अन्य थ्रेड्स में सहमति यह प्रतीत होती है कि वीएस समाधान / परियोजनाओं को निर्देशिका / फ़ाइल नामकरण और संरचना में प्रतिबिंबित किया जाना चाहिए। वास्तव में, मेरी धारणा यह है कि सहमति के लिए प्रोजेक्ट का नाम = असेंबली नाम = (नेस्टेड) ​​नेमस्पेस नाम है, जो सभी तब निर्देशिका / फ़ाइल नामकरण और संरचना में प्रतिबिंबित किया जाएगा। यदि वे सही दिशा-निर्देश (या नियम) हैं, तो इन सभी प्रतीत होता है कि ऑर्थोगोनल आयोजन तंत्र फिर भी सिंक में रखे जाएंगे।

Answer 29

पठनीयता के लिए हाँ, हमारे पास प्रति कक्षा एक फ़ाइल होनी चाहिए! बस एक परियोजना में कूद गया। मुझे एक फाइल में कई कक्षाएं दिखाई देती हैं। यह सिर्फ एक नए आदमी के लिए इसे समझना इतना कठिन बना देता है। क्या हमें बनाए रखने की सोचनी चाहिए? जब हम एक सॉफ्टवेयर विकसित करते हैं? कई बार अन्य डेवलपर्स द्वारा विकास जारी रहेगा। हमारे पास हमारे सामान की व्यवस्था करने के लिए नाम स्थान है, हमें ऐसा करने के लिए फाइलों की आवश्यकता नहीं है!

Answer 30

प्रति फ़ाइल एक कोड आइटम, हाँ।

बाकी सब कुछ एक कदाचार है - और, काफी स्पष्ट रूप से, आरएडी पीड़ित का संकेत।

जैसे ही कोई उचित सॉफ़्टवेयर डेवलपमेंट (IoC, डिज़ाइन पैटर्न, DDD, TDD, आदि ...) शुरू करता है और "omg इसे पूरा करने देता है, मुझे पता नहीं है, लेकिन मुझे भुगतान किया जाता है" खेल का मैदान, कोई भी इसे देखेगा यह नियम वास्तव में, वास्तव में, मायने रखता है।