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

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

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

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

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

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

इतिहास

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

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

Microsoft Transaction Server को AOP का पहला प्रमुख एप्लिकेशन माना जाता है, जिसके बाद Enterprise JavaBeans आता है।

प्रेरणा और बुनियादी अवधारणाएँ

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

उदाहरण के लिए, खाते से दूसरे खाते में राशि स्थानांतरित करने के लिए अवधारणात्मक रूप से बहुत ही सरल विधि के साथ बैंकिंग एप्लिकेशन पर विचार करें:

void transfer(Account fromAcc, Account toAcc, int amount) throws Exception {
  if (fromAcc.getBalance() < amount)
      throw new InsufficientFundsException();

  fromAcc.withdraw(amount);
  toAcc.deposit(amount);
}

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

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

void transfer(Account fromAcc, Account toAcc, int amount, User user,
    Logger logger, Database database) throws Exception {
  logger.info("Transferring money...");
  
  if (!isUserAuthorised(user, fromAcc)) {
    logger.info("User has no permission.");
    throw new UnauthorisedUserException();
  }
  
  if (fromAcc.getBalance() < amount) {
    logger.info("Insufficient funds.");
    throw new InsufficientFundsException();
  }

  fromAcc.withdraw(amount);
  toAcc.deposit(amount);

  database.commitChanges();  // Atomic operation.

  logger.info("Transaction successful.");
}

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

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

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

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

aspect Logger {
  void Bank.transfer(Account fromAcc, Account toAcc, int amount, User user, Logger logger)  {
    logger.info("Transferring money...");
  }

  void Bank.getMoneyBack(User user, int transactionId, Logger logger)  {
    logger.info("User requested money back.");
  }

  // Other crosscutting code.
}

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

बिंदु मॉडल से जुड़ें

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

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

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

AspectJ का ज्वाइन-पॉइंट मॉडल

Main article: AspectJ

• The join points in AspectJ include method or constructor call or execution, the initialization of a class or object, field read and write access, exception handlers, etc. They do not include loops, super calls, throws clauses, multiple statements, etc.
• Pointcuts are specified by combinations of primitive pointcut designators (PCDs).

  "Kinded" PCDs match a particular kind of join point (e.g., method execution) and tend to take as input a Java-like signature. One such pointcut looks like this:

   execution(* set*(*))
  

  This pointcut matches a method-execution join point, if the method name starts with "set" and there is exactly one argument of any type.

  "Dynamic" PCDs check runtime types and bind variables. For example,

    this(Point)
  

  This pointcut matches when the currently executing object is an instance of class Point. Note that the unqualified name of a class can be used via Java's normal type lookup.

  "Scope" PCDs limit the lexical scope of the join point. For example:

   within(com.company.*)
  

  This pointcut matches any join point in any type in the com.company package. The * is one form of the wildcards that can be used to match many things with one signature.

  Pointcuts can be composed and named for reuse. For example:

   pointcut set() : execution(* set*(*) ) && this(Point) && within(com.company.*);
  

  This pointcut matches a method-execution join point, if the method name starts with "set" and this is an instance of type Point in the com.company package. It can be referred to using the name "set()".
• Advice specifies to run at (before, after, or around) a join point (specified with a pointcut) certain code (specified like code in a method). The AOP runtime invokes Advice automatically when the pointcut matches the join point. For example:

   after() : set() {
     Display.update();
   }
  

  This effectively specifies: "if the set() pointcut matches the join point, run the code Display.update() after the join point completes."

अन्य संभावित ज्वाइन पॉइंट मॉडल

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

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

अंतर-प्रकार की घोषणाएं

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

  aspect DisplayUpdate {
    void Point.acceptVisitor(Visitor v) {
      v.visit(this);
    }
    // other crosscutting code...
  }

यह कोड स्निपेट जोड़ता है acceptVisitor विधि को Point कक्षा।

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

कार्यान्वयन

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

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

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

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

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

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

शब्दावली

पहलू-उन्मुख प्रोग्रामिंग में प्रयुक्त मानक शब्दावली में शामिल हो सकते हैं:

फिल्म आदि में दृश्यों के संपादन संबंधी चिंताएं

Main article: Cross-cutting concern

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

सलाह

Main article: Advice (programming)

यह वह अतिरिक्त कोड है जिसे आप अपने मौजूदा मॉडल पर लागू करना चाहते हैं। हमारे उदाहरण में, यह लॉगिंग कोड है जिसे हम तब लागू करना चाहते हैं जब थ्रेड किसी विधि में प्रवेश करता है या बाहर निकलता है।

प्वाइंटकट:

Main article: Pointcut

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

पहलू

Main article: Aspect (computer science)

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

अन्य प्रोग्रामिंग प्रतिमानों की तुलना

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

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

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

गोद लेने के मुद्दे

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

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

आलोचना

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

5 इनपुट एक्स

10 प्रिंट 'परिणाम है:' 15 प्रिंट एक्स 20 10 से आते हैं 25 एक्स = एक्स * एक्स 30 वापसी </वाक्यविन्यास हाइलाइट> समान शब्दार्थ के साथ AOP अंश के साथ: <वाक्यविन्यास प्रकाश लैंग = जावा हाइलाइट = 8> मुख्य() {

 इनपुट एक्स
 प्रिंट (परिणाम (एक्स))

} इनपुट परिणाम (int x) {वापसी x} चारों ओर (int x): कॉल (परिणाम (int)) && तर्क (x) {

 इंट टेम्प = आगे बढ़ना (एक्स)
 वापसी अस्थायी * अस्थायी

}

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

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

कार्यान्वयन

निम्नलिखित प्रोग्रामिंग भाषाओं ने AOP को भाषा के भीतर या बाहरी पुस्तकालय के रूप में लागू किया है:

• .नेट फ्रेमवर्क लैंग्वेज (सी शार्प (प्रोग्रामिंग लैंग्वेज)|सी# / विजुअल बेसिक .NET|VB.NET)
  • PostSharp मुक्त लेकिन सीमित संस्करण के साथ वाणिज्यिक एओपी कार्यान्वयन है।
  • एकता आवेदन ब्लॉक डेटा एक्सेस, सुरक्षा, लॉगिंग, अपवाद हैंडलिंग और अन्य सहित प्रोग्रामिंग के मुख्य क्षेत्रों में सिद्ध प्रथाओं को सुविधाजनक बनाने के लिए एपीआई प्रदान करता है।
  • AspectDN AOP कार्यान्वयन है जो पहलुओं को सीधे .net एक्ज़ीक्यूटेबल फ़ाइलों पर बुनने की अनुमति देता है।
• ActionScript
• अदा (प्रोग्रामिंग भाषा)
• ऑटो AutoHotkey
• सी (प्रोग्रामिंग भाषा) / सी ++
• कोबोल
• कोको (एपीआई) उद्देश्य सी फ्रेमवर्क
• ठंडा गलन
• सामान्य लिस्प
• डेल्फी (प्रोग्रामिंग भाषा)
• डेल्फी प्रिज्म
• ई (सत्यापन भाषा) (आईईईई 1647)
• Emacs लिस्प
• ग्रूवी (प्रोग्रामिंग भाषा)
• हास्केल (प्रोग्रामिंग भाषा)
• जावा (प्रोग्रामिंग भाषा)
  • पहलूजे
• जावास्क्रिप्ट
• लोगटॉक (प्रोग्रामिंग भाषा)
• लुआ (प्रोग्रामिंग भाषा)
• बनाना (सॉफ्टवेयर)
• मतलब
• एमएल (प्रोग्रामिंग भाषा)
• नेमर्ले
• पर्ल
• पीएचपी
• प्रोलॉग
• पायथन (प्रोग्रामिंग भाषा)
• रैकेट (प्रोग्रामिंग भाषा)
• रूबी (प्रोग्रामिंग भाषा)
• चीख़ स्मॉलटॉक
• यूएमएल 2|यूएमएल 2.0
• एक्सएमएल

यह भी देखें

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

अग्रिम पठन

• Kiczales, G.; Lamping, J.; Mendhekar, A.; Maeda, C.; Lopes, C.; Loingtier, J. M.; Irwin, J. (1997). Aspect-oriented programming (PDF). ECOOP'97. Proceedings of the 11th European Conference on Object-Oriented Programming. LNCS. Vol. 1241. pp. 220–242. CiteSeerX 10.1.1.115.8660. doi:10.1007/BFb0053381. ISBN 3-540-63089-9. The paper generally considered to be the authoritative reference for AOP.
• Robert E. Filman; Tzilla Elrad; Siobhán Clarke; Mehmet Aksit (2004). Aspect-Oriented Software Development. ISBN 978-0-321-21976-3.
• Renaud Pawlak, Lionel Seinturier & Jean-Philippe Retaillé (2005). Foundations of AOP for J2EE Development. ISBN 978-1-59059-507-7.
• Laddad, Ramnivas (2003). AspectJ in Action: Practical Aspect-Oriented Programming. ISBN 978-1-930110-93-9.
• Jacobson, Ivar; Pan-Wei Ng (2005). Aspect-Oriented Software Development with Use Cases. ISBN 978-0-321-26888-4.
• Aspect-oriented Software Development and PHP, Dmitry Sheiko, 2006
• Siobhán Clarke & Elisa Baniassad (2005). Aspect-Oriented Analysis and Design: The Theme Approach. ISBN 978-0-321-24674-5.
• Raghu Yedduladoddi (2009). Aspect Oriented Software Development: An Approach to Composing UML Design Models. ISBN 978-3-639-12084-4.
• "Adaptive Object-Oriented Programming Using Graph-Based Customization" – Lieberherr, Silva-Lepe, et al. - 1994
• Zambrano Polo y La Borda, Arturo Federico (5 June 2013). "Addressing aspect interactions in an industrial setting: experiences, problems and solutions": 159. doi:10.35537/10915/35861. Retrieved 30 May 2014. {{cite journal}}: Cite journal requires |journal= (help)
• Wijesuriya, Viraj Brian (2016-08-30) Aspect Oriented Development, Lecture Notes, University of Colombo School of Computing, Sri Lanka
• Groves, Matthew D. (2013). AOP in .NET. ISBN 9781617291142.

बाहरी संबंध

• Eric Bodden's list of AOP tools in .net framework
• Aspect-Oriented Software Development, annual conference on AOP
• AspectJ Programming Guide
• The AspectBench Compiler for AspectJ, another Java implementation
• Series of IBM developerWorks articles on AOP
• Laddad, Ramnivas (January 18, 2002). "I want my AOP!, Part 1". JavaWorld. Retrieved 2020-07-20. A detailed series of articles on basics of aspect-oriented programming and AspectJ
• 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 AOP, video 57 min.
• Aspect Oriented Programming in COBOL Archived 2008-12-17 at the Wayback Machine
• Aspect-Oriented Programming in Java with Spring Framework
• Wiki dedicated to AOP methods on.NET
• Early Aspects for Business Process Modeling (An Aspect Oriented Language for BPMN)
• Spring AOP and AspectJ Introduction
• AOSD Graduate Course at Bilkent University
• Introduction to AOP - Software Engineering Radio Podcast Episode 106
• An Objective-C implementation of AOP by Szilveszter Molnar
• Aspect-Oriented programming for iOS and OS X by Manuel Gebele
• DevExpress MVVM Framework. Introduction to POCO ViewModels