डिस्पोजल पैटर्न

"आपको कुछ मुहावरों का पालन सिर्फ इसलिए नहीं करना चाहिए क्योंकि हर कोई इसे करता है या कहीं न कहीं लिखा जाता है"

किसी और के कोड को पढ़ते और रिफैक्ट करते समय लेख के लेखक के विचार

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

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

मुहावरा RAII

सी ++ में, जिसमें स्मार्ट पॉइंटर्स के अलावा स्वचालित मेमोरी प्रबंधन के लिए कोई अंतर्निहित उपकरण नहीं हैं, संसाधनों (*) के समय पर रिलीज के लिए एक पैटर्न (या मुहावरे) को सक्रिय रूप से उपयोग किया गया है। इस मुहावरे को "संसाधन अधिग्रहण इज इनिशियलाइज़ेशन" (आरएआई) कहा जाता है और इस प्रकार है। संसाधन को कंस्ट्रक्टर में कैप्चर किया जाता है और डिस्ट्रक्टर में मुक्त किया जाता है, और चूंकि डिस्ट्रक्टर्स को स्वचालित रूप से कहा जाता है, संसाधनों को प्रबंधित करने के लिए अतिरिक्त प्रयासों की अब आवश्यकता नहीं है।

यह आश्चर्य की बात नहीं है कि नियतात्मक संसाधन प्रबंधन का एक ही विचार भी अन्य "स्मार्ट" और "प्रबंधित" वातावरण में स्थानांतरित किया गया, जैसे कि .NET या जावा (**) में एक आईडीसोप्लॉरी इंटरफ़ेस (सी # में) और एक निपटान विधि (जावा में) के रूप में। । लेकिन, चूंकि ये वातावरण पुराने C ++ की तुलना में अधिक स्मार्ट हैं, और मेमोरी प्रबंधन से जुड़ी मुख्य समस्याएं हैं, उन्हें हल किया जाता है, यह मुहावरा बहुत अच्छा नहीं हुआ। नहीं, मुझे सही ढंग से समझें, यह काफी सफलतापूर्वक चला गया, लेकिन इसके लिए आपको उपयोग ब्लॉक (सी # भाषा के लिए) का उपयोग करने की आवश्यकता है या प्रयास करें - संसाधनों के बयान (जावा 7 में) के साथ, यदि आप उन्हें उपयोग करने के लिए "भूल जाते हैं", तो अपने निर्धारक से संसाधनों की रिहाई ट्रेस नहीं रहेगी।

// using
using ( FileStream file = File .OpenRead( "foo.txt" ))
{
//
if (someCondition) return ;
// using
}
// , - using?
FileStream file2 = File .OpenRead( "foo.txt" );

* This source code was highlighted with Source Code Highlighter .

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

यह सब इस तथ्य को जन्म देता है कि अपेक्षाकृत सरल मुहावरे RAII ने .NET प्लेटफ़ॉर्म पर "डिस्पोज़ पैटर्न" नामक एक पैटर्न में फैलाया। हालाँकि, इसके विचार पर जाने से पहले, दो प्रकार के संसाधनों को देखते हैं जो .NET प्लेटफॉर्म पर मौजूद हैं: प्रबंधित और अप्रबंधित संसाधन।

प्रबंधित और अप्रबंधित संसाधन

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

class NativeResourceWrapper : IDisposable
{
// IntPtr –
private IntPtr nativeResourceHandle;
public NativeResourceWrapper()
{
// «»
nativeResourceHandle = AcquireNativeResource();
}
public void Dispose()
{
// , , -
//
ReleaseNativeResource(nativeResourceHandle);
}
// ,
~NativeResourceWrapper() {...}
}

* This source code was highlighted with Source Code Highlighter .

इस प्रकार, कोई भी वस्तु दो प्रकार के संसाधनों का मालिक हो सकती है: इसमें प्रत्यक्ष रूप से एक अप्रबंधित संसाधन (उदाहरण के लिए , IntPtr ) हो सकता है या इसमें एक प्रबंधित संसाधन (उदाहरण के लिए, NativeResourceWrapper ) का लिंक हो सकता है, दोनों ही मामलों में, इन संसाधनों में से एक में एक वस्तु होती है, यह स्वयं एक प्रबंधित संसाधन बन जाता है। यह बहुत मौलिक नहीं लग सकता है, लेकिन दो प्रकार के संसाधनों के बीच अंतर को समझना बहुत महत्वपूर्ण है, क्योंकि आपको उनके साथ विभिन्न तरीकों से काम करना होगा।

डिस्पोजल पैटर्न

तो, हम जानते हैं कि एक वस्तु दो प्रकार के संसाधनों का मालिक हो सकती है: प्रबंधित और अप्रबंधित ; इस तथ्य के साथ कि हमारे पास संसाधनों को मुक्त करने के दो तरीके हैं: नियतांक विधि का उपयोग करके नियतात्मक और अंतिम (***) का उपयोग करके गैर-नियतात्मक । अब देखते हैं कि इस अच्छे के साथ कैसे रहना है और सबसे महत्वपूर्ण बात यह है कि इस अच्छे को कैसे मुक्त किया जाए।

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

1. प्रबंधित या अप्रबंधित संसाधनों से युक्त एक वर्ग आईडीसोफिरेबल इंटरफ़ेस लागू करता है

class Boo : IDisposable { ... }

* This source code was highlighted with Source Code Highlighter .

2. कक्षा में डिस्पोज़ ( बूल डिस्पोज़िंग ) विधि शामिल है, जो संसाधनों को मुक्त करने का सारा काम करती है; डिस्पोज़िंग पैरामीटर इंगित करता है कि क्या इस विधि को डिस्पोज़ विधि से या अंतिम रूप से कहा जाता है। इस पद्धति को गैर-सीलबंद कक्षाओं के लिए वर्चुअल और सीलबंद कक्षाओं के लिए निजी होना चाहिए

// -sealed
protected virtual void Dispose( bool disposing) {}

// sealed
private void Dispose( bool disposing) {}

* This source code was highlighted with Source Code Highlighter .

3. डिस्पोज़ विधि को हमेशा निम्नानुसार लागू किया जाता है: पहला, डिस्पोज़ ( सच्चा ) तरीका कहा जाता है, और फिर जीसी विधि कॉल का पालन कर सकते हैं । SuppressFinalize () , जो अंतिम रूप से बुलाया जाने से रोकता है।

public void Dispose()
{
Dispose( true /*called by user directly*/ );
GC.SuppressFinalize( this );
}

* This source code was highlighted with Source Code Highlighter .

जीसी विधि । SuppressFinalize () , सबसे पहले, Dispose ( true ) को कॉल करने के बाद कॉल किया जाना चाहिए, और इसके पहले नहीं, क्योंकि यदि अपवाद के साथ Dispose ( true ) मेथड "फॉल्स" हो जाता है, तो फाइनल रद्द नहीं किया जाएगा। दूसरी बात, जीसी । SuppressFinalize () को उन वर्गों के लिए भी बुलाया जाना चाहिए, जिनमें अंतिम रूप नहीं है, क्योंकि अंतिम रूप से इसके वंशज पर प्रकट हो सकते हैं (अर्थात, हमें GC को कहना चाहिए । SuppressFinalize () सभी गैर-सील वर्गों में विधि)।

4. डिस्पोज़ ( बूल डिस्पोज़िंग ) विधि में दो भाग होते हैं: (1) यदि इस विधि को डिस्पोज़ विधि (अर्थात, डिस्पोज़िंग पैरामीटर सही है ) कहा जाता है , तो हम प्रबंधित और अप्रबंधित संसाधनों को जारी करते हैं और (2) यदि विधि को अंतिम रूप से कहा जाता है कचरा संग्रह ( डिस्पोज़िंग पैरामीटर गलत है ), तो हम केवल अप्रबंधित संसाधनों को मुक्त करते हैं।

void Dispose( bool disposing)
{
if (disposing)
{
//
}

//
}

* This source code was highlighted with Source Code Highlighter .

5. (वैकल्पिक) एक वर्ग में एक अंतिम रूप हो सकता है और कॉल डिस्पोज़ ( बूल डिस्पोज़िंग ) हो सकता है क्योंकि यह एक पैरामीटर के रूप में गलत है ।

~Boo()
{
Dispose( false /*not called by user directly*/ );
}

* This source code was highlighted with Source Code Highlighter .

यह मत भूलो कि अंतिम रूप से आंशिक रूप से निर्मित वस्तुओं के लिए भी बुलाया जा सकता है यदि इस वर्ग का निर्माण एक अपवाद फेंकता है। तो अप्रबंधित संसाधनों के लिए सफाई कोड को ध्यान में रखना चाहिए कि संसाधन अभी तक कैप्चर नहीं किए गए हैं (****)।

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

void Dispose( bool disposing)
{
if (disposed)
return ; //
//
disposed = true ;
}

public void SomeMethod()
{
if (disposed)
throw new ObjectDisposedException();
}

* This source code was highlighted with Source Code Highlighter .

7. (वैकल्पिक) एक वर्ग CriticalFinalizerObject से वारिस कर सकता है यदि पिछले छह अंक कम हैं और आप अधिक विदेशी चाहते हैं। इस वर्ग से विरासत आपको अतिरिक्त गारंटी देती है:

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

// , ?
class Foo : CriticalFinalizerObject {}

* This source code was highlighted with Source Code Highlighter .

डिस्पोज़ल पैटर्न पर एक व्यावहारिक नज़र

यदि आपको यह लगता है कि .NET में संसाधनों के साथ काम करना अनुचित रूप से जटिल है, तो मेरे पास इस बारे में दो खबरें हैं: एक अच्छा है, और दूसरा बहुत अच्छा नहीं है। समाचार "वास्तव में नहीं" यह है कि संसाधनों के साथ काम करना यहां वर्णित (*****) से भी अधिक कठिन है, अच्छी बात यह है कि ज्यादातर मामलों में यह सभी जटिलता व्यावहारिक रूप से हमें चिंतित नहीं करेगी।

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

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

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

डिस्पोजल पैटर्न का सरलीकृत संस्करण

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

class SomethingWithManagedResources : IDisposable
{
public void Dispose()
{
// Dispose(true) GC.SuppressFinalize()
DisposeManagedResources();
}

// ,
protected virtual void DisposeManagedResources() {}
}

* This source code was highlighted with Source Code Highlighter .

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

निष्कर्ष

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

यदि आप सीमित संख्या में उपयोगकर्ताओं के साथ बिजनेस लॉजिक क्लासेस या सिंपल लाइब्रेरीज़ डिज़ाइन कर रहे हैं, तो आप "कैनन" के साथ खुद को बेवकूफ नहीं बना सकते हैं, लेकिन इस पैटर्न के सरलीकृत संस्करण का उपयोग करें जो केवल प्रबंधित संसाधनों के साथ काम करता है।

------------------------------

(*) C ++ में, C # के विपरीत, मेमोरी भी एक संसाधन है। इसलिए, C ++ में RAII मुहावर का उपयोग गतिशील रूप से आवंटित स्मृति को मुक्त करने के लिए, और किसी भी अन्य संसाधनों को मुक्त करने के लिए किया जाता है, जैसे कि OS डिस्क्रिप्टर या सॉकेट।

(**) जावा 7 में, अंतत: C #: try-with-resource कथन का उपयोग करते हुए एक डिज़ाइन दिखाई दिया

(***) दुर्भाग्यवश, C # में, फाइनल सिंटैक्स फाइनलर्स (क्लास नाम के बाद दिया जाने वाला टिल्ड) के लिए चुना जाता है, जिसका उपयोग C ++ में डिस्ट्रक्टर्स के लिए किया जाता है। लेकिन विध्वंसक और फाइनल के शब्दार्थ बहुत भिन्न होते हैं, क्योंकि विध्वंसक का तात्पर्य संसाधनों के निर्धारक विमोचन से है, लेकिन अंतिम रूप से ऐसा नहीं होता है।

(***) हाँ, यह .NET और C ++ के व्यवहार में एक और अंतर है। उत्तरार्द्ध में, विध्वंसक को केवल पूरी तरह से निर्मित वस्तु के लिए कहा जाता है, जबकि विध्वंसक को उसके सभी पूर्ण निर्मित क्षेत्रों के लिए कहा जाता है।

(****) यहाँ, उदाहरण के लिए, मैंने इस बारे में बात नहीं की कि अपवाद होने या परस्पर सार्थक प्रकारों के साथ समस्याओं के बारे में "रिसोर्स लीक" कैसे प्राप्त किया जा सकता है, जो कि आइडीएसोपायरी इंटरफ़ेस को लागू करता है। मैंने पहले ही नोटों के बारे में लिखा था " अपवादों के लिए सुरक्षा की गारंटी " और "क्रमशः महत्वपूर्ण प्रकारों के खतरों पर, "।