😇 👨‍👨‍👧‍👦 🌕 PHP में पहलू-उन्मुख प्रोग्रामिंग का परिचय 🎈 👩🏼‍💻 🦑

सॉफ्टवेयर विकसित करते समय, प्रोग्रामर और आर्किटेक्ट अपघटन का उपयोग करते हैं - वस्तुओं और कक्षाओं, वस्तुओं, उनके गुणों और विधियों के रूप में उनके बीच संबंधों का प्रतिनिधित्व।

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

लेकिन क्या सब कुछ इतना सुविधाजनक है?

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

लगभग सब कुछ क्यों?

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

मैं इस समस्या को कैसे हल कर सकता हूं?

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

इस व्यवहार का वर्णन करने के लिए, निम्नलिखित शब्द प्रस्तावित किए गए थे:

1. सलाह - सलाह। यह प्रदर्शन किया जाना है। बयान के लिए "खाने से पहले अपने हाथ धोएं," सलाह होगी "अपने हाथ धोएं।" जैसा कि आप देख सकते हैं, युक्तियाँ वास्तविक दुनिया से बहुत वास्तविक कार्यों का वर्णन करती हैं, जिसका अर्थ है कि उन्हें विधियों, अनाम कार्यों और क्लोजर के रूप में दर्शाया जा सकता है। प्रत्येक परिषद को पता है कि वह किस स्थान से संबंधित है, इसलिए कार्रवाई के बारे में लगभग सभी जानकारी इसमें उपलब्ध है।

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

3. पॉइंटकट - कार्यान्वयन बिंदुओं का एक टुकड़ा। एक टुकड़ा कार्यान्वयन बिंदुओं की बहुलता को परिभाषित करता है जिस पर सलाह लागू करना है। AOP की दुनिया में, यह SQL से SELECT का एक एनालॉग है। अंकों के कटऑफ को निर्दिष्ट करने के लिए वाक्यविन्यास अलग-अलग हो सकता है, जैसे कि कार्यान्वयन स्वयं, लेकिन एक नियम के रूप में, ये ऐसे फिल्टर हैं जो इनपुट पर बहुत सारे एम्बेडिंग अंक प्राप्त करते हैं, जिसमें से केवल उपयुक्त का चयन किया जाना चाहिए। गो लाइब्रेरी में! एनोटेशन का उपयोग मुख्य रूप से स्लाइस को निर्दिष्ट करने के लिए किया जाता है, लेकिन भविष्य में xml, yaml और कोड का उपयोग करने के लिए समर्थन होगा। बिंदुओं का एक टुकड़ा इस तरह दिख सकता है: एक कक्षा में सभी सार्वजनिक विधियाँ, सभी स्थैतिक विधियाँ * इनिट (), एक विशिष्ट एनोटेशन के साथ सभी विधियाँ, आदि।

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

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

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

सौ बार सुनने से बेहतर है एक बार देखना।

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

/** * Human class example */ class Human {     /** * Eat something */     public function eat()     {         echo "Eating...", PHP_EOL;     }     /** * Clean the teeth */     public function cleanTeeth()     {         echo "Cleaning teeth...", PHP_EOL;     }     /** * Washing up */     public function washUp()     {         echo "Washing up...", PHP_EOL;     }     /** * Working */     public function work()     {         echo "Working...", PHP_EOL;     }     /** * Go to sleep */     public function sleep()     {         echo "Go to sleep...", PHP_EOL;     } }

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

 /** * Human class example */ class Human {    /** * Eat something */    public function eat()    { $this->washUp();        echo "Eating...", PHP_EOL; $this->cleanTeeth();    } // ....    /** * Go to sleep */    public function sleep()    { $this->cleanTeeth();        echo "Go to sleep...", PHP_EOL;    } }

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

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

एक ओर, मुख्य विधियाँ इस तर्क को समाप्‍त कर देंगी, लेकिन हमारी कक्षा प्रस्फुटित होने लगेगी, सीधे "खाओ (") विधि को कॉल करना संभव होगा, वर्ग इंटरफ़ेस अनावश्यक तरीकों से अटे पड़े होंगे, और कोड में त्रुटियों की संख्या बढ़ने लगेगी। फिर से एक विकल्प नहीं है।

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

पहलू उन्मुख दृष्टिकोण

आप शायद पहले ही समझ चुके हैं कि AOP आपको तार्किक ब्लॉकों में विभाजित करने की अनुमति देता है जो OOP का उपयोग करके नहीं किया जा सकता है। हालांकि, यह तकनीक बल्कि जटिल है, इसलिए एओपी मुख्य रूप से उन लोगों के लिए है, जिन्होंने ऑब्जेक्ट-उन्मुख प्रतिमान की सभी जटिलताओं को समझ लिया है और कुछ नया खोजना चाहते हैं।

पहलू-उन्मुख प्रोग्रामिंग (एओपी) के संस्थापक ग्रेगर किक्लेज ने अपने साक्षात्कार में एओपी के सार के अपने दृष्टिकोण को साझा किया: "... एओपी अनिवार्य रूप से संरचना तंत्र के विकास में अगला चरण है। आज यह स्पष्ट है कि ऑब्जेक्ट प्रक्रियाओं को प्रतिस्थापित नहीं करते हैं, लेकिन केवल उच्च-स्तरीय संरचना तंत्र बनाने का एक तरीका है। "और पहलू भी, वस्तुओं को प्रतिस्थापित नहीं करते हैं; वे केवल एक अन्य प्रकार की संरचना प्रदान करते हैं।"

आइए हमारे मामले को एक पहलू-उन्मुख प्रतिमान के दृष्टिकोण से वर्णन करने का प्रयास करें। ऐसा करने के लिए, हमारे "स्वच्छ" तरीकों के साथ "आदमी" का "शुद्ध" वर्ग लें और पहलू वर्ग का उपयोग करके आवश्यक विधियों के लिए युक्तियों का वर्णन करें:

 namespace Aspect; use Go\Aop\Aspect; use Go\Aop\Intercept\MethodInvocation; use Go\Lang\Annotation\After; use Go\Lang\Annotation\Before; use Go\Lang\Annotation\Around; use Go\Lang\Annotation\Pointcut; /** * Healthy live aspect */ class HealthyLiveAspect implements Aspect {    /** * Pointcut for eat method * * @Pointcut("execution(public Human->eat(*))") */    protected function humanEat() {}    /** * Method that recommends to wash up before eating * * @param MethodInvocation $invocation Invocation * @Before(pointcut="humanEat()") // Short pointcut name */    protected function washUpBeforeEat(MethodInvocation $invocation)    {        /** @var $person \Human */        $person = $invocation->getThis();        $person->washUp();    }    /** * Method that recommends to clean teeth after eating * * @param MethodInvocation $invocation Invocation * @After(pointcut="Aspect\HealthyLiveAspect->humanEat()") // Full-qualified pointcut name */    protected function cleanTeethAfterEating(MethodInvocation $invocation)    {        /** @var $person \Human */        $person = $invocation->getThis();        $person->cleanTeeth();    }    /** * Method that recommends to clean teeth before going to sleep * * @param MethodInvocation $invocation Invocation * @Before("execution(public Human->sleep())") */    protected function cleanTeethBeforeSleep(MethodInvocation $invocation)    {        /** @var $person \Human */        $person = $invocation->getThis();        $person->cleanTeeth();    } }

मुझे लगता है कि यह कोड अपने आप में काफी समझ में आता है, लेकिन कुछ टिप्पणियों को जोड़ना बेहतर है।

सबसे पहले, हमने बिंदुओं के एक स्लाइस को परिभाषित किया - एक खाली humanEat() विधि, विशेष @Pointcut("execution(public Human->eat(*))") एनोटेशन @Pointcut("execution(public Human->eat(*))") के साथ चिह्नित। सिद्धांत रूप में, एक अलग स्लाइस नहीं बनाना संभव था, लेकिन प्रत्येक टिप से पहले इसे अलग-अलग इंगित करने के लिए, लेकिन चूंकि हमारे पास इस स्लाइस के लिए कई सुझाव हैं, इसलिए हम इसे एक अलग परिभाषा में रख सकते हैं। स्लाइस का निर्धारण करने में स्वयं और इसके कोड का उपयोग नहीं किया जाता है और केवल पहलू में ही स्लाइस को इंगित करने और पहचानने के लिए सेवा प्रदान करता है।

दूसरे, हमने स्लाइस के लिए विशिष्ट कार्यान्वयन स्थान को @After करने के लिए @Before और @After का उपयोग करते हुए, खुद को पहलू विधियों के रूप में युक्तियों का वर्णन किया। आप तुरंत स्लाइस को एनोटेशन में सेट कर सकते हैं, जैसा कि cleanTeethBeforeSleep विधि में किया गया है: @Before("execution(public Human->sleep())") । प्रत्येक नोक मेथड MethodInvocation ऑब्जेक्ट के कारण निष्पादन बिंदु के बारे में आवश्यक जानकारी प्राप्त करता है, जिसमें कहा जाता है ऑब्जेक्ट (एक स्थिर विधि के लिए एक वर्ग), बुलाया विधि के तर्क, साथ ही कार्यक्रम (विधि प्रतिबिंब) में बिंदु के बारे में जानकारी। वस्तुओं के गुणों तक पहुँचने के लिए इसी तरह की जानकारी प्राप्त की जा सकती है।

अब हमारा कोड चलाएं:

 include isset($_GET['original']) ? './autoload.php' : './autoload_aspect.php'; // Test case with human $man = new Human(); echo "Want to eat something, let's have a breakfast!", PHP_EOL; $man->eat(); echo "I should work to earn some money", PHP_EOL; $man->work(); echo "It was a nice day, go to bed", PHP_EOL; $man->sleep();

यदि हम इस कोड को किसी ब्राउज़र में चलाते हैं, तो हम निम्न आउटपुट देख सकते हैं:

 Want to eat something, let's have a breakfast! Washing up... Eating... Cleaning teeth... I should work to earn some money Working... It was a nice day, go to bed Cleaning teeth... Go to sleep...

अन्य फ़ाइलों में रुचि रखने वालों के लिए:

autoload.php

 /** * Show all errors in code */ ini_set('display_errors', true); /** * Register PSR-0 autoloader for our code, any components can be used here */ spl_autoload_register(function($originalClassName) { $className = ltrim($originalClassName, '\\'); $fileName = ''; $namespace = ''; if ($lastNsPos = strripos($className, '\\')) { $namespace = substr($className, 0, $lastNsPos); $className = substr($className, $lastNsPos + 1); $fileName = str_replace('\\', DIRECTORY_SEPARATOR, $namespace) . DIRECTORY_SEPARATOR; } $fileName .= str_replace('_', DIRECTORY_SEPARATOR, $className) . '.php'; $resolvedFileName = stream_resolve_include_path($fileName); if ($resolvedFileName) { require_once $resolvedFileName; } return (bool) $resolvedFileName; }); ob_start(function($content) { return str_replace(PHP_EOL, "<br>" . PHP_EOL, $content); });

autoload_aspect.php

 include '../src/Go/Core/AspectKernel.php'; include 'DemoAspectKernel.php'; // Initialize demo aspect container DemoAspectKernel::getInstance()->init(array( // Configuration for autoload namespaces 'autoload' => array( 'Go' => realpath(__DIR__ . '/../src'), 'TokenReflection' => realpath(__DIR__ . '/../vendor/andrewsville/php-token-reflection/'), 'Doctrine\\Common' => realpath(__DIR__ . '/../vendor/doctrine/common/lib/') ), // Default application directory 'appDir' => __DIR__ . '/../demos', // Cache directory for Go! generated classes 'cacheDir' => __DIR__ . '/cache', // Include paths for aspect weaving 'includePaths' => array(), 'debug' => true ));

DemoAspectKernel.php

 use Aspect\HealthyLiveAspect; use Go\Core\AspectKernel; use Go\Core\AspectContainer; /** * Demo Aspect Kernel class */ class DemoAspectKernel extends AspectKernel { /** * Returns the path to the application autoloader file, typical autoload.php * * @return string */ protected function getApplicationLoaderPath() { return __DIR__ . '/autoload.php'; } /** * Configure an AspectContainer with advisors, aspects and pointcuts * * @param AspectContainer $container * * @return void */ protected function configureAop(AspectContainer $container) { $container->registerAspect(new HealthyLiveAspect()); } }

हमें क्या मिला? सबसे पहले, "मानव" वर्ग में खुद के तरीकों के तर्क में कोई कचरा नहीं है। पहले से ही उत्कृष्ट है, क्योंकि इसे बनाए रखना आसान होगा। दूसरे, ऐसी कोई विधियाँ नहीं हैं जो वर्ग विधियों की मुख्य कार्यक्षमता की नकल करती हैं। तीसरा, तर्क को पहलू में समझने योग्य युक्तियों के रूप में प्रस्तुत किया जाता है, क्योंकि युक्तियों का वास्तविक अर्थ होता है, जिसका अर्थ है कि हमने कार्यक्षमता में केवल एक अपघटन किया है और हमारे आवेदन को अधिक संरचित किया है! इसके अलावा, पहलू वर्ग स्वयं एक समझदार लक्ष्य का वर्णन करता है - एक स्वस्थ जीवन शैली। अब सब कुछ अपनी जगह पर है और हम अतिरिक्त तर्क को आसानी से बदल सकते हैं और स्वयं के शुद्ध तर्क के साथ काम कर सकते हैं।

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

संदर्भ:

आधिकारिक साइट http://go.aopphp.com
स्रोत कोड https://github.com/lisachenko/go-aop-php

PHP में पहलू-उन्मुख प्रोग्रामिंग का परिचय

लेकिन क्या सब कुछ इतना सुविधाजनक है?

लगभग सब कुछ क्यों?

मैं इस समस्या को कैसे हल कर सकता हूं?

सौ बार सुनने से बेहतर है एक बार देखना।

पहलू उन्मुख दृष्टिकोण

More articles: