2010-04-13 20 views
5

कहें कि मेरे पास दो वर्ग हैं, और उनमें से कोई भी जीयूआई घटक नहीं हैं। क्लास ए एक अल्पकालिक उद्देश्य यह है कि एक घटना उदाहरणक्या मुझे घटनाओं को अपनाने के लिए निपटान करने की आवश्यकता है?

public A(B b) 
{ 
    b.ChangeEvent += OnChangeEvent; 
} 

एक बी के कार्यक्रम से कभी नहीं deregisters हैं के लिए एक लंबे रहते थे वस्तु बी द्वारा घोषित के लिए पंजीकरण करता है, एक कचरा एकत्र किया जा कभी नहीं होगा है? क्या किसी को बस बी की घटना से वंचित करने के लिए एक निपटान विधि की आवश्यकता है?

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

उत्तर

3

आपके पहले प्रश्न पर: हां। बी का ए संदर्भ है। इस तरह ए बी के रूप में लंबे समय तक जी रहेगा। यदि आप उदा। यूआई ऐप में मेमोरी को खोने का यह एक अच्छा तरीका है। App.OnIdle जैसे किसी ईवेंट के साथ पंजीकरण करें।

दूसरे के लिए: अंत में सब कुछ मारे जायेंगे।

0

यदि बी ए के संदर्भ में है, ए को कचरा नहीं मिलेगा जब तक कि बी कचरा संग्रह के लिए भी योग्य नहीं है।

आपको इसके लिए एक निपटान विधि की आवश्यकता नहीं है। एक बार बी के पास कोई संदर्भ नहीं है, तो कचरा कलेक्टर बी और ए

दोनों को निपटाने के लिए पर्याप्त स्मार्ट होगा, यदि वे दोनों आवेदन के जीवन के लिए जीवित हैं, तो आपको घटना को अपनाने की आवश्यकता नहीं है।

+0

... जब तक ए कचरा संग्रह के लिए योग्य नहीं है। –

+0

जैसा कि जॉन ने कहा, ए के बारे में क्या? – Sean

+0

@ सेन, मेरे पास बी और ए उलट था। एक बार बाहरी संदर्भ बी से हटा दिए जाते हैं, ए को भी निपटाया जाएगा। – kemiller2002

1

घटना को डिस्कनेक्ट करने के लिए उचित स्थान, जैसा कि आपको संदेह है, IDisposable.DisposeA की विधि में होगा। वास्तव में कोई अच्छा विकल्प नहीं है। A के फाइनलाइज़र/विनाशक के भीतर ईवेंट को डिस्कनेक्ट करने का प्रयास करना बेकार होगा, क्योंकि से डिस्कनेक्ट होने से पहले A कचरा संग्रह के लिए योग्य होगा, B के लिए कचरा संग्रह के लिए योग्य बनने के लिए होगा; एक बार ऐसा हुआ है, सदस्यता एक महत्वपूर्ण मुद्दा बन जाएगी, इससे कोई फर्क नहीं पड़ता कि यह साफ हो गया था या नहीं।

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

संबंधित मुद्दे

 संबंधित मुद्दे