👨🏻‍🎓 🧞 🕍 डिस्पोजेबल पैटर्न (डिस्पोजेबल डिज़ाइन सिद्धांत) pt 3 😙 🎡 🧑🏼

बहु सूत्रण

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

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

इसके अलावा, यदि आप हमें धन्यवाद देना चाहते हैं, तो आप सबसे अच्छा तरीका यह कर सकते हैं कि हमें गितुब पर एक स्टार देना है या रिपॉजिटरी को फोर्क करना है github / sidristij / dotnetbook ।

public class FileWrapper : IDisposable { IntPtr _handle; bool _disposed; object _disposingSync = new object(); public FileWrapper(string name) { _handle = CreateFile(name, 0, 0, 0, 0, 0, IntPtr.Zero); } public void Seek(int position) { lock(_disposingSync) { CheckDisposed(); // Seek API call } } public void Dispose() { lock(_disposingSync) { if(_disposed) return; _disposed = true; } InternalDispose(); GC.SuppressFinalize(this); } [MethodImpl(MethodImplOptions.AggressiveInlining)] private void CheckDisposed() { lock(_disposingSync) { if(_disposed) { throw new ObjectDisposedException(); } } } private void InternalDispose() { CloseHandle(_handle); } ~FileWrapper() { InternalDispose(); } /// other methods }

_disposed () में _disposed सत्यापन कोड को एक महत्वपूर्ण अनुभाग के रूप में आरंभ किया जाना चाहिए। वास्तव में, सार्वजनिक विधियों के पूरे कोड को एक महत्वपूर्ण खंड के रूप में आरंभीकृत किया जाना चाहिए। यह समवर्ती प्रकार की एक सार्वजनिक विधि और इसके विनाश की विधि के लिए समवर्ती पहुंच की समस्या को हल करेगा। हालाँकि, यह अन्य समस्याएं लाता है जो टाइमबॉम्ब बन जाती हैं:

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

अब, दूसरी और, मेरी राय में, सबसे महत्वपूर्ण बात का नाम दें। हम एक वस्तु के विनाश की अनुमति देते हैं और उसी समय इसके साथ फिर से काम करने की उम्मीद करते हैं। इस स्थिति में हम क्या उम्मीद करते हैं? यह विफल हो जाएगा? क्योंकि यदि Dispose पहले चलता है, तो ObjectDisposedException के निम्नलिखित उपयोग से निश्चित रूप से ObjectDisposedException परिणाम होगा। इसलिए, आपको डिस्पोज़ () कॉल और अन्य प्रकार के अन्य सार्वजनिक तरीकों को सर्विस साइड, यानी उस कोड के बीच FileWrapper जो FileWrapper वर्ग का उदाहरण FileWrapper । ऐसा इसलिए है क्योंकि केवल बनाने वाला पक्ष जानता है कि वह एक वर्ग के उदाहरण के साथ क्या करेगा और इसे कब नष्ट करेगा। दूसरी ओर, एक डिस्पोज़ कॉल में केवल महत्वपूर्ण त्रुटियां उत्पन्न होनी चाहिए, जैसे कि OutOfMemoryException , लेकिन उदाहरण के लिए IOException नहीं। इसकी वजह यह है कि आईडीसोप्लिकेशन को लागू करने वाले वर्गों की वास्तुकला के लिए आवश्यकताएं हैं। इसका अर्थ है कि यदि एक बार में if(_disposed) return; को एक से अधिक थ्रेड से कॉल किया जाता है, तो एक एंटिटी का विनाश एक साथ दो थ्रेड्स से हो सकता है (हम if(_disposed) return; की जांच छोड़ देते if(_disposed) return; )। यह स्थिति पर निर्भर करता है: यदि कोई संसाधन कई बार जारी किया जा सकता है , तो अतिरिक्त जांच की आवश्यकता नहीं है। अन्यथा, सुरक्षा आवश्यक है:

 // I don't show the whole pattern on purpose as the example will be too long // and will not show the essence class Disposable : IDisposable { private volatile int _disposed; public void Dispose() { if(Interlocked.CompareExchange(ref _disposed, 1, 0) == 0) { // dispose } } }

डिस्पोजेबल डिज़ाइन सिद्धांत के दो स्तर

IDisposable को लागू IDisposable लिए सबसे लोकप्रिय पैटर्न क्या है जो आप .NET पुस्तकों और इंटरनेट में मिल सकते हैं? संभावित नई नौकरी के लिए साक्षात्कार के दौरान आपसे क्या पैटर्न अपेक्षित है? सबसे शायद यह एक:

 public class Disposable : IDisposable { bool _disposed; public void Dispose() { Dispose(true); GC.SuppressFinalize(this); } protected virtual void Dispose(bool disposing) { if(disposing) { // here we release managed resources } // here we release unmanaged resources } protected void CheckDisposed() { if(_disposed) { throw new ObjectDisposedException(); } } ~Disposable() { Dispose(false); } }

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

निपटान को वर्गों के दो स्तरों में विभाजित किया गया है:

स्तर 0 प्रकार सीधे अप्रबंधित संसाधनों को कूटबद्ध करते हैं
- वे या तो सार हैं या पैक हैं।
- सभी तरीकों को चिह्नित किया जाना चाहिए:
  - PrePrepareMethod, ताकि एक प्रकार लोड करते समय एक विधि संकलित की जा सके
  - SecuritySafeCritical प्रतिबंध के तहत काम करते हुए, कोड से कॉल से बचाने के लिए
  - विश्वसनीयताकंट्रेक्ट (संगति ।illNotCorruptState, Cer.Success / MayFail)] CER को एक विधि और उसके सभी चाइल्ड कॉल के लिए रखा जाए।
    - वे लेवल 0 प्रकारों का संदर्भ दे सकते हैं, लेकिन "अंतिम मील" में प्रवेश करने के सही क्रम की गारंटी के लिए वस्तुओं को संदर्भित करने के काउंटर को बढ़ाना चाहिए।
स्तर 1 प्रकार केवल प्रबंधित संसाधनों को संक्षिप्त करता है
- उन्हें केवल लेवल 1 प्रकार से विरासत में मिला है या सीधे आईडीआईसोपायरी लागू किया गया है
- वे लेवल 0 प्रकार या CriticalFinalizerObject का वारिस नहीं कर सकते हैं
- वे लेवल 1 और लेवल 0 प्रबंधित प्रकारों को इनकैप्सुलेट कर सकते हैं
- वे IDisposable को कार्यान्वित करते हैं। स्तर 0 प्रकार से शुरू होने वाली एन्कैप्सुलेटेड वस्तुओं को नष्ट करके और स्तर 1 पर जाकर
- वे एक फाइनल लागू नहीं करते हैं क्योंकि वे अप्रबंधित संसाधनों से निपटते नहीं हैं
- उनके पास एक संरक्षित संपत्ति होनी चाहिए जो स्तर 0 प्रकार तक पहुंच प्रदान करती है।

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

डिस्पोज़ का उपयोग करने के अन्य तरीके

आइडीआयोडीट के निर्माण के पीछे विचार मानव रहित संसाधनों को जारी करना था। लेकिन कई अन्य पैटर्न के साथ यह अन्य कार्यों के लिए बहुत उपयोगी है, जैसे प्रबंधित संसाधनों के संदर्भ जारी करना। हालांकि प्रबंधित संसाधन जारी करना बहुत मददगार नहीं लगता। मेरा मतलब है कि उन्हें उद्देश्य से प्रबंधित किया जाता है, इसलिए हम सी / सी ++ डेवलपर्स के बारे में मुस्कराहट के साथ आराम करेंगे, है ना? हालाँकि, ऐसा नहीं है। हमेशा एक ऐसी स्थिति हो सकती है जहां हम किसी वस्तु का संदर्भ खो देते हैं, लेकिन साथ ही यह सोचते हैं कि सब कुछ ठीक है: जीसी कचरा इकट्ठा करेगा, जिसमें हमारी वस्तु भी शामिल है। हालांकि, यह पता चला है कि स्मृति बढ़ती है। हम स्मृति विश्लेषण कार्यक्रम में आते हैं और देखते हैं कि कुछ और इस वस्तु को रखता है। बात यह है कि .NET प्लेटफ़ॉर्म और बाहरी कक्षाओं की वास्तुकला दोनों में आपकी इकाई के संदर्भ को निहित करने के लिए एक तर्क हो सकता है। जैसा कि कब्जा निहित है, एक प्रोग्रामर अपनी रिलीज की आवश्यकता को याद कर सकता है और फिर एक मेमोरी लीक प्राप्त कर सकता है।

प्रतिनिधि, घटनाएँ

आइए इस सिंथेटिक उदाहरण को देखें:

 class Secondary { Action _action; void SaveForUseInFuture(Action action) { _action = action; } public void CallAction() { _action(); } } class Primary { Secondary _foo = new Secondary(); public void PlanSayHello() { _foo.SaveForUseInFuture(Strategy); } public void SayHello() { _foo.CallAction(); } void Strategy() { Console.WriteLine("Hello!"); } }

यह कोड किस समस्या को दर्शाता है? द्वितीयक वर्ग स्टोर Action प्रतिनिधि को _action फ़ील्ड में _action जिसे SaveForUseInFuture विधि में स्वीकार किया SaveForUseInFuture है। अगला, Primary कक्षा के अंदर PlanSayHello पद्धति, Secondary वर्ग के लिए Strategy विधि के लिए सूचक को पास करती है। यह उत्सुक है, लेकिन यदि इस उदाहरण में, आप कहीं स्थिर विधि या आवृत्ति विधि पास करते हैं, तो SaveForUseInFuture को परिवर्तित नहीं किया जाएगा, लेकिन Primary वर्ग का उदाहरण अंतर्निहित रूप से संदर्भित किया जाएगा या बिल्कुल संदर्भित नहीं होगा। बाह्य रूप से ऐसा लगता है कि आपने निर्देश दिया है कि किस विधि से कॉल करें। लेकिन वास्तव में, एक प्रतिनिधि न केवल एक विधि सूचक का उपयोग करके बनाया जाता है, बल्कि एक वर्ग के उदाहरण के लिए सूचक का उपयोग भी किया जाता है। एक कॉलिंग पार्टी को यह समझना चाहिए कि किस वर्ग को किस तरीके से Strategy मेथड को कॉल करना है! यह Secondary वर्ग का उदाहरण अंतर्निहित रूप से स्वीकार किया गया है और Primary वर्ग के उदाहरण के लिए पॉइंटर को पकड़ता है, हालांकि यह स्पष्ट रूप से इंगित नहीं किया गया है। हमारे लिए इसका मतलब केवल यह है कि अगर हम _foo पॉइंटर को कहीं और पास _foo और Primary का संदर्भ खो देते हैं, तो जीसी Primary ऑब्जेक्ट को इकट्ठा नहीं करेगा , क्योंकि Secondary इसे धारण करेगा। हम ऐसी स्थितियों से कैसे बच सकते हैं? हमें एक संदर्भ जारी करने के लिए एक निर्धारित दृष्टिकोण की आवश्यकता है। एक ऐसा तंत्र जो इस उद्देश्य को पूरी तरह से फिट करता है, वह है IDisposable

 // This is a simplified implementation class Secondary : IDisposable { Action _action; public event Action<Secondary> OnDisposed; public void SaveForUseInFuture(Action action) { _action = action; } public void CallAction() { _action?.Invoke(); } void Dispose() { _action = null; OnDisposed?.Invoke(this); } }

अब उदाहरण स्वीकार्य लगता है। यदि किसी वर्ग का उदाहरण किसी तीसरे पक्ष को दिया जाता है और इस प्रक्रिया के दौरान _action प्रतिनिधि का संदर्भ खो जाएगा, तो हम इसे शून्य पर सेट करेंगे और तीसरे पक्ष को उदाहरण के विनाश के बारे में सूचित किया जाएगा और इसके संदर्भ को हटा दें ।
प्रतिनिधि पर चलने वाले कोड का दूसरा खतरा event के कामकाज के सिद्धांत हैं। आइए देखें कि उनमें क्या परिणाम हैं:

  // a private field of a handler private Action<Secondary> _event; // add/remove methods are marked as [MethodImpl(MethodImplOptions.Synchronized)] // that is similar to lock(this) public event Action<Secondary> OnDisposed { add { lock(this) { _event += value; } } remove { lock(this) { _event -= value; } } }

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

दूसरा तरीका स्पष्ट रूप से add / remove तरीकों को लागू करना है, इसलिए हम प्रतिनिधियों के संग्रह को नियंत्रित कर सकते हैं।

एक और अंतर्निहित स्थिति यहां दिखाई दे सकती है। ऐसा प्रतीत हो सकता है कि यदि आप किसी ईवेंट स्रोत को अशक्त करते हैं, तो ईवेंट की निम्न सदस्यता NullReferenceException कारण होगी। मुझे लगता है कि यह अधिक तार्किक होगा।

हालांकि, यह सच नहीं है। यदि ईवेंट कोड साफ़ होने के बाद बाहरी कोड घटनाओं की सदस्यता लेता है, तो एफसीएल एक्शन क्लास का एक नया उदाहरण बनाएगा और इसे OnDisposed में संग्रहीत OnDisposed । सी # में यह गवाह एक प्रोग्रामर को गुमराह कर सकता है: अशक्त क्षेत्रों से निपटने के लिए शांति के बजाय सतर्कता का उत्पादन करना चाहिए। यहां हम एक दृष्टिकोण भी प्रदर्शित करते हैं जब प्रोग्रामर की लापरवाही मेमोरी लीक को जन्म दे सकती है।

लम्बोदर बंद

इस तरह के सिंटैक्टिक शुगर का उपयोग लैम्ब्डा के रूप में करना विशेष रूप से खतरनाक है।

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

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

  button.Clicked += () => service.SendMessageAsync(MessageType.Deploy);

सहमत हूं, यह रेखा बहुत सुरक्षित दिखती है। लेकिन यह एक बड़ी समस्या को छुपाता है: अब button चर स्पष्ट रूप से संदर्भ service और इसे धारण करता है। यहां तक कि अगर हम यह तय करते हैं कि हमें अब service आवश्यकता नहीं है, तो button अभी भी संदर्भ को धारण करेगा जबकि यह चर जीवित है। इस समस्या को हल करने के तरीकों में से एक यह है कि किसी भी Action ( System.Reactive.Disposables ) से IDisposable बनाने के लिए एक पैटर्न का उपयोग किया जाए:

 // Here we create a delegate from a lambda Action action = () => service.SendMessageAsync(MessageType.Deploy); // Here we subscribe button.Clicked += action; // We unsubscribe var subscription = Disposable.Create(() => button.Clicked -= action); // where it is necessary subscription.Dispose();

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

थ्रेडबोर्ट सुरक्षा

जब आप किसी तृतीय-पक्ष डेवलपर के लिए लायब्रेरी बनाते हैं, तो आप तृतीय-पक्ष अनुप्रयोग में उसके व्यवहार की भविष्यवाणी नहीं कर सकते। कभी-कभी आप केवल अनुमान लगा सकते हैं कि एक प्रोग्रामर ने आपके पुस्तकालय के लिए क्या किया था जो एक विशेष परिणाम का कारण बना। एक उदाहरण एक बहुआयामी वातावरण में काम कर रहा है जब संसाधनों की निरंतरता एक महत्वपूर्ण मुद्दा बन सकती है। ध्यान दें कि जब हम Dispose() विधि लिखते हैं, तो हम अपवादों की अनुपस्थिति की गारंटी दे सकते हैं। हालाँकि, हम यह सुनिश्चित नहीं कर सकते हैं कि Dispose() विधि को चलाने के दौरान कोई भी ThreadAbortException नहीं होगा जो हमारे निष्पादन के थ्रेड को अक्षम करता है। यहां हमें यह याद रखना चाहिए कि जब ThreadAbortException होता है, तो सभी कैच / अंत में ब्लॉक को वैसे भी निष्पादित किया जाता है (कैच के अंत में / थ्रेडअबॉर्ट आगे ब्लॉक होता है)। इसलिए, थ्रेड का उपयोग करके एक निश्चित कोड के निष्पादन को सुनिश्चित करने के लिए। आपको try { ... } finally { ... } में एक महत्वपूर्ण अनुभाग को लपेटने की आवश्यकता है try { ... } finally { ... } , नीचे दिए गए उदाहरण देखें:

 void Dispose() { if(_disposed) return; _someInstance.Unsubscribe(this); _disposed = true; }

Thread.Abort का उपयोग करके कोई भी इसे निरस्त कर Thread.Abort । यह आंशिक रूप से एक वस्तु को नष्ट कर देता है, हालांकि आप अभी भी भविष्य में इसके साथ काम कर सकते हैं। उसी समय, निम्नलिखित कोड:

 void Dispose() { if(_disposed) return; // ThreadAbortException protection try {} finally { _someInstance.Unsubscribe(this); _disposed = true; } }

इस तरह के एक गर्भपात से सुरक्षित है और सुचारू रूप से और निश्चित रूप से चलेगा, भले ही Thread.Abort Unsubscribe विधि को कॉल करने और अपने निर्देशों को निष्पादित करने के बीच दिखाई दे।

परिणाम

लाभ

खैर, हमने इस सरल पैटर्न के बारे में बहुत कुछ सीखा। आइए जानें इसके फायदे:

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

नुकसान

मेरी राय में, इस पैटर्न के फायदे की तुलना में अधिक नुकसान हैं।

एक ओर, इस पैटर्न को लागू करने वाले किसी भी प्रकार से अन्य भागों को निर्देश दिया जाता है कि यदि वे इसका उपयोग करते हैं तो वे एक प्रकार का सार्वजनिक प्रस्ताव लेते हैं। यह इतना निहित है कि जनता के मामले में एक प्रकार का उपयोगकर्ता हमेशा यह नहीं जानता है कि प्रकार में यह इंटरफ़ेस है। इस प्रकार आपको आईडीई संकेतों का पालन करना होगा (एक अवधि टाइप करें, डिस्क ... और जांचें कि क्या किसी वर्ग के फ़िल्टर किए गए सदस्य सूची में एक विधि है)। यदि आप एक डिस्पोज़ पैटर्न देखते हैं, तो आपको इसे अपने कोड में लागू करना चाहिए। कभी-कभी यह सीधे नहीं होता है और इस मामले में आपको एक प्रकार के सिस्टम के माध्यम से एक पैटर्न को लागू करना चाहिए जो कार्यक्षमता जोड़ता है। एक अच्छा उदाहरण यह है कि IEnumerator<T> IDisposable ।
आमतौर पर जब आप एक इंटरफ़ेस डिज़ाइन करते हैं, तो एक प्रकार के इंटरफेस की प्रणाली में आईडीसिसोप्लिट सम्मिलित करने की आवश्यकता होती है, जब इंटरफेस में से एक को आईडीआईसोपायरी विरासत में प्राप्त करना होता है। मेरी राय में, यह हमारे द्वारा डिज़ाइन किए गए इंटरफेस को नुकसान पहुंचाता है। मेरा मतलब है कि जब आप एक इंटरफ़ेस डिज़ाइन करते हैं तो आप पहले एक इंटरैक्शन प्रोटोकॉल बनाते हैं। यह उन क्रियाओं का एक समूह है जो आप इंटरफ़ेस के पीछे छिपी किसी चीज़ के साथ कर सकते हैं। Dispose() एक वर्ग की आवृत्ति को नष्ट करने के लिए एक विधि है। यह एक इंटरैक्शन प्रोटोकॉल के सार का विरोध करता है । वास्तव में, ये इंटरफ़ेस में घुसपैठ करने वाले कार्यान्वयन का विवरण हैं।
निर्धारित होने के बावजूद, निपटान () का अर्थ किसी वस्तु का प्रत्यक्ष विनाश नहीं है। वस्तु अभी भी अपने विनाश के बाद मौजूद होगी लेकिन किसी अन्य राज्य में। इसे सही करने के लिए CheckDisposed () प्रत्येक सार्वजनिक विधि की पहली कमांड होनी चाहिए। यह एक अस्थायी समाधान की तरह दिखता है जो किसी ने हमें यह कहते हुए दिया: "आगे बढ़ो और गुणा करो";
एक प्रकार प्राप्त करने का एक छोटा सा मौका भी है जो स्पष्ट कार्यान्वयन के माध्यम से IDisposable को लागू करता है। या आप एक प्रकार प्राप्त कर सकते हैं जो लागू करने के लिए पहचान के अवसर के बिना आईडी लागू होता है, जो इसे नष्ट करना चाहिए: आप या वह पार्टी जिसने आपको इसे दिया था। इससे डिस्पोज़ () की कई कॉलों का एक एंटीपार्टर्न हुआ जो नष्ट हुई वस्तु को नष्ट करने की अनुमति देता है;
पूर्ण कार्यान्वयन मुश्किल है, और यह प्रबंधित और अप्रबंधित संसाधनों के लिए अलग है। यहां जीसी के माध्यम से डेवलपर्स के काम को सुविधाजनक बनाने का प्रयास अजीब लग रहा है। आप virtual void Dispose() डिस्पोज़ virtual void Dispose() विधि को ओवरराइड कर सकते हैं और कुछ डिस्पोजेबलऑब्जेक्ट प्रकार प्रस्तुत कर सकते हैं जो पूरे पैटर्न को लागू करता है, लेकिन यह पैटर्न से जुड़ी अन्य समस्याओं को हल नहीं करता है;
एक नियम के रूप में डिस्पोज़ () पद्धति को फ़ाइल के अंत में लागू किया जाता है जबकि '.ctor' को शुरुआत में घोषित किया जाता है। यदि आप एक वर्ग को संशोधित करते हैं या नए संसाधनों को पेश करते हैं, तो उनके लिए निपटान जोड़ना आसान है।
अंत में, बहुस्तरीय वातावरण में विनाश के क्रम को निर्धारित करना मुश्किल है जब आप ऑब्जेक्ट ग्राफ़ के लिए एक पैटर्न का उपयोग करते हैं जहां ऑब्जेक्ट पूरी तरह से या आंशिक रूप से उस पैटर्न को लागू करते हैं। मेरा मतलब उन स्थितियों से है जब डिस्पोज़ () एक ग्राफ के विभिन्न सिरों पर शुरू हो सकती है। यहां अन्य पैटर्न का उपयोग करना बेहतर है, उदाहरण के लिए लाइफटाइम पैटर्न।
प्लेटफ़ॉर्म डेवेलपर्स की इच्छा मेमोरी कंट्रोल को वास्तविकताओं के साथ संयुक्त करने की है: एप्लिकेशन बहुत बार अनवांटेड कोड के साथ इंटरैक्ट करते हैं + आपको ऑब्जेक्ट्स के संदर्भों की रिलीज़ को नियंत्रित करने की आवश्यकता होती है ताकि गारबेज कलेक्टर उन्हें इकट्ठा कर सके। यह इस तरह के सवालों को समझने में बहुत भ्रम जोड़ता है: "हमें एक पैटर्न को सही तरीके से कैसे लागू करना चाहिए"? "क्या कोई विश्वसनीय पैटर्न है"? शायद कॉलिंग delete obj; delete[] arr; delete obj; delete[] arr; सरल है

डोमेन अनलोडिंग और एक आवेदन से बाहर निकलें

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

एप्लिकेशन डोमेन को उतारने के दौरान आप दोनों असेंबली को एप्लिकेशन डोमेन में लोड कर देते हैं और वे सभी ऑब्जेक्ट जो डोमेन के हिस्से के रूप में लोड किए जाने के लिए बनाए गए थे। वास्तव में, इसका मतलब इन वस्तुओं की सफाई (जीसी द्वारा संग्रह) है और उनके लिए फाइनल कॉलिंग है। यदि कोई फ़ाइनलीज़र का तर्क सही क्रम में नष्ट होने वाली अन्य वस्तुओं के अंतिम रूप देने के लिए प्रतीक्षा करता है, तो आप Environment.HasShutdownStarted ध्यान दे सकते हैं। शटडाउनडस्टर्ड ने संपत्ति का संकेत दिया कि कोई एप्लिकेशन मेमोरी से और AppDomain.CurrentDomain.IsFinalizingForUnload() विधि से संकेत करता है कि यह दर्शाता है। डोमेन अनलोड किया गया है जो अंतिम रूप देने का कारण है। यदि ये घटनाएँ घटती हैं तो संसाधनों को अंतिम रूप देने का क्रम आम तौर पर महत्वहीन हो जाता है। हम या तो डोमेन या एप्लिकेशन को लोड करने में देरी नहीं कर सकते क्योंकि हमें हर चीज को जल्दी से जल्दी करना चाहिए।

यह इस तरह से इस कार्य को एक क्लास लोडर के हिस्से के रूप में हल किया जाता है

 // Assemblies and LoaderAllocators will be cleaned up during AppDomain shutdown in // an unmanaged code // So it is ok to skip reregistration and cleanup for finalization during appdomain shutdown. // We also avoid early finalization of LoaderAllocatorScout due to AD unload when the object was inside DelayedFinalizationList. if (!Environment.HasShutdownStarted && !AppDomain.CurrentDomain.IsFinalizingForUnload()) { // Destroy returns false if the managed LoaderAllocator is still alive. if (!Destroy(m_nativeLoaderAllocator)) { // Somebody might have been holding a reference on us via weak handle. // We will keep trying. It will be hopefully released eventually. GC.ReRegisterForFinalize(this); } }

विशिष्ट कार्यान्वयन दोष

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

FileEntry क्लास cmsinterop.cs

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

 internal class FileEntry : IDisposable { // Other fields // ... [MarshalAs(UnmanagedType.SysInt)] public IntPtr HashValue; // ... ~FileEntry() { Dispose(false); } // The implementation is hidden and complicates calling the *right* version of a method. void IDisposable.Dispose() { this.Dispose(true); } // Choosing a public method is a serious mistake that allows for incorrect destruction of // an instance of a class. Moreover, you CANNOT call this method from the outside public void Dispose(bool fDisposing) { if (HashValue != IntPtr.Zero) { Marshal.FreeCoTaskMem(HashValue); HashValue = IntPtr.Zero; } if (fDisposing) { if( MuiMapping != null) { MuiMapping.Dispose(true); MuiMapping = null; } System.GC.SuppressFinalize(this); } } }

SemaphoreSlim क्लास सिस्टम / थ्रेडिंग / SemaphoreSlim.cs

यह त्रुटि। आईडी फ्रेमवर्क के बारे में .NET फ्रेमवर्क की त्रुटियों में सबसे ऊपर है: उन कक्षाओं के लिए दबाएं जहां कोई फाइनल नहीं है। यह बहुत आम है।

 public void Dispose() { Dispose(true); // As the class doesn't have a finalizer, there is no need in GC.SuppressFinalize GC.SuppressFinalize(this); } // The implementation of this pattern assumes the finalizer exists. But it doesn't. // It was possible to do with just public virtual void Dispose() protected virtual void Dispose(bool disposing) { if (disposing) { if (m_waitHandle != null) { m_waitHandle.Close(); m_waitHandle = null; } m_lockObj = null; m_asyncHead = null; m_asyncTail = null; } }

कॉलिंग बंद + कुछ मूल निवासी प्रोजेक्ट कोड को डिस्पोज़ करें

कभी-कभी लोग क्लोज और डिस्पोजल दोनों कहते हैं। यह गलत है, हालांकि यह एक त्रुटि उत्पन्न नहीं करेगा क्योंकि दूसरा डिस्पोज एक अपवाद उत्पन्न नहीं करता है।

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

 public void Dispose() { if (MainForm != null) { MainForm.Close(); MainForm.Dispose(); } MainForm = null; }

सामान्य परिणाम

ID प्रयोज्य मंच का एक मानक है और इसके कार्यान्वयन की गुणवत्ता पूरे अनुप्रयोग की गुणवत्ता को प्रभावित करती है। इसके अलावा, कुछ स्थिति में यह आपके एप्लिकेशन की सुरक्षा को प्रभावित करता है जिसे मानव रहित संसाधनों के माध्यम से हमला किया जा सकता है।
आईडीसोपायरी का कार्यान्वयन अधिकतम रूप से उत्पादक होना चाहिए। यह अंतिम रूप देने के अनुभाग के बारे में विशेष रूप से सच है, जो शेष कोड के साथ समानांतर में काम करता है, कचरा कलेक्टर लोड कर रहा है।
आईडीसोपायरी को लागू करते समय आपको किसी वर्ग के सार्वजनिक तरीकों के साथ डिस्पोज () का उपयोग नहीं करना चाहिए। विनाश उपयोग के साथ नहीं जा सकता। एक प्रकार का डिजाइन करते समय इस पर विचार किया जाना चाहिए जो आईडीसॉर्पोरेट ऑब्जेक्ट का उपयोग करेगा।
हालांकि, एक साथ दो थ्रेड्स से 'डिस्पोज़ ()' कहने के खिलाफ सुरक्षा होनी चाहिए। यह उस कथन के परिणाम के रूप में है जो डिस्पोज़ () त्रुटियों का उत्पादन नहीं करना चाहिए।
जिन प्रकारों में अप्रबंधित संसाधन होते हैं उन्हें अन्य प्रकारों से अलग किया जाना चाहिए। मेरा मतलब है कि यदि आप एक अप्रबंधित संसाधन को लपेटते हैं, तो आपको इसके लिए एक अलग प्रकार आवंटित करना चाहिए। इस प्रकार में अंतिम रूप होना चाहिए और इसे SafeHandle / CriticalHandle / CriticalFinalizerObject से विरासत में मिला होना चाहिए। जिम्मेदारी के इस पृथक्करण से प्रकार प्रणाली के बेहतर समर्थन का परिणाम होगा और निपटान () के माध्यम से प्रकारों को नष्ट करने के लिए कार्यान्वयन को सरल करेगा: इस कार्यान्वयन के साथ प्रकारों को अंतिम रूप देने के लिए आवश्यक नहीं होगा।
सामान्य तौर पर, यह पैटर्न उपयोग के साथ-साथ कोड रखरखाव में भी सहज नहीं है। जब हम Lifetime पैटर्न के माध्यम से वस्तुओं की स्थिति को नष्ट करते हैं, तो शायद हमें नियंत्रण दृष्टिकोण के व्युत्क्रम का उपयोग करना चाहिए। हालाँकि, हम इसके बारे में अगले भाग में बात करेंगे।