पहलू आधारित प्रोग्रामिंग: Difference between revisions

From Vigyanwiki
(No difference)

Revision as of 10:26, 25 May 2023

Programming paradigms


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

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

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

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

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

इतिहास

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

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

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

प्रेरणा और मौलिक अवधारणाएँ

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

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

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.
}

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

बिंदु मॉडल से संयोजन

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

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

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

एस्पेक्टजे का ज्वाइन-पॉइंट मॉडल

Main article: एस्पेक्ट जे
  • एस्पेक्टजे में जुड़ने वाले बिंदुओं में विधि या कन्स्ट्रक्टर कॉल या निष्पादन, कक्षा या ऑब्जेक्ट का प्रारंभ, फ़ील्ड पढ़ने और लिखने का उपयोग, अपवाद हैंडलर इत्यादि सम्मिलित हैं। इसमें लूप, सुपर कॉल, फेंक खंड, एकाधिक कथन इत्यादि सम्मिलित नहीं हैं।
  • पॉइंटकट 'आदिम पॉइंटकट डिज़ाइनर' (PCDs) के संयोजन द्वारा निर्दिष्ट किए जाते हैं।

    "किंडेड" पीसीडी एक विशेष प्रकार के जॉइन पॉइंट (जैसे, विधि निष्पादन) से मेल खाते हैं और इनपुट के रूप में जावा-जैसे हस्ताक्षर लेते हैं। ऐसा ही एक पॉइंटकट इस तरह दिखता है: 

     execution(* set*(*))

    यदि विधि नाम से शुरू होता है, तो यह पॉइंटकट विधि-निष्पादन ज्वाइन पॉइंट से मेल खाता है"set" और किसी भी प्रकार का एक ही तर्क है।

    "गतिशील" पीसीडी रनटाइम प्रकारों की जांच करते हैं और वेरिएबल्स को बाइंड करते हैं। उदाहरण के लिए, 

      this(Point)

    यह पॉइंटकट तब मेल खाता है जब वर्तमान में निष्पादित वस्तु वर्ग का एक उदाहरण है Point.ध्यान दें कि जावा के सामान्य प्रकार के लुकअप के माध्यम से कक्षा के अयोग्य नाम का उपयोग किया जा सकता है।

    "स्कोप" PCDs ज्वाइन पॉइंट के लेक्सिकल स्कोप को सीमित करते हैं। उदाहरण के लिए: 

     within(com.company.*)

    यह पॉइंटकट किसी भी प्रकार के किसी भी जॉइन पॉइंट से मेल खाता है com.company पैकेज, * वाइल्डकार्ड का एक रूप है जिसका उपयोग एक हस्ताक्षर से कई चीजों का मिलान करने के लिए किया जा सकता है।

    पॉइंटकट की रचना की जा सकती है और पुन: उपयोग के लिए नामित किया जा सकता है। उदाहरण के लिए: 

     pointcut set() : execution(* set*(*) ) && this(Point) && within(com.company.*);
    यदि विधि नाम से शुरू होता है, तो यह पॉइंटकट विधि-निष्पादन ज्वाइन पॉइंट से मेल खाता है "set" और this प्रकार का उदाहरण है Point में com.company पैकेज रहता हैं। इसे नाम का उपयोग करके संदर्भित किया जा सकता है "set()".
  • यह कमांड एक निश्चित कोड (एक विधि में कोड की तरह निर्दिष्ट) एक ज्वाइन पॉइंट (पॉइंटकट के साथ निर्दिष्ट) पर (पहले, बाद में, या आसपास) चलाने के लिए निर्दिष्ट करती है। जब पॉइंटकट ज्वाइन पॉइंट से मेल खाता है तो एओपी रनटाइम सलाह को स्वचालित रूप से आमंत्रित करता है। उदाहरण के लिए: 
     after() : set() {
   Display.update();
 }
    यह प्रभावी रूप से निर्दिष्ट करता है: "if the set() pointcut matches the join point, run the code Display.update() after the join point completes."

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

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

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

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

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

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

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

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

कार्यान्वयन

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

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

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

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

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

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

शब्दावली

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

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

प्वाइंटकट:

Main article: प्वाइंटकट

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

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

अन्य प्रोग्रामिंग ओरिएंटेशन की तुलना

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

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

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

रीफैक्टरिंग की समस्याएँ

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

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

आलोचना

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

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
}

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

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

कार्यान्वयन

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

यह भी देखें

नोट्स और संदर्भ

  1. ↑ Kiczales, G.; Lamping, J.; Mendhekar, A.; Maeda, C.; Lopes, C.; Loingtier, J. M.; Irwin, J. (1997). पहलू आधारित प्रोग्रामिंग (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. Archived (PDF) from the original on 2016-01-12.
  2. ↑ "Adaptive Object Oriented Programming: The Demeter Approach with Propagation Patterns" Karl Liebherr 1996 ISBN 0-534-94602-X presents a well-worked version of essentially the same thing (Lieberherr subsequently recognized this and reframed his approach).
  3. ↑ Don Box; Chris Sells (4 November 2002). Essential.NET: The common language runtime. Addison-Wesley Professional. p. 206. ISBN 978-0-201-73411-9. Retrieved 4 October 2011.
  4. ↑ Roman, Ed; Sriganesh, Rima Patel; Brose, Gerald (1 January 2005). मास्टरिंग एंटरप्राइज JavaBeans. John Wiley and Sons. p. 285. ISBN 978-0-7645-8492-3. Retrieved 4 October 2011.
  5. ↑ Note: The examples in this article appear in a syntax that resembles that of the Java language.
  6. ↑ "नू.ऑर्ग". www.नू.ऑर्ग. Archived from the original on 24 December 2017. Retrieved 5 May 2018. {{cite web}}: Check |url= value (help)
  7. ↑ "संग्रहीत प्रति" (PDF). Archived from the original (PDF) on 2005-10-08. Retrieved 2005-06-19.
  8. ↑ B. De Win, B. Vanhaute and B. De Decker. "Security through aspect-oriented programming". In Advances in Network and Distributed Systems Security (2002).
  9. ↑ T. Pasquier, J. Bacon and B. Shand. "FlowR: Aspect Oriented Programming for Information Flow Control in Ruby". In ACM Proceedings of the 13th international conference on Modularity (Aspect Oriented Software Development) (2014).
  10. ↑ Edsger Dijkstra, Notes on Structured Programming Archived 2006-10-12 at the Wayback Machine, pg. 1-2
  11. ↑ 11.0 11.1 11.2 11.3 Constantinides, Constantinos; Skotiniotis, Therapon; Störzer, Maximilian (September 2004). AOP को हानिकारक माना जाता है (PDF). European Interactive Workshop on Aspects in Software (EIWAS). Berlin, Germany. Archived (PDF) from the original on 23 March 2016. Retrieved 5 May 2018.
  12. ↑ C2:ComeFrom
  13. ↑ 13.0 13.1 13.2 13.3 13.4 Steimann, F. (2006). "पहलू-उन्मुख प्रोग्रामिंग की विरोधाभासी सफलता". ACM SIGPLAN Notices. 41 (10): 481–497. CiteSeerX 10.1.1.457.2210. doi:10.1145/1167515.1167514., (slides Archived 2016-03-04 at the Wayback Machine,slides 2 Archived 2015-09-23 at the Wayback Machine, abstract Archived 2015-09-24 at the Wayback Machine), Friedrich Steimann, Gary T. Leavens, OOPSLA 2006
  14. ↑ "पहलू-उन्मुख कार्यक्रमों के लिए अधिक मॉड्यूलर तर्क". Archived from the original on 12 August 2015. Retrieved 11 August 2015.
  15. ↑ "एओपी और झूठे की एंटीनोमी" (PDF). fernuni-hagen.de. Archived (PDF) from the original on 9 August 2017. Retrieved 5 May 2018.
  16. ↑ Numerous: Afterthought Archived 2016-03-15 at the Wayback Machine, LOOM.NET Archived 2008-08-27 at the Wayback Machine, Enterprise Library 3.0 Policy Injection Application Block Archived 2007-01-19 at the Wayback Machine, AspectDNG Archived 2004-09-29 at the Wayback Machine, DynamicProxy Archived 2015-12-05 at the Wayback Machine, Compose* Archived 2005-08-21 at Wikiwix, PostSharp Archived 2016-05-03 at the Wayback Machine, Seasar.NET Archived 2006-07-25 at the Wayback Machine, DotSpect (.SPECT) Archived 2006-03-31 at the Wayback Machine, Spring.NET Archived 2006-04-02 at the Wayback Machine (as part of its functionality), Wicca and Phx.Morph Archived 2006-12-07 at the Wayback Machine, SetPoint Archived 2008-10-07 at the Wayback Machine
  17. ↑ "Welcome to as3-commons-bytecode". as3commons.org. Archived from the original on 3 October 2014. Retrieved 5 May 2018.
  18. ↑ "Ada2012 Rationale" (PDF). adacore.com. Archived (PDF) from the original on 18 April 2016. Retrieved 5 May 2018.
  19. ↑ "समारोह हुक". autohotkey.com. Archived from the original on 17 January 2013. Retrieved 5 May 2018.
  20. ↑ Several: AspectC++, FeatureC++, AspectC Archived 2006-08-21 at the Wayback Machine, AspeCt-oriented C Archived 2008-11-20 at the Wayback Machine, Aspicere
  21. ↑ "रास्ते का पत्थर". vub.ac.be. Retrieved 5 May 2018.[permanent dead link]
  22. ↑ "पहलूकोको". neu.edu. Archived from the original on 26 October 2007. Retrieved 5 May 2018.
  23. ↑ "ColdSpring Framework: Welcome". 5 November 2005. Archived from the original on 5 November 2005. Retrieved 5 May 2018.{{cite web}}: CS1 maint: bot: original URL status unknown (link)
  24. ↑ "Closer Project: AspectL". Archived from the original on 23 February 2011. Retrieved 11 August 2015.
  25. ↑ "इंफ्रा - डेल्फी के लिए एकीकृत फ्रेमवर्क - गूगल प्रोजेक्ट होस्टिंग". Archived from the original on 9 September 2015. Retrieved 11 August 2015.
  26. ↑ "meaop - MeSDK: MeObjects, MeRTTI, MeAOP - Delphi AOP(Aspect Oriented Programming), MeRemote, MeService... - Google Project Hosting". Archived from the original on 10 September 2015. Retrieved 11 August 2015.
  27. ↑ "Google प्रोजेक्ट होस्टिंग". Archived from the original on 25 December 2014. Retrieved 11 August 2015.
  28. ↑ "RemObjects सिरस". codegear.com. Archived from the original on 23 January 2012. Retrieved 5 May 2018.
  29. ↑ "Emacs सलाह कार्य". gnu.org. Archived from the original on 24 October 2011. Retrieved 5 May 2018.
  30. ↑ Monads allow program semantics to be altered by changing the type of the program without altering its code: De Meuter, Wolfgang (1997). "Monads As a theoretical basis for AOP". International Workshop on Aspect-Oriented Programming at ECOOP: 25. CiteSeerX 10.1.1.25.8262. Tabareau, Nicolas; Figueroa, Ismael; Tanter, Éric (March 2013). "A Typed Monadic Embedding of Aspects". Proceedings of the 12th Annual International Conference on Aspect-oriented Software Development. Aosd '13: 171–184. doi:10.1145/2451436.2451457. ISBN 9781450317665. S2CID 27256161. Type classes allow additional capabilities to be added to a type: Sulzmann, Martin; Wang, Meng (March 2007). "Aspect-oriented programming with type classes". Proceedings of the 6th Workshop on Foundations of Aspect-oriented Languages: 65–74. doi:10.1145/1233833.1233842. ISBN 978-1595936615. S2CID 3253858..
  31. ↑ Numerous others: CaesarJ Archived 2008-12-19 at the Wayback Machine, Compose* Archived 2005-08-21 at Wikiwix, Dynaop Archived 2007-07-24 at the Wayback Machine, JAC Archived 2004-06-19 at the Wayback Machine, Google Guice (as part of its functionality), Javassist Archived 2004-09-01 at the Wayback Machine, JAsCo (and AWED) Archived 2005-04-11 at the Wayback Machine, JAML Archived 2005-04-15 at the Wayback Machine, JBoss AOP Archived 2006-10-17 at the Wayback Machine, LogicAJ Archived 2006-05-04 at the Wayback Machine, Object Teams Archived 2005-08-31 at the Wayback Machine, PROSE Archived 2007-01-24 at the Wayback Machine, The AspectBench Compiler for AspectJ (abc) Archived 2014-12-16 at the Wayback Machine, Spring framework (as part of its functionality), Seasar, The JMangler Project Archived 2005-10-28 at the Wayback Machine, InjectJ Archived 2005-04-05 at the Wayback Machine, GluonJ Archived 2007-02-06 at the Wayback Machine, Steamloom Archived 2007-08-18 at the Wayback Machine
  32. ↑ Many: Advisable Archived 2008-07-04 at the Wayback Machine, Ajaxpect Archived 2016-07-09 at the Wayback Machine, jQuery AOP Plugin Archived 2008-01-13 at the Wayback Machine, Aspectes Archived 2006-05-08 at Wikiwix, AspectJS Archived 2008-12-16 at the Wayback Machine, Cerny.js Archived 2007-06-27 at the Wayback Machine, Dojo Toolkit Archived 2006-02-21 at the Wayback Machine, Humax Web Framework Archived 2008-12-09 at the Wayback Machine, Joose Archived 2015-03-18 at the Wayback Machine, Prototype - Prototype Function#wrap Archived 2009-05-05 at the Wayback Machine, YUI 3 (Y.Do) Archived 2011-01-25 at the Wayback Machine
  33. ↑ Using built-in support for categories (which allows the encapsulation of aspect code) and event-driven programming (which allows the definition of before and after event handlers).
  34. ↑ "पहलूलुआ". Archived from the original on 17 July 2015. Retrieved 11 August 2015.
  35. ↑ "मकाओ, पुनः (कविता) -इंजीनियरिंग बिल्ड सिस्टम". Archived from the original on 24 July 2012. Retrieved 11 August 2015.
  36. ↑ "मैकलैब". Archived from the original on 24 September 2015. Retrieved 11 August 2015.
  37. ↑ "AspectML - पहलू-उन्मुख कार्यात्मक प्रोग्रामिंग भाषा अनुसंधान". Archived from the original on 5 December 2010. Retrieved 11 August 2015.
  38. ↑ "nemerle/README.md at master · rsdn/nemerle". GitHub. Retrieved 22 March 2018.
  39. ↑ Adam Kennedy. "पहलू - पहलू-उन्मुख प्रोग्रामिंग (एओपी) पर्ल के लिए - metacpan.org". Archived from the original on 31 August 2013. Retrieved 11 August 2015.
  40. ↑ Several: PHP-AOP (AOP.io) Archived 2014-08-18 at Wikiwix, Go! AOP framework Archived 2013-03-01 at the Wayback Machine, PHPaspect Archived 2016-08-22 at the Wayback Machine, Seasar.PHP Archived 2005-12-26 at the Wayback Machine, PHP-AOP, Flow Archived 2018-01-04 at the Wayback Machine, AOP PECL Extension Archived 2017-04-11 at the Wayback Machine
  41. ↑ "bigzaphod.org जल्द ही आ रहा है". www.bigzaphod.org. Archived from the original on 20 April 2016. Retrieved 5 May 2018.
  42. ↑ Several: PEAK Archived 2005-04-09 at the Wayback Machine, Aspyct AOP, Lightweight Python AOP Archived 2004-10-09 at the Wayback Machine, Logilab's aspect module Archived 2005-03-09 at the Wayback Machine, Pythius Archived 2005-04-08 at the Wayback Machine, Spring Python's AOP module Archived 2016-03-04 at the Wayback Machine, Pytilities' AOP module Archived 2011-08-25 at the Wayback Machine, aspectlib Archived 2014-11-05 at the Wayback Machine
  43. ↑ "PLaneT Package Repository : PLaneT > dutchyn > aspectscheme.plt". Archived from the original on 5 September 2015. Retrieved 11 August 2015.
  44. ↑ "AspectR - रूबी में सरल पहलू-उन्मुख प्रोग्रामिंग". Archived from the original on 12 August 2015. Retrieved 11 August 2015.
  45. ↑ Dean Wampler. "घर". Archived from the original on 26 October 2007. Retrieved 11 August 2015.
  46. ↑ "gcao/aspector". GitHub. Archived from the original on 4 January 2015. Retrieved 11 August 2015.
  47. ↑ "पहलू". tu-ilmenau.de. Archived from the original on 6 January 2006. Retrieved 5 May 2018.
  48. ↑ "MetaclassTalk: Reflection and Meta-Programming in Smalltalk". Archived from the original on 29 July 2015. Retrieved 11 August 2015.
  49. ↑ "WEAVR". iit.edu. Archived from the original on 12 December 2008. Retrieved 5 May 2018.
  50. ↑ "AspectXML - एक पहलू-उन्मुख XML वीविंग इंजन (AXLE) - Google प्रोजेक्ट होस्टिंग". Archived from the original on 12 September 2015. Retrieved 11 August 2015.

अग्रिम पठन


बाहरी संबंध

Retrieved from ‘https://www.vigyanwiki.in/index.php?title=पहलू_आधारित_प्रोग्रामिंग&oldid=167768’