PHP में डुप्लिकेट एंड-टू-एंड कोड से छुटकारा पाएं: AOP के साथ कोड को फिर से भरना

मुझे लगता है कि प्रत्येक प्रोग्रामर एकमात्र जिम्मेदारी के सिद्धांत को जानता है, यह कुछ भी नहीं है कि यह मौजूद है: इसे देखते हुए, आप कोड को बेहतर लिख सकते हैं, यह अधिक समझने योग्य होगा, इसे संशोधित करना आसान होगा।

लेकिन हम में से प्रत्येक कोड के साथ जितना अधिक काम करता है, उतना ही समझ में आता है कि भाषा के मौजूदा स्तर पर - वस्तु-उन्मुख - यह नहीं किया जा सकता है। लेकिन अंत-टू-एंड कार्यक्षमता का तथ्य हमें एकमात्र जिम्मेदारी के सिद्धांत का पालन करने से रोकता है।

यह लेख डुप्लिकेट एंड-टू-एंड कोड से छुटकारा पाने के बारे में है, और इसे AOP के साथ थोड़ा बेहतर कैसे बनाया जाए।

एंड-टू-एंड कार्यक्षमता या गीला कोड

किसी भी एप्लिकेशन में लगभग 95% की संभावना के साथ, आप एंड-टू-एंड कार्यक्षमता के टुकड़े पा सकते हैं जो कोडिंग, लॉगिंग, अपवाद हैंडलिंग, लेन-देन नियंत्रण और एक्सेस अधिकार भेदभाव की आड़ में कोड में छिपे हुए हैं। आप नाम से अनुमान लगाया होगा, यह कार्यक्षमता सभी आवेदन परतों पर लाइव है और हमें बलों कई महत्वपूर्ण सिद्धांतों को तोड़ने के लिए (आप भी परतें होती हैं?): सूखी और KISS । DRY सिद्धांत का उल्लंघन करते हुए, आप स्वचालित रूप से WET सिद्धांत का उपयोग करना शुरू कर देते हैं और कोड "गीला" हो जाता है, जो कि लाइन्स ऑफ़ कोड (LOC), भारित विधि गणना (WMC), साइक्लोमैटिक कॉम्प्लेक्सिटी (CCN) मैट्रिक्स में वृद्धि के रूप में परिलक्षित होता है।

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

सबसे पहले, विधि का तर्क स्वयं लिखा जाता है, जिसमें आवश्यक और पर्याप्त कार्यान्वयन शामिल हैं:

/** * Creates a new user * * @param string $newUsername Name for a new user */ public function createNewUser($newUsername) { $user = new User(); $user->setName($newUsername); $this->entityManager->persist($user); $this->entityManager->flush(); } 

... इसके बाद हम एक्सेस अधिकारों की जांच के लिए कोड की 3 और पंक्तियों को जोड़ते हैं

 /** ... */ public function createNewUser($newUsername) { if (!$this->security->isGranted('ROLE_ADMIN')) { throw new AccessDeniedException(); } $user = new User(); $user->setName($newUsername); $this->entityManager->persist($user); $this->entityManager->flush(); } 

... तो विधि की शुरुआत और अंत लॉग करने के लिए 2 और लाइनें

 /** ... */ public function createNewUser($newUsername) { if (!$this->security->isGranted('ROLE_ADMIN')) { throw new AccessDeniedException(); } $this->logger->info("Creating a new user {$newUsername}"); $user = new User(); $user->setName($newUsername); $this->entityManager->persist($user); $this->entityManager->flush(); $this->logger->info("User {$newUsername} was created"); } 

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

आइए मौजूदा समस्याओं को क्रॉस-कटिंग कार्यक्षमता समस्याओं के समाधान पर देखें।

स्वच्छता स्वास्थ्य की कुंजी है! पहले स्वास्थ्य!

मैं आवेदन विकास के संदर्भ में शीर्षक को पढ़ने की सलाह देता हूं: "कोड स्वच्छता आवेदन के स्वास्थ्य की कुंजी है! आवेदन का स्वास्थ्य पहले है! " प्रत्येक डेवलपर के सामने इस तरह के संकेत को लटका देना अच्छा होगा, हमेशा इसे याद रखने के लिए :)

इसलिए, हमने कोड को साफ रखने का फैसला किया। हमारे पास क्या समाधान हैं और हम क्या उपयोग कर सकते हैं?

सज्जाकार

सज्जाकार पहली चीज है जो दिमाग में आती है। डेकोरेटर एक संरचनात्मक डिजाइन टेम्पलेट है जिसे किसी वस्तु में अतिरिक्त व्यवहार को गतिशील रूप से जोड़ने के लिए डिज़ाइन किया गया है। डेकोरेटर पैटर्न कार्यक्षमता का विस्तार करने के लिए उपवर्ग के अभ्यास का एक लचीला विकल्प प्रदान करता है।

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

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

हालांकि, सज्जाकारों का मध्यम उपयोग पूरी तरह से उचित है।

प्रॉक्सी कक्षाएं

प्रॉक्सी क्लासेस दूसरी चीज है जो दिमाग में आती है। प्रॉक्सी - एक डिज़ाइन पैटर्न, एक ऑब्जेक्ट प्रदान करता है जो किसी अन्य ऑब्जेक्ट तक पहुंच को नियंत्रित करता है, सभी कॉल को इंटरसेप्ट करता है (यह एक कंटेनर के रूप में कार्य करता है)।

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

लेकिन एक प्लस है: 100 वर्गों के मामले में, हम सभी वर्गों के लिए एक कैशिंग प्रॉक्सी लिख सकते हैं। लेकिन! 100 इंटरफेस पर टाइपिंगहिंट को छोड़ने की कीमत पर, जो आधुनिक अनुप्रयोगों को विकसित करते समय स्पष्ट रूप से अस्वीकार्य है।

घटनाओं और प्रेक्षक पैटर्न

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

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

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

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

 class Foo { // ... public function __call($method, $arguments) { // create an event named 'foo.method_is_not_found' $event = new HandleUndefinedMethodEvent($this, $method, $arguments); $this->dispatcher->dispatch('foo.method_is_not_found', $event); // no listener was able to process the event? The method does not exist if (!$event->isProcessed()) { throw new \Exception(sprintf('Call to undefined method %s::%s.', get_class($this), $method)); } // return the listener returned value return $event->getReturnValue(); } } 

सिग्नल और स्लॉट

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

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

 use lithium\analysis\Logger; use lithium\data\Connections; // Set up the logger configuration to use the file adapter. Logger::config(array( 'default' => array('adapter' => 'File') )); // Filter the database adapter returned from the Connections object. Connections::get('default')->applyFilter('_execute', function($self, $params, $chain) { // Hand the SQL in the params headed to _execute() to the logger: Logger::debug(date("DM j G:i:s") . " " . $params['sql']); // Always make sure to keep the filter chain going. return $chain->next($self, $params, $chain); }); 

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

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

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

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

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

पुस्तकालय जाओ! AOP PHP

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

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

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

AOP का उपयोग करके पास-थ्रू कोड रीफैक्टरिंग

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

हम कोड से लॉगिंग निकालते हैं

तो, आइए कल्पना करें कि हमारे पास 20 वर्गों में सभी निष्पादन योग्य सार्वजनिक तरीकों की लॉगिंग है जो एक्मे नेमस्पेस में हैं। यह कुछ इस तरह दिखता है:

 namespace Acme; class Controller { public function updateData($arg1, $arg2) { $this->logger->info("Executing method " . __METHOD__, func_get_args()); // ... } } 

आइए पहलुओं का उपयोग करके इस कोड को लें और रिफ्लेक्टर करें! यह नोटिस करना आसान है कि लॉगिंग स्वयं विधि के कोड से पहले की जाती है, इसलिए तुरंत सलाह का प्रकार चुनें - इससे पहले। अगला, हमें कार्यान्वयन के बिंदु को निर्धारित करने की आवश्यकता है - एक्मे नाम स्थान के अंदर सभी सार्वजनिक तरीकों का कार्यान्वयन। यह नियम अभिव्यक्ति के निष्पादन (सार्वजनिक एक्मे \ * -> * ()) द्वारा परिभाषित किया गया है। तो, हम LoggingAspect लिखते हैं:

 use Go\Aop\Aspect; use Go\Aop\Intercept\MethodInvocation; use Go\Lang\Annotation\Before; /** * Logging aspect */ class LoggingAspect implements Aspect { /** @var null|LoggerInterface */ protected $logger = null; /** ... */ public function __construct($logger) { $this->logger = $logger; } /** * Method that should be called before real method * * @param MethodInvocation $invocation Invocation * @Before("execution(public Acme\*->*())") */ public function beforeMethodExecution(MethodInvocation $invocation) { $obj = $invocation->getThis(); $class = is_object($obj) ? get_class($obj) : $obj; $type = $invocation->getMethod()->isStatic() ? '::' : '->'; $name = $invocation->getMethod()->getName(); $method = $class . $type . $name; $this->logger->info("Executing method " . $method, $invocation->getArguments()); } } 

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

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

पारदर्शी कैशिंग

मुझे लगता है कि हर कोई कैशिंग का उपयोग करके बॉयलरप्लेट विधि कोड जानता है:

  /** ... */ public function cachedMethod() { $key = __METHOD__; $result = $this->cache->get($key, $success); if (!$success) { $result = // ... $this->cache->set($key, $result); } return $result; } 

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

 use Go\Aop\Aspect; use Go\Aop\Intercept\MethodInvocation; use Go\Lang\Annotation\Around; class CachingAspect implements Aspect { /** * Cache logic * * @param MethodInvocation $invocation Invocation * @Around("@annotation(Annotation\Cacheable)") */ public function aroundCacheable(MethodInvocation $invocation) { static $memoryCache = array(); $obj = $invocation->getThis(); $class = is_object($obj) ? get_class($obj) : $obj; $key = $class . ':' . $invocation->getMethod()->name; if (!isset($memoryCache[$key])) { $memoryCache[$key] = $invocation->proceed(); } return $memoryCache[$key]; } } 

इस टिप में, सबसे दिलचस्प बात मूल विधि को कॉल करना है, जिसे MethodInvocation ऑब्जेक्ट पर कॉल आगे () द्वारा किया जाता है, जिसमें वर्तमान विधि के बारे में जानकारी होती है। यह देखना आसान है कि यदि हमारे पास कैश में डेटा है, तो हम मूल विधि को नहीं कहते हैं। उसी समय, आपका कोड किसी भी तरह से नहीं बदलता है!
इस पहलू के होने पर, हम किसी भी विधि से पहले एनोटेशन \ Cacheable का एनोटेट कर सकते हैं और यह विधि AOP के लिए स्वचालित रूप से कैश की जाएगी। हम सभी तरीकों से गुजरते हैं और कैशिंग लॉजिक को काटते हैं, इसे एनोटेशन के साथ बदल देते हैं। अब कैशिंग का उपयोग करके बॉयलरप्लेट विधि कोड सरल और सुरुचिपूर्ण दिखता है:

  /** * @Cacheable */ public function cachedMethod() { $result = // ... return $result; } 

इस उदाहरण को गो! लाइब्रेरी के डेमो फोल्डर के अंदर भी पाया जा सकता है एओपी पीएचपी, साथ ही साथ उस प्रतिबद्ध को देखें जो उपरोक्त कार्रवाई को लागू करता है।

निष्कर्ष

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

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

यदि आपके पास पुस्तकालय के बारे में प्रश्न और सुझाव हैं, तो मैं ख़ुशी से उनके साथ चर्चा करूँगा। मुझे आशा है कि Habré पर मेरा पहला लेख आपके लिए उपयोगी था।

संदर्भ

1. स्रोत कोड https://github.com/lisachenko/go-aop-php
2. SymfonyCampUA-2012 की प्रस्तुति http://www.slideshare.net/lisachenko/php-go-aop
3. SymfonyCampUA-2012 वीडियो http://www.youtube.com/watch?v=ZXbREKT5GWE
4. ZF2 में सभी तरीकों के अवरोधन का एक उदाहरण (क्लोनिंग के बाद, हम संगीतकार के माध्यम से निर्भरता स्थापित करते हैं) https://github.com/lisachenko/zf2-aspect
5. विषय पर दिलचस्प लेख: पहलू, फिल्टर और संकेत - हे भगवान! (एन)