पहलू उन्मुख प्रोग्रामिंग के अलावा क्रॉस कटिंग चिंताओं के लिए क्या विकल्प हैं? [बन्द है]

Question

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

Comments

विज़िटर पैटर्न बहुत सारी स्थितियों से निपट सकता है जो अब AOP के माध्यम से हल की जाती हैं।

— स्टीवन एवर्स

@SnOrfus: नीचे मेरी प्रतिक्रिया भी देखें, जहां मैं जावा के लिए डीजे लाइब्रेरी के बारे में बात करता हूं: विज़िटर पैटर्न का उपयोग करने का एक गतिशील तरीका! जांच करने लायक। (यह भी एक सामान्य तकनीक है जिसका उपयोग आप रिफ्लेक्शन के साथ अपने दम पर कर सकते हैं।)

— मेकनील

Answer 1

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

यह हमेशा सुरुचिपूर्ण ढंग से काम नहीं करता है, हालांकि। यही कारण है कि लोग इस मुद्दे को AOP जैसी चीजों से संबोधित करने की कोशिश कर रहे हैं।

Answer 2

दो अन्य विकल्प जिन्हें मैंने अभी तक नहीं देखा है:

मोनाड्स और एरो के साथ कार्यात्मक प्रोग्रामिंग

FP में आप किसी और चीज़ की तरह क्रॉस-कटिंग चिंता का प्रतिनिधित्व करते हैं: जैसे कि आप किसी फ़ंक्शन कॉल पर पास होते हैं। चूंकि ऐसा करने से स्पष्ट रूप से थकाऊ हो जाता है, आप अतिरिक्त जानकारी को छिपाने के लिए मोनाड्स (या शायद तीर) का उपयोग कर सकते हैं।

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

इकाई / घटक-आधारित प्रोग्रामिंग

कुछ मैं एक खेल इंजन के लिए शोध और प्रयोग कर रहा हूं। OOP की तरह "ऑब्जेक्ट" के बजाय, आप सब कुछ डेटा (घटकों) और सेवाओं के पैकेट में विघटित करते हैं जो एक प्रकार के घटक पर काम करते हैं। घटक सामान्य आईडी द्वारा एक साथ समूहीकृत किए जाते हैं, जैसे एक संबंधपरक डेटाबेस में, और लिंक किए गए घटकों के समूह निकाय हैं। इस तरह की प्रणाली में लॉगिंग जोड़ने के लिए, आप एक नई लॉगिंग सेवा जोड़ेंगे जो ट्रिगर पर आधारित है जिसके माध्यम से घटकों को पारित किया जाता है।

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

Comments

जब आप मोनाड्स और एरो के बारे में बात करते हैं, तो आपको एपेरेटिव फंडर्स का उल्लेख करना चाहिए।

— वाको

Answer 3

क्रॉसकटिंग चिंताओं की समस्याओं से निपटने के कई तरीके हैं:

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

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

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

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

• जनरेटिंग प्रोग्रामिंग तकनीकों का उपयोग करें : मेटा स्तर तक कदम रखने को पहलू-उन्मुख प्रोग्रामिंग के लिए एक कार्यान्वयन तकनीक माना जा सकता है, लेकिन यह एक बड़ा पर्याप्त क्षेत्र है जो सरल पहलुओं को स्थानांतरित करता है। जनन तकनीक (जहां एक प्रोग्राम दूसरे प्रोग्राम के लिए सोर्स कोड बनाता है) भी डोमेन-विशिष्ट भाषाओं से संबंधित हैं।

इन सभी के लिए, मुझे लगता है कि एओपी का अध्ययन करना उचित है। AOP आपको कोड की अपनी अवधारणाओं का विस्तार करने में मदद कर सकता है, भले ही आप AOP भाषा का उपयोग न करें।

Answer 4

एक घोषित सुविधा के साथ सामान्य टैगिंग कोड तत्वों में, लेकिन विशेष रूप से C # /। NET / मोनो दुनिया में विशेषता प्रणाली।

Comments

क्या आप अधिक विशिष्ट हो सकते हैं? आप क्या वर्णन करते हैं कि कुछ एओपी सिस्टम कैसे काम करते हैं।

— स्टीवन एवर्स

यह बहुत AOP है।

— मैट एच

अपने विशिष्ट / शास्त्रीय अर्थों में AOP को बड़े पैमाने पर करने के लिए एक सहायक उपकरण (एक पहलू बुनाई IDE) की आवश्यकता होती है। AOP प्राथमिक स्रोत कोड से कोड के बारे में तर्क करना कठिन बनाता है। जब आपके कार्यक्रम को पहलू लाश द्वारा घुसपैठ की जाती है, तो आपके घटकों के व्यवहार की भविष्यवाणी करना कठिन होता है। विशेषताएँ या टैग समान कार्यक्षमता प्रदान करते हैं लेकिन स्रोत कोड में स्पष्ट प्रतिनिधित्व के साथ।

ध्यान दें कि मेरा मुद्दा उन समस्याओं के साथ बिल्कुल नहीं है जो एओपी तरीका हल करता है। मेरी एकमात्र चिंता यह है कि AOP के साथ, मेरा स्रोत कोड मेरे कार्यक्रम के व्यवहार की भविष्यवाणी करने के लिए पर्याप्त स्रोत नहीं है।

@ मुमताज: मैं देख सकता हूं कि जब पूरे नेमस्पेस पर पहलुओं को लागू किया जाता है तो यह कैसा होगा। एओपी की दूसरी विधि: जिम्मेदार तरीके / गुण / आदि। उस पहलू को लागू करने के लिए, जो आप वर्णन करते हैं, उसके समान है।

— स्टीवन एवर्स

Answer 5

मैं एओपी पर कोई विशेषज्ञ नहीं हूं, लेकिन वर्षों से इसके बारे में पढ़ने से, यह हमेशा लिस्प द्वारा पेश किए गए मेटाप्रोग्रामिंग के एक कमजोर रूप की तरह लग रहा है , विशेष रूप से इसके मेटाबोजेक्ट प्रोटोकॉल जैसे भागों।

मुझे आश्चर्य नहीं होना चाहिए, मुझे लगता है: ग्रेगोर किस्केल्स एएमओपी के लेखकों में से एक थे, और बाद में जावा के लिए एस्पेक्टज लिखा!