नेट दिशानिर्देशों के अनुरूप घटनाओं के क्या फायदे हैं?

Question

मैं समझता हूं कि नेट फ्रेमवर्क दिशानिर्देशों के अनुसार घटनाओं का उपयोग कैसे करें, लेकिन इस पैटर्न का उपयोग करने के क्या फायदे हैं?

http://msdn.microsoft.com/en-us/library/aa645739%28VS.71%29.aspx:

.नेट फ्रेमवर्क दिशा निर्देशों संकेत मिलता है कि प्रतिनिधि प्रकार की एक घटना के लिए इस्तेमाल किया दो पैरामीटर, एक "वस्तु स्रोत" पैरामीटर घटना के स्रोत का संकेत लेना चाहिए, और एक "ई "पैरामीटर घटना के बारे में कोई अतिरिक्त जानकारी encapsulates। का प्रकार "ई" पैरामीटर EventArgs क्लास से प्राप्त होना चाहिए। घटनाओं के लिए जो किसी भी अतिरिक्त जानकारी का उपयोग नहीं करते हैं, .NET Framework में पहले से ही एक उपयुक्त प्रतिनिधि प्रकार परिभाषित किया गया है: EventHandler।

ए) मुझे पहले ऑब्जेक्ट के रूप में "ऑब्जेक्ट स्रोत" मान का उपयोग करने में कुछ लाभ दिखाई देते हैं क्योंकि ऐसी स्थितियां हैं जहां कई ऑब्जेक्ट्स एक ही विधि में अपनी घटनाओं को सेट कर सकते हैं। इस प्रकार, यदि उदाहरण के लिए हमारे पास 10 ऑब्जेक्ट्स हैं और यदि सभी 10 ऑब्जेक्ट्स ईवेंट इवेंट हैंडलर एम पर सेट करते हैं, तो एम के अंदर हम इवेंट कॉल के आरंभकर्ता की पहचान करने के लिए "ऑब्जेक्ट प्रेषक" पैरामीटर मान का उपयोग कर सकते हैं।

• लेकिन जहां तक ​​मैं कह सकता हूं, "ऑब्जेक्ट स्रोत" पैरामीटर केवल तभी उपयोगी होता है जब ईवेंट किसी इंस्टेंस विधि के अंदर उठाया गया हो। इस प्रकार, यदि स्थैतिक विधि के अंदर घटना को उठाया गया था, तो "ऑब्जेक्ट स्रोत" पैरामीटर का कोई उपयोग नहीं है ?!

बी) क्या नेट फ्रेमवर्क दिशानिर्देशों के अनुसार घटनाओं का उपयोग करने के अन्य लाभ हैं?

ग) जो कुछ भी लाभ हो सकता है, इसलिए वे बाहर वजन करने के लिए

• एक वस्तु EventArgs से व्युत्पन्न में वांछित तर्क डाल करने के लिए एक अतिरिक्त कोड लिखने की मेहनत नहीं होगा
• एक अतिरिक्त बारे में EventArgs से प्राप्त ऑब्जेक्ट से जानकारी निकालने के लिए इवेंट हैंडलर के अंदर कोड?

आप

Answer 1

धन्यवाद जहाँ तक मुझे यह देखने के रूप में वहाँ दो प्रमुख लाभ हैं:

• लोग घटना लेने पैटर्न समझते हैं और तुरंत कैसे घटना का उपयोग करने के पता चल जाएगा कोड लिखने
• घटना का हस्ताक्षर इस तरह से तैयार किया गया है कि यह

पहला पोई एनटी बहुत स्पष्ट होना चाहिए, बहुत सारे विस्तार की जरूरत नहीं है।

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

अद्यतन
प्रश्नों के उत्तर:

मुझे यकीन है कि आप "होने बिना EventArgs का विस्तार करने में सक्षम घटना के हस्ताक्षर बदलकर" द्वारा क्या मतलब है नहीं कर रहा हूँ ?!

के एक उदाहरण लेते हैं, निम्नलिखित वर्ग ले:

public class SomeClass 
{ 
    public event EventHandler<FileEventArgs> SomethingHappened; 
} 
public class FileEventArgs : EventArgs 
{ 
    public FileEventArgs(string filename) 
    { 
     Filename = filename; 
    } 
    public string Filename { get; private set; } 
} 

तब हमारे पास एक उपभोक्ता है कि SomethingHappened घटना को सुनता है: कहते हैं कि

static void SomethingHappenedHandler(object sender, FileEventArgs e) 
{ 
    // do something intelligent 
} 

अब, देता है कि हम चाहते हैं फ़ाइल में जो हुआ उसके बारे में जानकारी के साथ हम उस सूचना को विस्तारित करते हैं:

public enum WhatHappened 
{ 
    Copy, 
    Rename, 
    Delete 
} 
public class FileEventArgs : EventArgs 
{ 
    public FileEventArgs(string filename, WhatHappened whatHappened) 
    { 
     Filename = filename; 
     WhatHappened = whatHappened; 
    } 
    public string Filename { get; private set; } 
    public WhatHappened WhatHappened { get; private set; } 
} 

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

Am मुझे लगता है कि यह सोचते हैं कि अगर घटना स्थिर विधि के अंदर उठाया है में लिखते हैं, तो "वस्तु स्रोत" पैरामीटर कोई उपयोग की है ?!

हाँ, यह सही है। मैं static घटनाओं (जो ईमानदारी से, बहुत दुर्लभ है) से प्रेषक तर्क के रूप में आमतौर पर null पास करता है।

Answer 2

अच्छी तरह से एक मानक दृष्टिकोण के मुख्य लाभों में से एक यह तथ्य है कि यह टिन पर जो कहता है वह करता है। एक मानक दृष्टिकोण का अर्थ है कि आपके कोड को देखकर कोई भी डेवलपर तुरंत क्या हो रहा है, और आपके ईवेंट का उपयोग कैसे करें।

Answer 3

यदि आप न केवल घटनाओं के लिए .NET Framework दिशानिर्देशों का पालन करते हैं, लेकिन सब कुछ के लिए, जो कोई व्यक्ति आपके कोड को पढ़ने या अपनी लाइब्रेरी का उपयोग करने की आवश्यकता है उसे पहचान लेगा, जिससे चीजों को उसके लिए आसान बना दिया जाएगा। यह हमेशा एक अच्छी बात है, क्योंकि आपको अपने पाठकों के लिए कोड लिखना चाहिए, न कि आपकी सुविधा के लिए। .NET के साथ अच्छी बात यह है कि सी ++ और इसी तरह के हजारों सम्मेलनों के विपरीत शुरुआत से ही कुछ मानक दिशानिर्देश है, और अधिकांश लोग इसे जानते हैं और इसे लागू करते हैं।

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

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

Answer 4

व्यक्तिगत रूप से, मैं इस निर्देश हर समय, केवल काम के लिए है कि आम पुन: उपयोग

क्यों के लिए प्रकाशित किया जाएगा का पालन नहीं करते?

• क्योंकि मैं हमेशा एक घटना
• के प्रेषक को पता है क्योंकि प्रतिनिधि बहस चलती जरूरत नहीं है - खासकर जब केवल एक - एक अलग वर्ग के लिए overkill

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

हां, तो हमेशा की तरह, "यह निर्भर करता है" और "अपनी खुद की निर्णय का उपयोग करें" लागू :-)

Answer 5

आप सामान्य घटना हैंडलर प्रतिनिधि (eventhandler < TEventArgs>) का उपयोग कर सकते है अगर आप मानक घटना का उपयोग हस्ताक्षर और घटनाक्रम से आपके कार्यक्रम तर्क प्राप्त होते हैं।

public event EventHandler<MyCustomEventArgs> MyEvent; 

http://msdn.microsoft.com/en-us/library/db0etb8x.aspx