पहलू-उन्मुख प्रोग्रामिंग: सीखें और इसे स्वयं करें!

लेख इस तथ्य से पैदा हुआ था कि मुझे कुछ कार्यों के लिए एक सुविधाजनक और सरल अवरोधन तंत्र की आवश्यकता थी, जिसे एओपी तकनीकों द्वारा आसानी से लागू किया जाता है। काफी कुछ इंटरसेप्टर (Casle.net, Spring.net, LinFu, इत्यादि) हैं जिन्हें रन-टाइम पर IL-code में डायनामिक चाइल्ड क्लासेस के कार्यान्वयन की आवश्यकता होती है और लगभग हमेशा इंटरसेप्टेड क्लासेस पर समान प्रतिबंधों की ओर जाता है: नहीं स्थिर, अनसेल्ड, विधियाँ और गुण आभासी होने चाहिए, आदि ...

अन्य अवरोधन तंत्रों को विधानसभा प्रक्रिया या लाइसेंस की खरीद में बदलाव की आवश्यकता होती है। मैं एक या दूसरे को बर्दाश्त नहीं कर सकता ...

परिचय

एओपी - पहलू ओरिएंटेड प्रोग्रामिंग। मुझे लगता है कि हर कोई ओपी से परिचित है, इसलिए आपको यह पता लगाने की जरूरत है कि पहलू क्या है । बाद में एक लेख में इस बारे में चिंता न करें।

मैं इस लेख को शुरुआती स्तर पर लिखने की कोशिश करूंगा। आगे पढ़ने के लिए एकमात्र आवश्यकता ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग की अवधारणा का ज्ञान है।

यह मुझे लगता है कि अवधारणा को समझने से आप कार्यान्वयन को बेहतर ढंग से समझ पाएंगे। लेकिन मैं यह भी समझता हूं कि लेख काफी बड़ा है, क्योंकि यदि आप ऊब गए हैं या थक गए हैं, तब भी कार्यान्वयन भाग को देखें। आप हमेशा सिद्धांत पर लौट सकते हैं।

अनुभवी डेवलपर्स, इसे पढ़ें!

यदि आप पहले से ही एओपी से परिचित हैं, तो मत छोड़ो!
मुझे यहीं छोड़ दो और अब मैं इस लेख में क्या है, इसका खुलासा करूंगा ...

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

बिना:
• अपने कोड और विधानसभाओं को फिर से बनाता है
• IL कोड में एम्बेड करना
• गतिशील रूप से कुछ बनाएं
• कक्षाओं को लक्षित करने के लिए परिवर्तन
• कुछ को लागू करने के लिए एक बुनकर की आवश्यकता (उदाहरण के लिए, मार्शलबीफ)

सामान्य तौर पर, हम स्वच्छ प्रबंधित कोड के बारे में बात करेंगे जो .Net 1.1 पर चलाए जा सकते हैं (सामान्य तौर पर, मैं थोड़ा Linq का उपयोग करता हूं, लेकिन आप आसानी से इससे छुटकारा पा सकते हैं) और आपके सिर में आने वाली किसी भी चीज़ को रोक सकते हैं।

हम अंत में स्पष्ट करेंगे। इस तकनीक का उपयोग करना:
• आप System.DateTime.Now और System.IO.File जैसे निर्माणों को रोक सकते हैं!
• आपके पास सभी लोकप्रिय इंटरसेप्शन लाइब्रेरी के लिए सामान्य सीमाएं सामान्य नहीं होंगी।
अभी भी संदेह में है? फिर पढ़ो!

एओपी सिद्धांत

पृष्ठभूमि

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

प्राचीन समय में, जब इंटरनेट में पीले पृष्ठ, बुलेटिन बोर्ड और उपयोगकर्ता के पृष्ठ शामिल होते थे, तो कुछ सीखने के लिए पुस्तकों को पढ़ना सबसे अच्छा था (नई पीढ़ी के लिए टिप्पणी: एक पुस्तक एक पेपर शीट से बना एक टुकड़ा होता है, जिसमें एक साथ पाठ होता है)। और इनमें से लगभग सभी पुस्तकें आपको लगातार निम्नलिखित OOP नियमों की याद दिलाती हैं:
• नियम संख्या 1: डेटा और कोड एनकैप्सुलेशन की आवश्यकता है
• नियम संख्या 2: नियम संख्या 1 को कभी न तोड़ें

एनकैप्सुलेशन मुख्य लक्ष्य था जिसके लिए OOP तीसरी पीढ़ी की भाषाओं (3GL) में दिखाई दिया।

विकी से:

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

एओपी आम तौर पर दावा करता है कि कभी-कभी एक भाषा के निर्माण के लिए तरीकों (या अन्य कार्यों) के एकीकरण की सुविधा की आवश्यकता होती है जो इस डेटा के बिना समझाया डेटा के साथ काम करते हैं।

क्या आपने इसे पकड़ा? वास्तव में, यह आपको सिद्धांत से आवश्यक है। बहुत बढ़िया!

अब, दो उभरते मुद्दों पर चलते हैं:
• यह "कभी-कभी" कब होता है?
• इसकी आवश्यकता क्यों है?

AOP के लाभों के बारे में ... कुछ परिदृश्य

परिदृश्य ए

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

परिदृश्य b

आपका वेब एप्लिकेशन परीक्षक टीम को जारी किया गया है। सभी कार्यात्मक परीक्षण पास हुए, और आवेदन लोड परीक्षण पर टूट गया। एक गैर-कार्यात्मक आवश्यकता है जो कहती है कि 500 ​​एमएस से अधिक के लिए सर्वर पर किसी भी पेज को संसाधित नहीं किया जा सकता है। विश्लेषण करने के बाद, आपको दर्जनों डेटाबेस क्वेश्चन मिले, जो परिणामों को कैशिंग से बचा सकते हैं।

परिदृश्य बी

आप 200+ कक्षाओं वाले एक आदर्श पुस्तकालय में दो साल के लिए एक डोमेन मॉडल का निर्माण कर रहे हैं। बाद में आपको पता चलेगा कि एप्लिकेशन के लिए एक नया फ्रंट-एंड लिखा जा रहा है और यह आपके सभी ऑब्जेक्ट्स को UI के साथ जोड़ना आवश्यक है। लेकिन समस्या को हल करने के लिए, यह आवश्यक है कि सभी वर्ग INotifyPropertyChanged को लागू करें।

उपरोक्त उदाहरण प्रदर्शित करते हैं कि AOP एक मोक्ष हो सकता है। ये सभी परिदृश्य निम्नलिखित में समान हैं:

क्रॉस-कटिंग चिंता

यह "कभी-कभी" कब होता है?

कुछ वर्गों (बैंकिंग प्रणाली, डेटा एक्सेस सेवाओं, डोमेन-मॉडल) को कार्यक्षमता प्राप्त करने की आवश्यकता होती है, जो सामान्य रूप से, "उनका व्यवसाय" नहीं है।

• बैंकिंग प्रणाली का व्यवसाय धन हस्तांतरित करना है। लॉगिंग ऑपरेशन सरकार चाहती है।
• डेटा प्राप्त करने के लिए डेटा एक्सेस सेवा की आवश्यकता होती है। डेटा कैशिंग एक गैर-कार्यात्मक आवश्यकता है।
• डोमेन मॉडल कक्षाएं आपकी कंपनी के व्यावसायिक तर्क को लागू करती हैं। संपत्ति परिवर्तन के बारे में यूआई की अधिसूचना केवल यूआई द्वारा आवश्यक है।

सामान्य तौर पर, हम उन परिस्थितियों के बारे में बात कर रहे हैं, जहां आपको उन वर्गों की समस्याओं को हल करने के लिए विभिन्न वर्गों के लिए कोड लिखने की आवश्यकता है जो इन वर्गों में निहित नहीं हैं। AOP की बोली में बोलते हुए - कार्यान्वित कार्यों की आवश्यकता है।

लागू की जा रही क्रियाओं को समझना AOP के लिए महत्वपूर्ण है। कोई कार्यान्वित कार्य नहीं हैं - AOP की कोई आवश्यकता नहीं है।

इसकी आवश्यकता क्यों है?
आइए परिदृश्य बी पर एक नज़र डालें।

समस्या यह है कि आपके पास है, उदाहरण के लिए, प्रत्येक वर्ग में औसतन 5 गुण। 200+ कक्षाएं होने पर, आपको कुछ इस तरह से बदलने के लिए कोड के 1000 से अधिक टेम्पलेट टुकड़ों को लागू करना होगा (कॉपी-पेस्ट):

public class Customer { public string Name { get; set; } } 

कुछ इस तरह से:

 public class Customer : INotifyPropertyChanged { public event PropertyChangedEventHandler PropertyChanged; private string _Name; public string Name { get { return _Name; } set { if (value != _Name) { _Name = value; SignalPropertyChanged("Name"); } } } void SignalPropertyChanged(string propertyName) { var pcEvent = this.PropertyChanged; if (pcEvent != null) pcEvent(this, new PropertyChangedEventArgs(propertyName)); } } 

वाह! और यह केवल एक संपत्ति है! वैसे, क्या आप आज तक हैं? कुछ दिनों पहले इंटर्न ने नौकरी छोड़ दी

हमें "तरीकों (या अन्य कार्यों) के संयोजन की आवश्यकता है जो इस डेटा के बिना एनकैप्सुलेटेड डेटा के साथ काम करते हैं।" दूसरे शब्दों में: प्रकार के ग्राहक के डोमेन मॉडल के वर्गों में परिवर्तन किए बिना या न्यूनतम बदलाव के साथ INotifyPropertyChanged कार्यों के कार्यान्वयन को लागू करें।

यदि हम इसे लागू कर सकते हैं, तो हम प्राप्त करते हैं:
• कार्यों का स्पष्ट पृथक्करण
• कोड दोहराव से बचें और विकास को गति दें
• चलो बॉयलरप्लेट कोड के टन के तहत डोमेन कक्षाएं नहीं छिपाते हैं

वाह। लेकिन यह सब कैसे करें?

सैद्धांतिक उत्तर

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

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

एक आदर्श एओपी में, हमें लक्ष्य कोड की किसी भी पंक्ति पर एक कार्रवाई को लागू करने में सक्षम होना चाहिए।
महान, लेकिन अगर हमें एक कार्रवाई संलग्न करने की आवश्यकता है, तो क्या हमें लक्ष्य में इंटरसेप्टर की आवश्यकता है? हाँ, सीईपी!

एओपी में, इंटरसेप्टर का वर्णन (जिस स्थान पर कार्रवाई की जाएगी) का एक नाम है: पॉइंटकट। और वह स्थान जहां कोड वास्तव में बांधता है: कनेक्शन बिंदु।

कि स्पष्ट है? शायद नहीं ... यहाँ छद्म कोड का एक सा है, जो मुझे आशा है कि एक स्पष्टीकरण प्रदान करेगा:

 //  class BankAccount { public string AccountNumber {get;} public int Balance {get; set;} void Withdraw(int AmountToWithdraw) { :public pointcut1; //  ( ,   -    ) Balance -= AmountToWithdraw; } } //   concern LoggingConcern { void LogWithdraw(int AmountToWithdraw) { //   ,     //  'this' –    BankAccount. Console.WriteLine(this.AccountNumber + " withdrawal on-going..."); } } class Program { void Main() { //        pointcut = typeof(Bank).GetPointcut("pointcut1"); //     LoggingConcern.Join(cutpoint, LogWithdraw); //        , //    LoggingConcern   pointcut1  } } 

क्या बॉक्स के बाहर # सही में ऐसा तंत्र होना अच्छा होगा ???

कुछ और अवधारणाएँ

इससे पहले कि हम अपने कार्यान्वयन के लिए आगे बढ़ें, यहाँ कुछ और अवधारणाएँ हैं ...

पहलू क्या है?
यह कार्रवाई, टुकड़ा और कनेक्शन बिंदु का एक संयोजन है।

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

लेकिन सिर्फ एक मिनट ... कार्यान्वयन के बाद क्या करना चाहिए और क्या करना चाहिए?

क्रियाओं को दो श्रेणियों में विभाजित किया गया है:

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

युक्तियाँ।
टिप्स - ऐसी क्रियाएं जो किसी विधि के इनपुट / आउटपुट को बदल सकती हैं।
एक्शन कैशिंग एक बेहतरीन उदाहरण है। जब लक्ष्य विधि निष्पादित की जाती है (उदाहरण के लिए, CustomerService.GetById (int Id)), CachingConcern.TryGetCustomerById (int Id) विधि निष्पादित की जाती है और कैश में पाए गए मान को वापस कर देती है, या अनुपस्थित होने पर निष्पादन जारी रखती है।

सुझाव हैं:
• लक्ष्य अनुभाग में मापदंडों की जाँच करें और यदि आवश्यक हो तो उन्हें बदलने की क्षमता
• लक्ष्य विधियों का निष्पादन रद्द करें और उन्हें अन्य कार्यान्वयन के साथ बदलें
• लक्ष्य विधि के वापसी मूल्य की जाँच करें और उन्हें बदलें या बदलें

क्या आप अभी भी पढ़ रहे हैं? ब्रावो! पार्स क्यू वूस ले वलेज़ बिएन ...

यह AOP की अवधारणाओं और अवधारणाओं के साथ संपन्न होता है। चलो उसे C # में बेहतर जानते हैं।

हमारा कार्यान्वयन

मुझे कोड यू जेई ले ले चिएन दिखाओ!

क्रिया (चिंता)

कार्रवाई को इस जादू को लागू करना चाहिए, जो हमारे लक्ष्य के प्रकार का है।
कोई बात नहीं!

 public interface IConcern<T> { T This { get; } //  ,   ? } 

स्लाइस (पॉइंटकट)

कोड की प्रत्येक पंक्ति के लिए स्लाइस प्राप्त करने का कोई आसान तरीका नहीं है। लेकिन एक-एक करके हम इसे प्राप्त कर सकते हैं और यह System.Reflection.MethodBase वर्ग का उपयोग करके काफी सरल है। MSDN इसके बारे में क्रिया नहीं है: विधियों और निर्माणकर्ताओं के बारे में जानकारी प्रदान करता है।

हमारे बीच, स्लाइसिंग लिंक प्राप्त करने के लिए मेथडबेस का उपयोग करना हमारे कार्य का सबसे शक्तिशाली उपकरण है।
आप कंस्ट्रक्टरों, विधियों, गुणों और घटनाओं के स्लाइसर्स का उपयोग कर सकते हैं, क्योंकि लगभग सभी चीजें जो आप .Net में घोषित करते हैं, अंततः एक विधि के लिए नीचे आती हैं ...

अपने लिए देखें:

 public class Customer { public event EventHandler<EventArgs> NameChanged; public string Name { get; private set; } public void ChangeName(string newName) { Name = newName; NameChanged(this, EventArgs.Empty); } } class Program { static void Main(string[] args) { var t = typeof(Customer); //  (  ) var pointcut1 = t.GetConstructor(new Type[] { }); //  ChangeName var pointcut2 = t.GetMethod("ChangeName"); //  Name var nameProperty = t.GetProperty("Name"); var pointcut3 = nameProperty.GetGetMethod(); var pointcut4 = nameProperty.GetSetMethod(); //     NameChanged var NameChangedEvent = t.GetEvent("NameChanged"); var pointcut5 = NameChangedEvent.GetRaiseMethod(); var pointcut6 = NameChangedEvent.GetAddMethod(); var pointcut7 = NameChangedEvent.GetRemoveMethod(); } } 

कनेक्शन अंक (joinpoint)

कनेक्शन के लिए कोड लिखना वास्तव में सरल है। इस कोड पर एक नज़र डालें:

 void Join(System.Reflection.MethodBase pointcutMethod, System.Reflection.MethodBase concernMethod); 

हम इसे एक रजिस्ट्री की तरह कुछ में जोड़ सकते हैं, जिसे हम बाद में करेंगे, और हम इस तरह कोड लिखना शुरू कर सकते हैं !!!

 public class Customer { public string Name { get; set;} public void DoYourOwnBusiness() { System.Diagnostics.Trace.WriteLine(Name + "   "); } } public class LoggingConcern : IConcern<Customer> { public Customer This { get; set; } public void DoSomething() { System.Diagnostics.Trace.WriteLine(This.Name + "    "); This.DoYourOwnBusiness(); System.Diagnostics.Trace.WriteLine(This.Name + "    "); } } class Program { static void Main(string[] args)h { //    Customer.DoSomething(); var pointcut1 = typeof(Customer).GetMethod("DoSomething"); var concernMethod = typeof(LoggingConcern).GetMethod("DoSomething"); //   AOP.Registry.Join(pointcut1, concernMethod); } } 

क्या हम अपने छद्म कोड से दूर हैं? मेरी राय में, वास्तव में नहीं ...
तो आगे क्या है?

यह सब एक साथ रखकर ...

यह वह जगह है जहाँ समस्याओं और मज़ा एक ही समय में शुरू होता है!
लेकिन चलो एक सरल के साथ शुरू करते हैं

रजिस्ट्री

रजिस्ट्री हमारे कनेक्शन बिंदुओं का रिकॉर्ड रखेगी। कनेक्शन बिंदुओं के लिए सिंगलटन सूची लें। जंक्शन बिंदु एक सरल संरचना है:

 public struct Joinpoint { internal MethodBase PointcutMethod; internal MethodBase ConcernMethod; private Joinpoint(MethodBase pointcutMethod, MethodBase concernMethod) { PointcutMethod = pointcutMethod; ConcernMethod = concernMethod; } //       public static Joinpoint Create(MethodBase pointcutMethod, MethodBase concernMethod) { return new Joinpoint (pointcutMethod, concernMethod); } } 

कुछ खास नहीं ... उसे IEquatable को लागू करने की भी आवश्यकता है, लेकिन कोड को कम करने के लिए, मैंने इसे हटा दिया।

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

 public class AOP : List<Joinpoint> { static readonly AOP _registry; static AOP() { _registry = new AOP(); } private AOP() { } public static AOP Registry { get { return _registry; } } [MethodImpl(MethodImplOptions.Synchronized)] public void Join(MethodBase pointcutMethod, MethodBase concernMethod) { var joinPoint = Joinpoint.Create(pointcutMethod, concernMethod); if (!this.Contains(joinPoint)) this.Add(joinPoint); } } 

एओपी वर्ग का उपयोग करते हुए, आप इस निर्माण को लिख सकते हैं:

 AOP.Registry.Join(pointcut, concernMethod); 

ह्यूस्टन, हमें समस्याएं हैं

यहां हमें एक स्पष्ट और बड़ी समस्या का सामना करना पड़ता है जिसके साथ हमें कुछ करने की आवश्यकता है। अगर डेवलपर इस तरह लिखता है

 var customer = new Customer {Name="test"}; customer.DoYourOwnBusiness(); 

फिर हमारी रजिस्ट्री तक पहुँचने का कोई कारण नहीं है, और हमारा LoggingConcern.DoSomething () विधि शुरू नहीं होगी।

परेशानी यह है कि .नेट हमें इस तरह के कॉल को इंटरसेप्ट करने का आसान तरीका प्रदान नहीं करता है।
चूंकि कोई अंतर्निहित तंत्र नहीं है, इसलिए आपको अपना खुद का बनाने की आवश्यकता है। आपके तंत्र की क्षमताएं आपके AOP के कार्यान्वयन की क्षमताओं को निर्धारित करेंगी।
इस लेख का उद्देश्य सभी संभव अवरोधन तकनीकों पर चर्चा नहीं करना है। बस ध्यान दें कि अवरोधन विधि AOP कार्यान्वयन के बीच एक महत्वपूर्ण अंतर है।

SharpCrafters वेबसाइट (PostSharp स्वामियों) दो मुख्य तकनीकों पर कुछ स्पष्ट जानकारी प्रदान करती है:
• संकलन समय पर एम्बेड करना
• रनटाइम पर एम्बेड करना

हमारे कार्यान्वयन - प्रॉक्सी

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

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

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

इसके अलावा, यदि आपको कोड की किसी भी पंक्ति में कटौती करने में सक्षम होने की आवश्यकता नहीं है, तो पहले दो विकल्प बहुत जटिल हैं।

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

अच्छी खबर यह है कि आपको प्रॉक्सी को लागू करने के लिए कुछ भी करने की आवश्यकता नहीं है। System.Runtime.Remoting.Proxies.RealProxy वर्ग इसे एक इष्टतम तरीके से बनाएगा।
मेरी राय में, वर्ग का नाम उसके उद्देश्य को नहीं दर्शाता है। यह वर्ग एक छद्म नहीं है, बल्कि एक इंटरसेप्टर है। फिर भी, वह हमें अपने GetTransparentProxy () विधि को कॉल करके एक प्रॉक्सी बना देगा, और यह वह है, जिसे वास्तव में, हमें उससे ज़रूरत है।

यहाँ इंटरसेप्टर मछली है:

 public class Interceptor : RealProxy, IRemotingTypeInfo { object theTarget { get; set; } public Interceptor(object target) : base(typeof(MarshalByRefObject)) { theTarget = target; } public override System.Runtime.Remoting.Messaging.IMessage Invoke(System.Runtime.Remoting.Messaging.IMessage msg) { IMethodCallMessage methodMessage = (IMethodCallMessage) msg; MethodBase method = methodMessage.MethodBase; object[] arguments = methodMessage.Args; object returnValue = null; // TODO: //     ,  AOP.Registry //     MethodBase,   "method"... //      ,     //   "theTarget"   ... ;-) return new ReturnMessage(returnValue, methodMessage.Args, methodMessage.ArgCount, methodMessage.LogicalCallContext, methodMessage); } #region IRemotingTypeInfo public string TypeName { get; set; } public bool CanCastTo(Type fromType, object o) { return true; } #endregion } 

कुछ स्पष्टीकरण, के रूप में हम अहसास के दिल में चढ़ गए ...

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

RealProxy, इनवोक विधि (System.Runtime.Remoting.Messaging.IMessage msg) का उपयोग करके पारदर्शी प्रॉक्सी के माध्यम से सभी कॉल प्राप्त करता है। यह यहां है कि हम तरीकों के प्रतिस्थापन के सार का एहसास करते हैं। ऊपर दिए गए कोड में टिप्पणी देखें।

IRemotingTypeInfo के कार्यान्वयन के बारे में: एक वास्तविक दूरस्थ वातावरण में, क्लाइंट सर्वर से किसी ऑब्जेक्ट का अनुरोध करेगा। क्लाइंट एप्लिकेशन को ऑब्जेक्ट के प्रकार के बारे में कुछ भी पता नहीं हो सकता है। तदनुसार, जब क्लाइंट एप्लिकेशन सार्वजनिक ऑब्जेक्ट GetTransparentProxy () को कॉल करता है, तो पर्यावरण रिटर्न ऑब्जेक्ट (पारदर्शी प्रॉक्सी) को एप्लिकेशन अनुबंध का अनुपालन कर सकता है। IRemotingTypeInfo को लागू करने से हम क्लाइंट वातावरण को संकेत देते हैं कि कौन सा वैध है और कौन सा नहीं।

अब हम यहाँ जिस ट्रिक का उपयोग कर रहे हैं, उस पर आश्चर्य करें

 public bool CanCastTo(Type fromType, object o) { return true; } 

एओपी का हमारा संपूर्ण कार्यान्वयन पूरी तरह से दूरस्थ वस्तु पर इन दो शब्दों को लिखने की क्षमता के कारण संभव है: यह सच है। जिसका अर्थ है कि हम GetTransparentProxy () द्वारा लौटाए गए ऑब्जेक्ट को बिना किसी पर्यावरण जांच के किसी भी इंटरफ़ेस में डाल सकते हैं !!!!

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

अब हमारे पास पहले से ही हमारे लक्ष्य उदाहरण के लिए एक सभ्य अवरोधन तंत्र है। लेकिन हमारे पास अभी भी कंस्ट्रक्टर अवरोधन और पारदर्शी परदे नहीं हैं। ये है फैक्ट्री के लिए चुनौती ...

कारखाना है

ज्यादा कुछ नहीं कहना है। यहाँ एक क्लास फिश है।

 public static class Factory { public static object Create<T>(params object[] constructorArgs) { T target; // TODO: //   typeof(T)   constructorArgs (-   ) //    ,         //   ,    -     //     “target” ()   //   GetProxy return GetProxyFor<T>(target); } public static object GetProxyFor<T>(object target = null) { //         // (    ,  ) //        return new Interceptor(target).GetTransparentProxy(); } } 

ध्यान दें कि फ़ैक्टरी क्लास हमेशा ऑब्जेक्ट का ऑब्जेक्ट लौटाता है। हम टाइप T की एक वस्तु को केवल इसलिए वापस नहीं कर सकते क्योंकि पारदर्शी प्रॉक्सी टाइप T की नहीं है, यह System.Runtime.Remoting.Proxies .__ TransparentProxy का प्रकार है। लेकिन पर्यावरण द्वारा हमें दिए गए संकल्प को याद रखें, हम बिना जांचे परखे किसी भी इंटरफेस में लौटी हुई वस्तु को डाल सकते हैं!

हमने अपने एओपी वर्ग में फैक्टरी वर्ग को इस उम्मीद के साथ रखा है कि हम अपने ग्राहकों को एक साफ-सुथरा कोड देंगे। इसे उपयोग अनुभाग में देखा जा सकता है।

नवीनतम कार्यान्वयन नोट

यदि आप इस बिंदु पर पढ़ते हैं, तो आप एक नायक हैं! Bravissimo! कुडोस!

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

चेतावनी! अपनी परियोजना में कोड का उपयोग करने से पहले, पैनेल्टिमस को ध्यान से पढ़ें। और अगर आपको नहीं पता कि पैनेल्टिमस का क्या मतलब है, तो लिंक पर क्लिक करें।

के उपयोग

मैंने पहले से ही बहुत सारी चीजें लिखी हैं, लेकिन फिर भी यह नहीं दिखाया है कि यह सब क्या करना है। और यहाँ वह सत्य का क्षण है!

संग्रह में क्या है ( डाउनलोड करें )

संग्रह में निम्नलिखित पहलुओं के कार्यान्वयन को प्रदर्शित करने वाले 5 उदाहरण शामिल हैं:
• डिजाइनर का अवरोधन
• तरीकों और गुणों का अवरोधन
• घटनाओं का अवरोधन
• इनिशियलाइज़ेशन इंटरसेप्शन टाइप करें
• अवरोधन फ़ाइल। ReadAllText (स्ट्रिंग पथ)

और यहाँ मैं पाँच में से दो का प्रदर्शन करूँगा: सबसे कम और स्पष्ट।

विधियों और गुणों का अवरोधन

सबसे पहले, हमें एक डोमेन मॉडल की आवश्यकता है। कुछ खास नहीं।

 public interface IActor { string Name { get; set; } void Act(); } public class Actor : IActor { public string Name { get; set; } public void Act() { Console.WriteLine("My name is '{0}'. I am such a good actor!", Name); } } 

अब हमें कार्रवाई की जरूरत है

 public class TheConcern : IConcern<Actor> { public Actor This { get; set; } public string Name { set { This.Name = value + ". Hi, " + value + " you've been hacked"; } } public void Act() { This.Act(); Console.WriteLine("You think so...!"); } } 

जब आवेदन शुरू हो जाता है, तो हम रजिस्ट्री को हमारे कनेक्शन बिंदुओं के बारे में सूचित करते हैं

 // Weave the Name property setter AOP.Registry.Join ( typeof(Actor).GetProperty("Name").GetSetMethod(), typeof(TheConcern).GetProperty("Name").GetSetMethod() ); // Weave the Act method AOP.Registry.Join ( typeof(Actor).GetMethod("Act"), typeof(TheConcern).GetMethod("Act") ); 

और अंत में, हम कारखाने में एक वस्तु बनाते हैं

 var actor1 = (IActor) AOP.Factory.Create<Actor>(); actor1.Name = "the Dude"; actor1.Act(); 

कृपया ध्यान दें कि हमने अभिनेता वर्ग के निर्माण का अनुरोध किया था, लेकिन हम परिणाम को इंटरफ़ेस पर ला सकते हैं, इसलिए हम Ictor को ले जाएंगे, क्योंकि वर्ग इसे लागू करता है।

यदि आप कंसोल एप्लिकेशन में यह सब चलाते हैं, तो हमें यह मिलता है:
My name is 'the Dude. Hi, the Dude you've been hacked'. I am such a good actor!
You think so...!


अवरोधन फ़ाइल। ReadAllText (स्ट्रिंग पथ)

यहाँ दो छोटे मुद्दे हैं:
• फ़ाइल वर्ग स्थिर है
• और किसी भी इंटरफेस को लागू नहीं करता है

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

 public interface IFile { string[] ReadAllLines(string path); } 

हमारी कार्रवाई

 public class TheConcern { public static string[] ReadAllLines(string path) { return File.ReadAllLines(path).Select(x => x + " hacked...").ToArray(); } } 

प्वाइंट रजिस्ट्रेशन में शामिल हों

 AOP.Registry.Join ( typeof(File).GetMethods().Where(x => x.Name == "ReadAllLines" && x.GetParameters().Count() == 1).First(), typeof(TheConcern).GetMethod("ReadAllLines") ); 

और अंत में, कार्यक्रम का निष्पादन

 var path = Path.Combine(Environment.CurrentDirectory, "Examples", "data.txt"); var file = (IFile) AOP.Factory.Create(typeof(File)); foreach (string s in file.ReadAllLines(path)) Console.WriteLine(s); 

इस उदाहरण में, ध्यान दें कि हम Factory.Create पद्धति का उपयोग नहीं कर सकते हैं, जैसा कि स्थैतिक प्रकारों का उपयोग तर्कों के रूप में नहीं किया जा सकता है।

संदर्भ

बिना किसी विशेष आदेश के।
क्यूई 4 जे से ट्यूटोरियल
• विस्तार RealProxy
• डायनेमिक प्रॉक्सी ट्यूटोरियल (Castle.net)
• LinFu.DynamicProxy: एक लाइटवेट प्रॉक्सी जनरेटर
• डायनेमिक डेकोरेटर का उपयोग करके पहलुओं को जोड़ें
• AOP इंटरसेप्टर के रूप में कार्य करने के लिए CLR प्रोफाइलर को लागू करना
• अवरोधन .Net
• क्लीनर मेंटेनेंस कोड के लिए पहलू जोड़ने के लिए एस्पेक्ट फ्लुएंट रास्ता

आगे क्या है?

हम एओपी के मुख्य लक्ष्य को प्राप्त करने में सक्षम थे: पहलू का एहसास करने और इसे निष्पादन के लिए पंजीकृत करने के लिए। TinyAOP का जन्म हुआ। लेकिन एओपी की भूमि में आपका रास्ता अभी खत्म नहीं हुआ है, और आप गहराई तक जाना चाहते हैं।

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

कारण 2: अशुद्धियों और एकत्रीकरण के विषयों का खुलासा नहीं किया गया है, और आप उनसे बहुत अच्छे की उम्मीद कर सकते हैं।

कारण 3: हमें प्रदर्शन और स्थिरता की आवश्यकता है। अब कोड केवल अवधारणा का प्रमाण है। यह काफी धीमा है और इसे बहुत तेज बनाया जा सकता है। जाँचने में त्रुटि हुई या तो चोट नहीं लगी।

कारण 4: हम लगभग सभी वर्गों को रोकते हैं, लेकिन इंटरसेप्टिंग इंटरफेस के बारे में क्या?

कारण 5: क्या आपके लिए अभी भी बहुत कम कारण है?

निष्कर्ष

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

अब जब आप AOP के बारे में जानते हैं, तो आप अपना खुद का कार्यान्वयन लिख सकते हैं।

फिर एक अनुवादक को पेश किया जाता है और एक गैग ले जाने लगता है

हालाँकि मैं इस खंड के बारे में लेखक से पूरी तरह सहमत हूँ।
Habahabr.ru, codeproject.com और जैसी साइटें केवल इसलिए मौजूद हैं क्योंकि विभिन्न लोग उन पर लेख पोस्ट करते हैं। इससे कोई फर्क नहीं पड़ता कि वे ऐसा क्यों करते हैं, लेकिन यह काम किया जा रहा है। कृपया लेखकों की उपेक्षा न करें। यदि आप लेख पसंद नहीं करते हैं, तो टिप्पणियों में स्पष्ट करें कि क्या गलत है। यदि आप सिर्फ माइनस करते हैं, तो कोई नहीं जानता कि बेहतर कैसे किया जाए। यदि आप इसे पसंद करते हैं, तो या तो चुप मत रहो!

और अब यह सुनिश्चित करने के लिए कि अनुवादक का अंतराल है

वास्तव में, मेरे आश्चर्य विवेक के लिए कई शब्दों का अनुवाद से AOP काम नहीं किया, इसलिए मैं प्रस्ताव में टिप्पणी एक अच्छा और सरल रूसी शब्द निम्नलिखित शब्दों के लिए सुझाव है कि:
• पहलू (वहाँ समझा जा रहा है, लेकिन अभी भी)
• चिंता
• JoinPoint
• पार काटने
• बुनाई ( जुलाहा - कुछ भी नहीं, लेकिन एक रूसी शब्द खोजने के लिए बेहतर होगा)

लेखक: गुइरेक ले बार्स