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

From Vigyanwiki


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

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

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

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

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

इतिहास

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

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

Microsoft Transaction Server को AOP का पहला प्रमुख एप्लिकेशन माना जाता है, जिसके बाद Enterprise JavaBeans आता है।[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.
}

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

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

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

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

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

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|§ आलोचना भी देखें)।

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

शब्दावली

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

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

प्वाइंटकट:

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

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

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

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

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

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

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

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

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

आलोचना

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

5 इनपुट एक्स

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

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

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

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

}

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

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

कार्यान्वयन

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


यह भी देखें

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

  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.

अग्रिम पठन


बाहरी संबंध