🧣 👨🏾‍🏫 👨🏽 डेल्फी में इंटरफेस के उपयोग की विशेषताएं 🧚🏾 🧔🏿 👂🏽

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

सच कहूँ तो, मैं आमतौर पर COM तंत्र के माध्यम से बाहरी दुनिया के साथ बातचीत करने के लिए इंटरफेस का उपयोग नहीं करता हूं। और, मुझे शक है कि मैं ही नहीं। डेल्फी में, इंटरफेस ने एक और उपयोगी उपयोग पाया है।

वास्तव में, इंटरफेस दो मामलों में उपयोगी हैं:

जब कई विरासत का उपयोग करने के लिए;
जब एआरसी (स्वचालित संदर्भ गिनती) स्मृति प्रबंधन को बहुत आसान बनाती है।

डेल्फी में, ऐतिहासिक रूप से नहीं है और इस रूप में कई विरासत नहीं मिली है, जैसा कि कुछ अन्य प्रोग्रामिंग भाषाओं में प्रथागत है (उदाहरण के लिए, C ++)। और वह अच्छा है।

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

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

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

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

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

एक उदाहरण एक-बटन का एक रूप है। एक शुद्ध परीक्षण उदाहरण। इसे घर पर न दोहराएं।

unit Unit1; interface uses Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics, Vcl.Controls, Vcl.Forms, Vcl.Dialogs, Vcl.StdCtrls; type IMyIntf = interface procedure TestMessage; end; TMyClass = class(TInterfacedObject, IMyIntf) public procedure TestMessage; destructor Destroy; override; end; TForm1 = class(TForm) Button1: TButton; Memo1: TMemo; procedure Button1Click(Sender: TObject); public procedure Kill(Intf: IMyIntf); end; var Form1: TForm1; implementation {$R *.dfm} procedure TForm1.Button1Click(Sender: TObject); var MyClass: TMyClass; begin Memo1.Clear; try MyClass := TMyClass.Create; try Kill(MyClass); finally MyClass.Free; end; except on E: Exception do Memo1.Lines.Add(E.Message); end; end; procedure TForm1.Kill(Intf: IMyIntf); begin Intf.TestMessage; end; { TMyClass } destructor TMyClass.Destroy; begin Form1.Memo1.Lines.Add('TMyClass.Destroy'); inherited; end; procedure TMyClass.TestMessage; begin Form1.Memo1.Lines.Add('TMyClass.TestMessage'); end; end.

हम शुरू करते हैं, बटन दबाएं और निम्न पाठ मेमो 1 में दिखाई देता है:

  TMyClass.TestMessage
 TMyClass.Destroy
 TMyClass.Destroy
 अमान्य पॉइंटर ऑपरेशन

नष्ट दो बार और कहा जाता है, परिणामस्वरूप, "अमान्य पॉइंटर ऑपरेशन"। क्यों?

एक बार - यह समझ में आता है। Button1Click हैंडलर में, MyClass.Free कहा जाता है। दूसरी बार कहाँ है? समस्या का सार किल प्रक्रिया में निहित है। हम इसके कार्यान्वयन के पाठ्यक्रम का विश्लेषण करेंगे।

 //  Intf.RefCount = 0,     TInterfacedObject //  Intf      Kill //  Intf._AddRef,  RefCount = 1 procedure TForm1.Kill(Intf: IMyIntf); begin Intf.TestMessage; //     ,  Intf._Release // ,   RefCount   ,  : TMyClass.Destroy //     ,      ,  . //      . end;

यही है, समस्या यह है कि TInterfacedObject और इसके वंशज शून्य की एक संदर्भ संख्या है। ऑब्जेक्ट के लिए, यह सामान्य है, लेकिन इंटरफ़ेस के लिए यह आसन्न और आसन्न मौत का संकेत है।

किसे दोष देना है और क्या करना है?

मुझे लगता है कि किसी को दोष नहीं देना है। ऐसा करने की कोई जरूरत नहीं है। यह संभावना नहीं है कि एक कचरा कलेक्टर के बिना एक भाषा में नियंत्रित जीवनकाल के साथ इंटरफेस को अधिक आसानी से लागू करना संभव होगा। प्रोग्रामर को स्पष्ट रूप से _AddRef और _Release को कॉल करने के लिए मजबूर करने के लिए। मुझे संदेह है कि यह अधिक सुविधाजनक होगा।

संदर्भ काउंट्स के साथ और इसके बिना - दो प्रकार के इंटरफेस शुरू करना भी संभव था, लेकिन इससे और भी भ्रम पैदा हो जाता।

यह समझा जाना चाहिए कि संदर्भ काउंटर इंटरफेस से संबंधित नहीं है, बल्कि ऑब्जेक्ट के लिए है। इंटरफेस केवल इस काउंटर को नियंत्रित करते हैं। यदि डेल्फी में दो प्रकार के इंटरफेस हैं, तो ऐसी स्थिति में किसी वस्तु के साथ कैसे व्यवहार करना है जो विभिन्न प्रकार के दो इंटरफेस को लागू करता है? संभावित नुकसान की तलाश के लिए बहुत जगह है।

आप ऑब्जेक्ट संदर्भ काउंटर से _AddRef और _Release विधियों को ओवरराइड करके इस तरह से छुटकारा पा सकते हैं कि संदर्भ काउंटर को रीसेट करने से ऑब्जेक्ट को मुक्त नहीं किया जा सकता है। उदाहरण के लिए, उदाहरण से कक्षा को इस तरह से बदलना (ताकि कक्षा इंटरफ़ेस को विरासत में दे सके, उसे तीन विधियों को लागू करना होगा: _AddRef, _Release और QueryInterface):

  TMyClass = class(TObject, IMyIntf) protected function _AddRef: Integer; stdcall; function _Release: Integer; stdcall; function QueryInterface(const IID: TGUID; out Obj): HResult; stdcall; public procedure TestMessage; destructor Destroy; override; end; function TMyClass.QueryInterface(const IID: TGUID; out Obj): HResult; begin if GetInterface(IID, Obj) then Result := 0 else Result := E_NOINTERFACE; end; function TMyClass._AddRef: Integer; begin Result := -1; end; function TMyClass._Release: Integer; begin Result := -1; end;

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

हालांकि, वीसीएल में, संदर्भ काउंटर पुनर्वितरण का उपयोग किया जाता है। TComponent वंशज के लिए, लिंक काउंटर बहुत जटिल रूप से काम करता है।

 function TComponent._AddRef: Integer; begin if FVCLComObject = nil then Result := -1 // -1 indicates no reference counting is taking place else Result := IVCLComObject(FVCLComObject)._AddRef; end; function TComponent._Release: Integer; begin if FVCLComObject = nil then Result := -1 // -1 indicates no reference counting is taking place else Result := IVCLComObject(FVCLComObject)._Release; end;

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

 procedure TForm1.Kill(const Intf: IMyIntf); begin Intf.TestMessage; end;

अब नतीजा कुछ इस तरह होगा, यानी पूरी उम्मीद है:

  TMyClass.TestMessage
 TMyClass.Destroy

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

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

डेल्फी में इंटरफेस के उपयोग की विशेषताएं

किसे दोष देना है और क्या करना है?

More articles: