517

मैं सोच रहा था कि क्या कोई मुझे इसका अवलोकन दे सकता है कि मैं उनका उपयोग क्यों करूंगा और इस प्रक्रिया में मुझे क्या फायदा होगा।

c# class architecture

— Asterix
स्रोत

यहाँ भी देखें: softwareengineering.stackexchange.com/questions/71494/…

— RenniePet

422

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

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

— JaredPar
स्रोत

70

आंशिक वर्गों से पहले कितनी बुरी चीजें थीं, इसके बारे में आपको बुरे सपने देने के लिए आपको देने के लिए प्रलोभन दिया गया :)

— जॉन बी

9

@ जॉन :), मुझे लगता है कि हम सभी को बुरे सपने आए हैं।

— JaredPar

18

एक बार मैंने एक कोड जनरेटर लिखा था जो 36K से अधिक लाइनों का उत्पादन करता है (या शायद बहुत अधिक, मैं बिल्कुल ठीक नहीं करता हूं), और स्रोत को खोलने पर मेरे संपादकों को अवरुद्ध कर दिया गया था। आंशिक वर्गों ने मुझे हविन 4 जीबी रैम के बिना उत्पादित कोड को देखने की अनुमति दी।

— लुका

6

मैं यह कहना चाहूंगा कि उत्पादन कोड में आंशिक वर्गों के लिए यह एकमात्र उपयोग है। हालांकि मैं स्वीकार करता हूं कि यह रिफैक्टिंग के लिए उपयोगी हो सकता है।

— गॉर्डन मैकएलेस्टर

5

@ गोर्डन - हमरगु का जवाब एक और है जो मुझे लगता है कि इसके खिलाफ बहस करना काफी कठिन है। आंशिक कक्षाएं C # में इंटरफेस को लागू करने के लिए बहुत आसान हो सकती हैं, और इंटरफ़ेस सदस्यों को कक्षा के सदस्यों से स्पष्ट रूप से अलग रख सकती हैं: stackoverflow.com/questions/3601901/why-use-partial-classes/…

— STW

260

एक अन्य उपयोग विभिन्न इंटरफेस के कार्यान्वयन को विभाजित करने के लिए है, जैसे:

partial class MyClass : IF1, IF2, IF3
{
    // main implementation of MyClass
}


partial class MyClass
{
    // implementation of IF1
}

partial class MyClass
{
    // implementation of IF2
}

— relascope
स्रोत

6

अच्छी बात! यह कुछ ऐसा है जो मैंने पहले किया है और इसके बारे में भूल गया हूं, लेकिन निश्चित रूप से इंटरफ़ेस सदस्यों को स्पष्ट रूप से रखने का एक अच्छा तरीका है (विशेष रूप से सी # में, क्योंकि VB.NET Implementsकीवर्ड का उपयोग करता है एक विधि इंटरफ़ेस से संबंधित है)

— STW

2

बहुत अच्छा बिंदु, प्रत्येक इंटरफ़ेस को एक डेवलपर द्वारा कार्यान्वित किया जा सकता है, साथ ही यह इंटरफ़ेस के कार्यान्वयन को आसानी से खोजने का अच्छा तरीका है।

— कोकाबी

3

वर्गों की घोषणा के क्रम में आईएफ 1, या आईएफ 2 .. के लिए कोई कैसे जानता है?

— कुलदीप

17

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

— इंक्रेडिबल

4

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

— किम

170

अन्य उत्तरों के अलावा ...

मैंने उन्हें देव-कक्षाओं को फिर से लाने में एक कदम-पत्थर के रूप में मददगार पाया है। यदि किसी वर्ग की कई ज़िम्मेदारियाँ हैं (विशेषकर यदि यह एक बहुत बड़ी कोड-फ़ाइल है) तो मुझे आयोजन के लिए प्रथम-पास के रूप में 1x आंशिक वर्ग-प्रति-जिम्मेदारी जोड़ने के लिए लाभकारी लगता है और फिर कोड को फिर से भरना है।

यह बहुत मदद करता है क्योंकि यह कोड को वास्तव में निष्पादित व्यवहार को प्रभावित किए बिना कोड को अधिक पठनीय बनाने में मदद कर सकता है। यह तब भी पहचानने में मदद कर सकता है जब एक जिम्मेदारी को दूर करना आसान होता है या अन्य पहलुओं के साथ कसकर उलझ जाता है।

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

— STW
स्रोत

23

बहुत अच्छा: "... विकास के अंत में आप अभी भी एक जिम्मेदारी प्रति वर्ग ( आंशिक वर्ग के अनुसार नहीं ) चाहते हैं ..."

— kokabi

मेरे लिए, यह एक अच्छी कोडिंग शैली नहीं है, लेकिन खराब कोड बेहतर बना सकते हैं।

— थीमफील्ड

मैं इससे पूरी तरह सहमत हूं। यह खराब कोड को ठीक करने की दिशा में एक अच्छा कदम है। एक देव वर्ग एक देव वर्ग का मौसम है जो कई फाइलों में फैला हुआ है या नहीं।

— Jimbo

84

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

बिंदु 4 को सत्यापित करने के लिए। बस एक जीत परियोजना बनाएं और इस लाइन को फॉर्म 1 कंस्ट्रक्टर के बाद शामिल करें और कोड को संकलित करने का प्रयास करें
```
partial void Ontest(string s);
```

आंशिक कक्षाओं को लागू करते समय विचार करने के लिए यहां कुछ बिंदु दिए गए हैं: -

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

— hellowahab
स्रोत

1

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

— मार्सेलो बार्बोसा

मेरी भी यही चिंताएं हैं। मैं उन लाभों को जानना चाहता हूं "यदि कोई हो" जो कि एक आंशिक वर्ग के पास मॉडल बनाते समय होता है कि एंटिटी फ्रेमवर्क अनिवार्य रूप से एक कोड फर्स्ट परिप्रेक्ष्य / दृष्टिकोण / कार्यान्वयन से मेरे डेटाबेस का निर्माण करेगा ... आपके पास क्या है।

— शेफ_कोड

@JimBalter कृपया इस लिंक msdn.microsoft.com/en-us/library/6b0scde8(v=vs.110).aspx पर जाएं । यह बताता है कि यदि कोई कार्यान्वयन मौजूद नहीं है तो संकलक कोड का टुकड़ा निकाल देगा और कोई संकलन समय त्रुटि प्राप्त नहीं होगी।

— नरकवास

यदि आपको एक आंशिक वर्ग पर एक वर्ग या इंटरफ़ेस विरासत में मिला है तो यह उस आंशिक वर्ग के सभी भागों द्वारा विरासत में मिला है।

— लाल मटर

56

एक महान उपयोग हाथ से लिखे गए कोड से उत्पन्न कोड को अलग कर रहा है जो एक ही कक्षा में हैं।

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

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

— जस्टिन नेसनेर
स्रोत

21

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

public partial class Product
{
    // 50 business logic embedded in methods and properties..
}

public partial class Product
{
    // another 50 business logic embedded in methods and properties..
}
//finally compile with product.class file.

एक अन्य संभावित उपयोग यह हो सकता है कि एक से अधिक डेवलपर एक ही वर्ग पर काम कर सकते हैं क्योंकि वे विभिन्न स्थानों पर संग्रहीत हैं। लोग हंस सकते हैं लेकिन आप कभी नहीं जानते कि यह कभी-कभी मुट्ठी भर हो सकता है।

Product1.cs

public partial class Product
{
    //you are writing the business logic for fast moving product
}

Product2.cs

public partial class Product
{
    // Another developer writing some business logic...
}

आशा है कि यह समझ में आता है!

— कौसर अहमद
स्रोत

13

आंशिक कक्षाओं में कई फाइलें होती हैं।

आप C # वर्ग घोषणा पर आंशिक संशोधक का उपयोग कैसे कर सकते हैं?

आंशिक कक्षाओं के साथ, आप भौतिक रूप से एक वर्ग को कई फाइलों में अलग कर सकते हैं। यह अक्सर कोड जनरेटर द्वारा किया जाता है।

उदाहरण

सामान्य C # कक्षाओं के साथ, आप एक ही प्रोजेक्ट में दो अलग-अलग फ़ाइलों में एक क्लास घोषित नहीं कर सकते। लेकिन partialसंशोधक के साथ , आप कर सकते हैं।

यह उपयोगी है अगर एक फ़ाइल को आम तौर पर संपादित किया जाता है और दूसरा मशीन-जनरेट किया जाता है या शायद ही कभी संपादित किया जाता है।

यहाँ एक उदाहरण स्पष्ट करना है:

class Program
{
    static void Main()
    {
        A.A1();
        A.A2();
    }
}

फ़ाइल की सामग्री A1.cs: C #

using System;

partial class A
{
    public static void A1()
    {
        Console.WriteLine("A1");
    }
}

फ़ाइल की सामग्री A2.cs: C #

using System;

partial class A
{
    public static void A2()
    {
        Console.WriteLine("A2");
    }
}

आउटपुट:

A1
A2

यहां आंशिक आवश्यकता है।

यदि आप partialसंशोधक को हटाते हैं , तो आपको इस पाठ में एक त्रुटि मिलेगी:

[नामस्थान ' <global namespace>' में पहले से ही ' A' के लिए एक परिभाषा है ]।

सुझाव:

इसे ठीक करने के लिए, आप या तो partialकीवर्ड का उपयोग कर सकते हैं , या क्लास के नामों में से एक को बदल सकते हैं।

आंशिक वर्गों के साथ C # संकलक कैसे व्यवहार करता है?

यदि आप उपरोक्त प्रोग्राम (IL Disassembler का उपयोग करके) को अलग करते हैं, तो आप देखेंगे कि A1.cs और A2.cs फाइलें समाप्त हो गई हैं। आप पाएंगे कि क्लास ए मौजूद है।

कक्षा A में समान कोड ब्लॉक में A1 और A2 के तरीके होंगे। दोनों वर्गों को एक में मिला दिया गया।

A1.cs और A2.cs का संकलित परिणाम: C #

internal class A
{
    // Methods
    public static void A1()
    {
        Console.WriteLine("A1");
    }

    public static void A2()
    {
        Console.WriteLine("A2");
    }
}

सारांश

आंशिक कक्षाएं कुछ C # प्रोग्रामिंग स्थितियों को सरल बना सकती हैं।
विंडोज फॉर्म / WPF प्रोग्राम बनाते समय अक्सर विजुअल स्टूडियो में इनका उपयोग किया जाता है।
मशीन द्वारा निर्मित C # कोड अलग है।
या आप यहाँ पूरा विवरण पा सकते हैं ।

— विवेक सौरव
स्रोत

2

अच्छा उदाहरण और अच्छी तरह से प्रलेखित।

— शेफ_कोड

1

यह इमो का पालन करने के लिए सबसे आसान स्पष्टीकरण है।

— युषा

12

विशाल वर्ग के साथ काम करते समय, या टीम पर काम करते समय, जितना संभव हो सके सब कुछ साफ रखें, आप बिना ओवरराइड किए (या हमेशा सुधार के बिना) संपादन कर सकते हैं

11

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

— cletus
स्रोत

8

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

उदाहरण के लिए, यदि आपके पास चर्चा मंच और उत्पादों की प्रणाली वाली साइट के लिए डेटाबेस है, और आप दो अलग-अलग प्रदाता कक्षाएं नहीं बनाना चाहते हैं (प्रॉक्सी क्लास के रूप में एक ही बात नहीं है, तो बस स्पष्ट होना चाहिए), आप कर सकते हैं विभिन्न फ़ाइलों में एक ही आंशिक वर्ग बनाएँ, जैसे

MyProvider.cs - कोर तर्क

MyProvider.Forum.cs - विशेष रूप से मंच से संबंधित तरीके

MyProvider.Product.cs - उत्पादों के लिए तरीके

यह सिर्फ चीजों को व्यवस्थित रखने का एक और तरीका है।

साथ ही, जैसा कि अन्य लोगों ने कहा है, यह अगली बार कक्षा के पुनर्जीवित होने पर आपके परिवर्धन को नष्ट करने के जोखिम के बिना एक उत्पन्न वर्ग के तरीकों को जोड़ने का एकमात्र तरीका है। यह टेम्पलेट-जनरेट (T4) कोड, ORMs, आदि के साथ काम आता है।

— 3Dave
स्रोत

2

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

— STW

@STW: यह हो सकता है कि विभिन्न कार्यों के लिए कई ऑब्जेक्ट इंस्टेंस बनाए और उपयोग किए जाएं। विभिन्न कार्यों को अलग-अलग वर्गों में अलग करने से नीचे ट्रैक करने की आवश्यकता होगी कि कौन से उदाहरणों का उपयोग किन कार्यों के लिए किया गया है - संभावित रूप से स्रोत मॉड्यूल के बीच कोड के केवल चलती ब्लॉकों की तुलना में बहुत बड़ा उपक्रम।

— सुपरकैट

4

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

— STW

1

@ सुपरकैट - मैंने यह अर्हता प्राप्त करने की कोशिश की कि "अगर एक आंशिक रूप से अन्य चिंताओं से अलग हो जाता है ... तो यह एक छोटा प्रयास है"। असंगति के दर्द से गुजरना आमतौर पर लंबे समय तक रखरखाव में बड़ी बचत करेगा, यदि रोगाइन नहीं

— STW

2

संयोग से, मैं इन दिनों रोजलिन को संशोधित करने की कोशिश कर रहा हूं, और यह आंशिक कक्षाओं के व्यापक उपयोग के साथ लिखा गया है। रोसलिन के बहुत सारे प्रमुख वर्ग और कई फाइलों में आंशिक कक्षाओं के रूप में परिभाषित किया गया है। और रोजलिन को उन लोगों द्वारा लिखा गया था जिन्हें मैं कम से कम, बहुत चालाक सी # प्रोग्रामर मानता हूं।

— RenniePet

8

पूर्व-संकलक निर्देशों के विकल्प के रूप में।

यदि आप पूर्व-संकलक निर्देशों (अर्थात् #IF DEBUG) का उपयोग करते हैं, तो आप अपने वास्तविक रिलीज कोड के साथ अंतःक्रियात्मक रूप से देख रहे हैं।

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

— STW
स्रोत

मोनोगेम इस रणनीति का उपयोग करता है।

— जाम्बोनी

6

सेवा संदर्भ एक अन्य उदाहरण है जहां आंशिक कक्षाएं उपयोगकर्ता-निर्मित कोड से उत्पन्न कोड को अलग करने के लिए उपयोगी हैं।

जब आप सेवा संदर्भ को अद्यतन करते हैं, तो आप उन्हें अधिलेखित किए बिना सेवा वर्गों को "विस्तारित" कर सकते हैं।

— फ्रांसेस्को डी विटोरी
स्रोत

6

एक और उपयोग मैंने देखा है,

डेटा एक्सेस लॉजिक के बारे में एक बड़े अमूर्त वर्ग का विस्तार,

मेरे पास Post.cs, Comment.cs, Pages.cs नाम के साथ विभिन्न फाइलें हैं ...

in Post.cs 

public partial class XMLDAO :BigAbstractClass
{
// CRUD methods of post..
}


in Comment.cs 

public partial class XMLDAO :BigAbstractClass
{
// CRUD methods of comment..
}

in Pages.cs 

public partial class XMLDAO :BigAbstractClass
{
// CRUD methods of Pages..
}

— श्रीनिवास रेड्डी थातीर्थी
स्रोत

6

ज्यादातर लोग टिप्पणी करते हैं कि partialकेवल एक वर्ग के लिए उपयोग किया जाना चाहिए जिसमें एक उत्पन्न कोड फ़ाइल या इंटरफेस है। मैं असहमत हूँ, और यहाँ क्यों है।

एक उदाहरण के लिए, आइए C # System.Math वर्ग को देखें ... वह वर्ग है । मैं एक ही कोड फ़ाइल में सभी 70 + विधियों को सामान करने का प्रयास नहीं करूंगा। इसे बनाए रखना दुःस्वप्न होगा।

प्रत्येक गणित विधि को अलग-अलग आंशिक श्रेणी की फाइलों में, और सभी कोड फाइलों को प्रोजेक्ट में एक मैथ फोल्डर में रखने से काफी क्लीनर संगठन होगा।

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

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

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

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

— deegee
स्रोत

4

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

आंशिक पब्लिक क्लास zzFileConverterRegistrar
    घटना रजिस्टर (zVFileConverter के रूप में byVal mainConverter)
    सब रजिस्टर (बायल मेनकॉन्जर zzFileConverter के रूप में)
        स्थापना रजिस्टर
    अंत उप
एंड क्लास

प्रत्येक मॉड्यूल जो एक या एक से अधिक प्रकार के फ़ाइल कनवर्टर को पंजीकृत करना चाहता है, उसमें कुछ शामिल हो सकते हैं:

आंशिक पब्लिक क्लास zzFileConverterRegistrar
    निजी उप रजिस्टरगिफ (zzFileConverter के रूप में ByVal mainConverter) संभालती है
        mainConverter.RegisterConverter ("GIF", GifConverter.NewFactory)
    अंत उप
एंड क्लास

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

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

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

  RegisterConverter ("GIF", GifConvertor.NewFactory)
  RegisterConverter ("बीएमपी", BmpConvertor.NewFactory)
  RegisterConverter ("JPEG", JpegConvertor.NewFactory)

लेकिन एक और कनवर्टर मॉड्यूल को जोड़ने के लिए कनवर्टर कोड के उस हिस्से में जाने और नए कनवर्टर को सूची में जोड़ने की आवश्यकता होगी। आंशिक तरीकों का उपयोग करना, जो अब आवश्यक नहीं है - सभी कन्वर्टर्स स्वचालित रूप से शामिल हो जाएंगे।

— supercat
स्रोत

यह काम करता है, लेकिन इन मॉड्यूल को गतिशील रूप से लोड करने के लिए एक सरल प्लगइन-सिस्टम बहुत अच्छा होगा और एक दूसरे को भ्रष्ट करने वाले मॉड्यूल के जोखिम को खत्म करने में मदद करेगा (यह एक recompile की आवश्यकता के बजाय रनटाइम पर मॉड्यूल को लोड कर सकता है)

— STW

अगर वे zz_ वर्ग के साथ कुछ नहीं करते हैं, तो एक रजिस्टर ईवेंट को हुक करने और खुद को पंजीकृत करने के लिए एक रूटीन को कॉल करने पर मॉड्यूल को एक दूसरे को भ्रष्ट करने का जोखिम बहुत कम हो सकता है। आप क्या जोखिम देखते हैं जो प्लग-इन के साथ मौजूद नहीं होगा? प्लग-इन महान हैं यदि अंतिम उपयोगकर्ता को नए मॉड्यूल में "प्लग इन" करने की उम्मीद है। कभी-कभी, हालांकि, सभी एक ही exe में सभी कार्यक्षमता रखना चाहते हैं। स्रोत फ़ाइलों में प्लग करने में सक्षम होने के बिना मैन्युअल रूप से नए जोड़े गए फ़ाइलों के लिए एक संदर्भ जोड़ना आसान हो सकता है।

— सुपरकैट

1

जोखिम काफी हद तक आपकी लाइन में निहित है "... अगर वे कुछ भी नहीं करते [...] को छोड़कर ...", सुरक्षा और स्थिरता पूरी तरह से डेवलपर के सम्मेलन के बाद सवारी करती है, और 0% आश्वासन प्रदान करती है। यदि आपका उपयोग-मामला उन्हें संकलित करने के लिए है (पूरी तरह से मान्य है, तो बस एक विवेक व्यापार बंद करने की आवश्यकता है) तो क्यों न केवल अलग वर्गों और कुछ IModuleइंटरफ़ेस को लागू करने में मॉड्यूल को परिभाषित किया गया है?

— STW

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

— STW

3

आंशिक वर्गों ने हाल ही में स्रोत नियंत्रण के साथ मदद की जहां कई डेवलपर्स एक फाइल में जोड़ रहे थे जहां फ़ाइल के एक ही हिस्से में नए तरीके जोड़े गए थे (रेस्पर द्वारा स्वचालित)।

इन दबावों ने मर्ज की वजह से टकराव पैदा किया। मुझे नए तरीकों को पूर्ण कोड ब्लॉक के रूप में लेने के लिए मर्ज टूल को बताने का कोई तरीका नहीं मिला।

इस संबंध में आंशिक कक्षाएं डेवलपर्स को अपनी फ़ाइल के एक संस्करण से चिपके रहने की अनुमति देती हैं, और हम उन्हें बाद में हाथ से मर्ज कर सकते हैं।

उदाहरण -

MainClass.cs - फ़ील्ड, कंस्ट्रक्टर, आदि रखती है
MainClass1.cs - जैसा कि वे लागू करते हैं एक डेवलपर्स नया कोड
MainClass2.cs - उनके नए कोड के लिए एक और डेवलपर्स वर्ग है।

— नीलकंठ
स्रोत

3

से MSDN :

1. संकलित समय के लिए, आंशिक प्रकार की परिभाषाओं के गुणों को मिला दिया जाता है। उदाहरण के लिए, निम्नलिखित घोषणाओं पर विचार करें:

[SerializableAttribute]
partial class Moon { }

[ObsoleteAttribute]
partial class Moon { }

वे निम्नलिखित घोषणाओं के समतुल्य हैं:

[SerializableAttribute]
[ObsoleteAttribute]
class Moon { }

निम्नलिखित सभी आंशिक प्रकार की परिभाषाओं से विलय किए गए हैं:

XML टिप्पणियाँ
इंटरफेस
सामान्य प्रकार के पैरामीटर गुण
वर्ग गुण
सदस्यों

2. एक साधारण बात, नेस्टेड आंशिक वर्ग भी आंशिक हो सकते हैं:

partial class ClassWithNestedClass
{
    partial class NestedClass { }
}

partial class ClassWithNestedClass
{
    partial class NestedClass { }
}

— एली
स्रोत

1

यहाँ आंशिक वर्गों के कुछ फायदों की सूची दी गई है।

आप यूआई डिजाइन कोड और बिजनेस लॉजिक कोड को अलग कर सकते हैं ताकि पढ़ने और समझने में आसानी हो। उदाहरण के लिए आप Visual Studio का उपयोग करके एक वेब एप्लिकेशन विकसित कर रहे हैं और एक नया वेब फ़ॉर्म जोड़ रहे हैं, तो दो स्रोत फाइलें हैं, "aspx.cs" और "aspx.designer.cs"। इन दो फ़ाइलों में आंशिक कीवर्ड के साथ एक ही वर्ग है। ".Aspx.cs" वर्ग का व्यावसायिक तर्क कोड है जबकि "aspx.designer.cs" में उपयोगकर्ता इंटरफ़ेस नियंत्रण परिभाषा है।

स्वचालित रूप से उत्पन्न स्रोत के साथ काम करते समय, कोड को स्रोत फ़ाइल को फिर से बनाए बिना वर्ग में जोड़ा जा सकता है। उदाहरण के लिए आप LINQ से SQL में काम कर रहे हैं और एक DBML फ़ाइल बनाएँ। अब जब आप एक टेबल को ड्रैग और ड्रॉप करते हैं तो यह डिज़ाइनर में एक आंशिक क्लास बनाता है। क्लास में सभी टेबल कॉलम में गुण होते हैं। UI ग्रिड पर बाँधने के लिए आपको इस तालिका में और स्तंभों की आवश्यकता है, लेकिन आप डेटाबेस तालिका में एक नया स्तंभ जोड़ना नहीं चाहते हैं, इसलिए आप इस वर्ग के लिए एक अलग स्रोत फ़ाइल बना सकते हैं, जिसमें उस स्तंभ के लिए एक नई संपत्ति हो और यह होगा एक आंशिक वर्ग हो। ताकि डेटाबेस तालिका और DBML इकाई के बीच मानचित्रण प्रभावित हो लेकिन आप आसानी से एक अतिरिक्त क्षेत्र प्राप्त कर सकते हैं। इसका मतलब है कि आप सिस्टम जनरेट किए गए कोड के साथ बिना मैसेज किए भी कोड लिख सकते हैं।

एक से अधिक डेवलपर एक साथ वर्ग के लिए कोड लिख सकते हैं।

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

— शशि
स्रोत

1

जब भी मेरे पास एक वर्ग होता है जिसमें एक नेस्टेड वर्ग होता है जो किसी भी महत्वपूर्ण आकार / जटिलता का होता है, तो मैं कक्षा को चिह्नित करता हूं partialऔर नेस्टेड क्लास को एक अलग फ़ाइल में डाल देता हूं । मैं नियम का उपयोग करके नेस्टेड क्लास वाली फ़ाइल का नाम देता हूं: [वर्ग का नाम]। [नेस्टेड क्लास का नाम] .cs

निम्नलिखित MSDN ब्लॉग में स्थिरता के लिए नेस्टेड कक्षाओं के साथ आंशिक कक्षाओं का उपयोग करने के बारे में बताया गया है: http://blogs.msdn.com/b/marcelolr/archive/2009/04/13/use-partial-classes-with-nested-classes-for- maintainability.aspx

— Ǥमानंद ǤeezeƦ
स्रोत

1

मुझे पता है कि यह प्रश्न वास्तव में पुराना है, लेकिन मैं आंशिक वर्गों पर अपना ध्यान जोड़ना चाहूंगा।

एक कारण यह है कि मैं व्यक्तिगत रूप से आंशिक कक्षाओं का उपयोग करता हूं, जब मैं एक कार्यक्रम, विशेष रूप से राज्य मशीनों के लिए बाइंडिंग बना रहा हूं।

उदाहरण के लिए, ओपनजीएल एक राज्य मशीन है, ऐसे तरीकों के ढेर हैं जो सभी वैश्विक रूप से बदले जा सकते हैं, हालांकि, मेरे अनुभव में ओपनजीएल के समान कुछ बाध्यकारी है जहां बहुत सारे तरीके हैं, वर्ग आसानी से 10k एलओसी से अधिक हो सकता है।

आंशिक कक्षाएं मेरे लिए इसे तोड़ देंगी और जल्दी से विधियां खोजने में मेरी मदद करेंगी ।

0

आंशिक रूप से कोड जनरेटरों की मदद करने के लिए प्राथमिक कक्षाएं शुरू की जाती हैं, इसलिए हम (उपयोगकर्ता) अपने सभी काम / परिवर्तन उत्पन्न एएसपी की तरह खत्म नहीं करते हैं। जैसे कि हम पुन: उत्पन्न करते हैं, प्रत्येक बार ASP.NET के -designer.cs वर्ग की तरह लगभग सभी नए उपकरण उत्पन्न होते हैं। कोड LINQ, EntityFrameworks, ASP.NET, उत्पन्न कोड के लिए आंशिक कक्षाओं का उपयोग करते हैं, इसलिए हम आंशिक रूप से वर्गों और विधियों का लाभ लेते हुए इन उत्पन्न कोडों के तर्क को सुरक्षित रूप से जोड़ या बदल सकते हैं, लेकिन आंशिक कक्षाओं का उपयोग करके उत्पन्न कोड में सामान जोड़ने से पहले बहुत सावधानी से रहें। अगर हम रनटाइम त्रुटियों का परिचय देते हैं तो हम बिल्ड को तोड़ते हैं लेकिन सबसे खराब। अधिक जानकारी के लिए इस http://www.4guysfromrolla.com/articles/071509-1.aspx को देखें

— किरण भीमर्ती
स्रोत

0

मैं दो उपयोगों पर ध्यान देता हूं जिन्हें मैं स्पष्ट रूप से उत्तर में नहीं पा सकता था।

कक्षा आइटम समूहीकरण

कुछ डेवलपर्स अपनी कक्षा के विभिन्न "भागों" को अलग करने के लिए टिप्पणियों का उपयोग करते हैं। उदाहरण के लिए, एक टीम निम्नलिखित सम्मेलन का उपयोग कर सकती है:

public class MyClass{  
  //Member variables
  //Constructors
  //Properties
  //Methods
}

आंशिक कक्षाओं के साथ, हम एक कदम आगे जा सकते हैं, और वर्गों को अलग-अलग फ़ाइलों में विभाजित कर सकते हैं। एक सम्मेलन के रूप में, एक टीम प्रत्येक फ़ाइल को उसके अनुरूप अनुभाग के साथ प्रत्यय दे सकती है। इसलिए ऊपर में हमारे पास कुछ इस तरह होगा: MyClassMembers.cs, MyClassConstructors.cs, MyClassProperties.cs, MyClassMethods.cs।

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

//Methods - See partial class

स्टेटमेंट्स / नेमस्पेस का उपयोग करने का दायरा

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

— कोलम भंडाल
स्रोत

नामस्थान टकराव को हल करने के लिए तंत्र हैं, उदाहरण के लिए, किसी नाम स्थान का नाम बदलकर using Library1 = The.Namespace.You.Needयाglobal::Root.Of.Namespace

— fjch1997

हाँ, मुझे लगता है कि यह एक कमजोर उपयोग मामला है। लेकिन नामों को पूरी तरह से योग्य नहीं बनाना थोड़ा अच्छा है। आंशिक कक्षाओं का उपयोग करने के लिए एक कारण से एक अच्छा अनपेक्षित साइड इफेक्ट का अधिक।

— कोलम भंडाल

C # आंशिक कक्षाओं का उपयोग कब करना उचित है?

Product1.cs

Product2.cs

कक्षा आइटम समूहीकरण

स्टेटमेंट्स / नेमस्पेस का उपयोग करने का दायरा