पहलू आधारित प्रोग्रामिंग

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

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

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

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

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

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

इस आलेख के उदाहरण एस्पेक्टजे का उपयोग करते हैं।

माइक्रोसाॅफ्ट ट्रांसैक्शन सर्वर को एओपी का पहला प्रमुख एप्लिकेशन माना जाता है, जिसके बाद इंटरप्राइस जावाबींस आता है।

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

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

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

इस उदाहरण में, अन्य मौलिक कार्यक्षमता जिसे कभी-कभी व्यावसायिक तर्क समस्या कहा जाता है, इसके साथ उलझ गई हैं। इस प्रकार लेन-देन, सुरक्षा और लॉगिंग सभी क्रॉस-कटिंग आने वाली सम्स्याओं का उदाहरण देते हैं।

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

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

इसलिए उपरोक्त उदाहरण के लिए एस्पेक्ट में लॉगिंग लागू करना:

कोई एओपी को डिबगिंग टूल या उपयोगकर्ता-स्तरीय टूल के रूप में सोच सकता है। कमांड उन स्थितियों के लिए आरक्षित होनी चाहिए जहां आप फ़ंक्शन को परिवर्तित कर नहीं सकते (उपयोगकर्ता स्तर) या फ़ंक्शन को उत्पादन कोड (डीबगिंग) में परिवर्तित करना नहीं चाहते हैं।

बिंदु मॉडल से संयोजन
एस्पेक्ट ओरिएंटेड भाषा का कमांड-संबंधित घटक ज्वाइन पॉइंट मॉडल (जेपीएम) को परिभाषित करता है। जेपीएम तीन चीजों को परिभाषित करता है:


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

जॉइन-पॉइंट मॉडल की तुलना जॉइन पॉइंट्स के आधार पर की जा सकती है, जॉइन पॉइंट्स कैसे निर्दिष्ट किए जाते हैं, जॉइन पॉइंट्स पर अनुमत संचालन और संरचनात्मक संवर्द्धन जो व्यक्त किए जा सकते हैं।

अन्य संभावित ज्वाइन पॉइंट मॉडल
अन्य प्रकार के जेपीएम हैं। सभी कमांड भाषाओं को उनके जेपीएम के संदर्भ में परिभाषित किया जा सकता है। उदाहरण के लिए, एकीकृत मॉडलिंग भाषा के लिए काल्पनिक एस्पेक्ट भाषा में निम्नलिखित जेपीएम हो सकते हैं:


 * ज्वाइन पॉइंट सभी मॉडल तत्व हैं।
 * पॉइंटकट कुछ बूलियन एक्सप्रेशन हैं जो मॉडल तत्वों को जोड़ते हैं।
 * इन बिंदुओं पर प्रभाव के साधन सभी मिलान किए गए जुड़ने वाले बिंदुओं का दृश्य है।

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

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

यह आवश्यकता है कि कोई भी संरचनात्मक परिवर्धन मूल वर्ग के साथ संगत हो, जिससे कि सम्मिलिता वर्ग के ग्राहक तब तक काम करते रहें, जब तक कि एओपी कार्यान्वयन सभी ग्राहकों को हर समय नियंत्रित करने की अपेक्षा नहीं करते हैं।

कार्यान्वयन
अंतर्निहित भाषाओं और परिवेशों के आधार पर एओपी प्रोग्राम अन्य प्रोग्रामों को दो अलग-अलग तरीकों से प्रभावित कर सकते हैं:


 * 1) एक संयुक्त फंक्शन तैयार किया जाता है, जो मूल भाषा में मान्य होता है और सामान्य फंक्शन से अंतिम दुभाषिया तक अप्रभेद्य होता है
 * 2) एओपी सुविधाओं को समझने और लागू करने के लिए अंतिम दुभाषिया या पर्यावरण को अद्यतन किया गया है।

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

सिस्टम प्रीप्रोसेसरों का उपयोग करके स्रोत-स्तर की बुनाई को लागू कर सकता है (जैसा कि C ++ मूल रूप से CFront में लागू किया गया था) जिसके लिए प्रोग्राम स्रोत फ़ाइलों तक पहुंच की आवश्यकता होती है। चूंकि, जावा का अच्छी तरह से परिभाषित बाइनरी फॉर्म बायटेकोड बुनकरों को किसी भी जावा प्रोग्राम के साथ .class-file फॉर्म में काम करने में सक्षम बनाता है। बाइटकोड बनाने वालों को निर्माण प्रक्रिया के समय उपयोग में लाए जाने वाले किया जा सकता है या, यदि वर्ग लोडिंग के समय बुनाई मॉडल प्रति-वर्ग है। एस्पेक्टजे ने 2001 में स्रोत-स्तर की बुनाई के साथ प्रारंभ की, 2002 में प्रति-श्रेणी बायटेकोड वीवर दिया, और 2005 में एस्पेक्ट वर्क्ज के एकीकरण के बाद उन्नत लोड-टाइम समर्थन की प्रस्तुति की हैं।

कोई भी समाधान जो प्रोग्राम को रनटाइम पर जोड़ता है उसे ऐसे विचार प्रदान करने होते हैं जो प्रोग्रामर के अलग-अलग मॉडल को बनाए रखने के लिए उन्हें ठीक से अलग करते हैं। एकाधिक स्रोत फ़ाइलों के लिए जावा का बायटेकोड समर्थन किसी भी डिबगर को स्रोत संपादक में ठीक से बुनी गई .class फ़ाइल के माध्यम से आगे बढ़ने में सक्षम बनाता है। चूंकि, कुछ तृतीय-पक्ष डिकंपाइलर बुने हुए कोड को संसाधित नहीं कर सकते हैं क्योंकि वे सभी समर्थित बायटेकोड रूपों के अतिरिक्त जावैक द्वारा निर्मित कोड की अपेक्षा करते हैं (नीचे #Criticism|§ आलोचना भी देखें)।

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

शब्दावली
एस्पेक्ट ओरिएंटेड प्रोग्रामिंग में प्रयुक्त मानक शब्दावली में सम्मिलित हो सकते हैं:

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

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

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

डिजाइनरों ने कोड के पृथक्करण को प्राप्त करने के वैकल्पिक तरीकों पर विचार किया है, जैसे कि C शार्प (प्रोग्रामिंग भाषा) या C# के आंशिक प्रकार, अपितु ऐसे दृष्टिकोणों में परिमाणीकरण तंत्र की कमी होती है जो घोषणात्मक कथन के साथ कोड के कई जुड़ने वाले बिंदुओं तक पहुँचने की अनुमति देता है।

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

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

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

आलोचना
एओपी के प्रभाव की सबसे मौलिक आलोचना यह है कि नियंत्रण प्रवाह अस्पष्ट है, और यह न केवल बहुत बदनाम GOTO से भी बदतर है, बल्कि वास्तव में जोक COME FROM बयान के समान है। एप्लीकेशन की जानकारी न होने पर जो एओपी की कई परिभाषाओं के लिए मौलिक है (प्रश्न में कोड का कोई संकेत नहीं है कि कमांड लागू की जाएगी, जिसे पॉइंटकट में निर्दिष्ट किया गया है), इसका अर्थ है कि कमांड स्पष्ट के विपरीत दिखाई नहीं दे रही है विधि कॉल। उदाहरण के लिए, आओ से फंक्शन की तुलना करें: 5 INPUT X 10 PRINT 'Result is :' 15 PRINT X 20 COME FROM 10 25     X = X * X

30 RETURN

समान शब्दार्थ के साथ एओपी अंश के साथ: main {

input x    print(result(x)) } input result(int x) { return x } around(int x): call(result(int)) && args(x) { int temp = proceed(x) return temp * temp }

इस प्रकार पॉइंटकट रनटाइम स्थिति पर निर्भर हो सकता है और इस प्रकार स्थिर रूप से निर्धारक नहीं हो सकता है। इसे कम किया जा सकता है अपितु स्थिर विश्लेषण और आईडीई समर्थन द्वारा हल नहीं किया जा सकता है जो दिखाता है कि कौन सी कमांड संभावित रूप से मेल खाती है।

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

कार्यान्वयन
निम्नलिखित प्रोग्रामिंग भाषाओं ने एओपी को भाषा के भीतर या बाहरी लाइब्रेरी के रूप में लागू किया है: Afterthought, LOOM.NET , Enterprise Library 3.0 Policy Injection Application Block , AspectDNG , DynamicProxy , Compose* , PostSharp , Seasar.NET , DotSpect (.SPECT) , Spring.NET (as part of its functionality), Wicca and Phx.Morph , SetPoint
 * .नेट फ्रेमवर्क लैंग्वेज (सी शार्प (प्रोग्रामिंग लैंग्वेज)|सी# / विजुअल बेसिक .NET|VB.NET) Numerous:
 * पोस्ट शार्प मुक्त अपितु सीमित संस्करण के साथ वाणिज्यिक एओपी कार्यान्वयन है।
 * एकता एप्लीकेशन ब्लॉक डेटा एक्सेस, सुरक्षा, लॉगिंग, अपवाद हैंडलिंग और अन्य सहित प्रोग्रामिंग के मुख्य क्षेत्रों में सिद्ध प्रथाओं को सुविधाजनक बनाने के लिए एपीआई प्रदान करता है।
 * एस्पेक्ट डीएन एओपी कार्यान्वयन है जो पहलुओं को सीधे .net एक्ज़ीक्यूटेबल फ़ाइलों पर बुनने की अनुमति देता है।
 * एक्शन स्क्रिप्ट
 * स्टाइल (प्रोग्रामिंग भाषा)
 * ऑटो AutoHotkey
 * सी (प्रोग्रामिंग भाषा) / सी ++
 * कोबोल
 * कोको (एपीआई) उद्देश्य सी फ्रेमवर्क
 * कोल्ड फ्यूजन
 * सामान्य लिस्प
 * डेल्फी (प्रोग्रामिंग भाषा)
 * डेल्फी प्रिज्म
 * ई (सत्यापन भाषा) (आईईईई 1647)
 * ईमैक लिस्प
 * ग्रूवी (प्रोग्रामिंग भाषा)
 * हास्केल (प्रोग्रामिंग भाषा)
 * जावा (प्रोग्रामिंग भाषा) Numerous others: CaesarJ, Compose* , Dynaop , JAC , Google Guice (as part of its functionality), Javassist , JAsCo (and AWED) , JAML , JBoss AOP , LogicAJ , Object Teams , PROSE , The AspectBench Compiler for AspectJ (abc) , Spring framework (as part of its functionality), Seasar, The JMangler Project , InjectJ , GluonJ , Steamloom
 * एस्पेक्टजे
 * जावास्क्रिप्ट Many: Advisable, Ajaxpect , jQuery AOP Plugin , Aspectes , AspectJS , Cerny.js , Dojo Toolkit , Humax Web Framework , Joose , Prototype - Prototype Function#wrap , YUI 3 (Y.Do)
 * लोगटॉक (प्रोग्रामिंग भाषा)
 * लुआ (प्रोग्रामिंग भाषा)
 * मेक (सॉफ्टवेयर)
 * मैटलेब
 * एमएल (प्रोग्रामिंग भाषा)
 * नेमर्ले
 * पर्ल
 * पीएचपी
 * प्रोलॉग
 * पायथन (प्रोग्रामिंग भाषा)
 * रैकेट (प्रोग्रामिंग भाषा)
 * रूबी (प्रोग्रामिंग भाषा)
 * स्क्वीक स्मॉलटॉक
 * यूएमएल 2|यूएमएल 2.0
 * एक्सएमएल

यह भी देखें

 * वितरित एओपी
 * विशेषता व्याकरण, औपचारिकता जिसका उपयोग कार्यात्मक प्रोग्रामिंग भाषाओं के शीर्ष पर एस्पेक्ट ओरिएंटेड प्रोग्रामिंग के लिए किया जा सकता है
 * प्रोग्रामिंग ओरिएंटेशन
 * विषय-उन्मुख प्रोग्रामिंग, एस्पेक्ट ओरिएंटेड प्रोग्रामिंग का विकल्प
 * भूमिका-उन्मुख प्रोग्रामिंग, एस्पेक्ट ओरिएंटेड प्रोग्रामिंग का विकल्प
 * विधेय प्रेषण, भूमिका उन्मुख प्रोग्रामिंग का पुराना विकल्प
 * निष्पादन योग्य यूएमएल
 * डेकोरेटर पैटर्न
 * डोमेन संचालित डिजाइन

अग्रिम पठन

 * The paper generally considered to be the authoritative reference for एओपी.
 * Aspect-oriented Software Development and PHP, Dmitry Sheiko, 2006
 * "Adaptive Object-Oriented Programming Using Graph-Based Customization" – Lieberherr, Silva-Lepe, et al. - 1994
 * Wijesuriya, Viraj Brian (2016-08-30) Aspect Oriented Development, Lecture Notes, University of Colombo School of Computing, Sri Lanka
 * Aspect-oriented Software Development and PHP, Dmitry Sheiko, 2006
 * "Adaptive Object-Oriented Programming Using Graph-Based Customization" – Lieberherr, Silva-Lepe, et al. - 1994
 * Wijesuriya, Viraj Brian (2016-08-30) Aspect Oriented Development, Lecture Notes, University of Colombo School of Computing, Sri Lanka
 * "Adaptive Object-Oriented Programming Using Graph-Based Customization" – Lieberherr, Silva-Lepe, et al. - 1994
 * Wijesuriya, Viraj Brian (2016-08-30) Aspect Oriented Development, Lecture Notes, University of Colombo School of Computing, Sri Lanka
 * Wijesuriya, Viraj Brian (2016-08-30) Aspect Oriented Development, Lecture Notes, University of Colombo School of Computing, Sri Lanka
 * Wijesuriya, Viraj Brian (2016-08-30) Aspect Oriented Development, Lecture Notes, University of Colombo School of Computing, Sri Lanka

बाहरी संबंध

 * Eric Bodden's list of एओपी tools in .net framework
 * Aspect-Oriented Software Development, annual conference on एओपी
 * एस्पेक्टजे Programming Guide
 * The AspectBench Compiler for एस्पेक्टजे, another Java implementation
 * Series of IBM developerWorks articles on एओपी
 * A detailed series of articles on basics of aspect-oriented programming and एस्पेक्टजे
 * What is Aspect-Oriented Programming?, introduction with RemObjects Taco
 * Constraint-Specification Aspect Weaver
 * Aspect- vs. Object-Oriented Programming: Which Technique, When?
 * Gregor Kiczales, Professor of Computer Science, explaining एओपी, video 57 min.
 * Aspect Oriented Programming in COBOL
 * Aspect-Oriented Programming in Java with Spring Framework
 * Wiki dedicated to एओपी methods on.NET
 * Early Aspects for Business Process Modeling (An Aspect Oriented Language for BPMN)
 * Spring एओपी and एस्पेक्टजे Introduction
 * AOSD Graduate Course at Bilkent University
 * Introduction to एओपी - Software Engineering Radio Podcast Episode 106
 * An Objective-C implementation of एओपी by Szilveszter Molnar
 * Aspect-Oriented programming for iOS and OS X by Manuel Gebele
 * DevExpress MVVM Framework. Introduction to POCO ViewModels