🏙️ 👣 🔧 PostSharp। पहलू उन्मुख प्रोग्रामिंग बनाम निर्भरता इंजेक्शन 👡 💐 🕹️

भय, असुरक्षा, और एस्पेक्ट ओरिएंटेड प्रोग्रामिंग के बारे में संदेह के बारे में एंड्रेस हेल्सबर्ग के साथ मेरी बातचीत में , मैंने आम भ्रम और गलतफहमी का उल्लेख किया कि AOP और DI अवधारणाओं का मुकाबला कर रहे हैं। इस लेख में मैं आपको इन दोनों दृष्टिकोणों के सभी अंतरों और समानताओं के बारे में समझाने की कोशिश करूंगा। हाल ही में मैंने डिनो एस्पोसिटो के लेख को पढ़ने में बहुत अच्छा समय दिया था: "एमएसडीएन मैगज़ीन के दिसंबर अंक में" पहलू-उन्मुख प्रोग्रामिंग, इंटरसेप्शन और एकता 2.0 "। यह एक महान लेख है और मैं इसे पूरी तरह से पढ़ने के लिए .NET विकास में शामिल किसी भी डेवलपर को दृढ़ता से सलाह देता हूं। कई DI चौखटे, और कुछ बुनियादी ढांचे (WCF, ASP.NET MVC) की तरह, एकता AOP जैसी सुविधा प्रदान करती है: इंटरसेप्टर।

निर्भरता इंजेक्शन क्या है?

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

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

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

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

पहलू उन्मुख प्रोग्रामिंग

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

AOP और DI के बीच समानताएं और अंतर

DI और AOP के बीच कुछ समानताएँ हैं:

दोनों शिथिल युग्मित वास्तुकला को प्राप्त करते हैं
दोनों कार्यक्षमता का बेहतर पृथक्करण प्राप्त करते हैं।
दोनों मुख्य कोड के साथ कुछ समस्याओं को दूर करते हैं।

हालांकि, DI और AOP उन स्थितियों में काफी भिन्न हैं जहां वे उपयोगी साबित होते हैं:

जब आप घटकों पर निर्भर होते हैं, तो DI अच्छा है, और यह लागू नहीं होता है कि वे कैसे लागू होते हैं;
AOP अच्छा है जब आपको बहुत सारे कोड तत्वों के लिए किसी प्रकार का व्यवहार लागू करने की आवश्यकता होती है। इसके अलावा, लक्ष्य कोड आवश्यक रूप से इस व्यवहार पर निर्भर नहीं करता है।

गतिशील प्रॉक्सी

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

प्रॉक्सी आधारित AOP: क्या अच्छा है?

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

प्रॉक्सी आधारित AOP: क्या गलत है?

प्रॉक्सी-आधारित AOP, जिसे DI चौखटे का उपयोग करके लागू किया गया है, की एक बड़ी संख्या है:
वे हैं

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

प्रॉक्सी आधारित AOP: क्या बदसूरत है?

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

निष्कर्ष

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

संदर्भ:

PostSharp। पहलू उन्मुख प्रोग्रामिंग बनाम निर्भरता इंजेक्शन