एओपी बनाम सुविधाएँ

पहलू ओरिएंटेड प्रोग्रामिंग (एओपी) एक काफी लोकप्रिय प्रोग्रामिंग प्रतिमान है। विकिपीडिया लेख अच्छी तरह से इस दृष्टिकोण के लिए प्रेरणा की व्याख्या करता है।



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

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

@RequireRole(Role.Admin) // clearly visible aspect fun updateUserPermissions(…) { // logic here } 

हालांकि, पठनीयता के संदर्भ में, यह एनोटेशन के बजाय आवश्यकता पद्धति का उपयोग करते हुए, कार्यात्मक दृष्टिकोण से बहुत अलग नहीं है।

अनुवादक का नोट : मूल लेख में, एक कार्यात्मक तरीके या कार्यात्मक दृष्टिकोण में फिर से लिखे जाने पर अभिव्यक्ति का उपयोग किया जाता है, जिसे एक कार्यात्मक दृष्टिकोण या प्रत्यक्ष / विशिष्ट फ़ंक्शन कॉल का उपयोग करके व्याख्या की जा सकती है। लेख में ऐसे उदाहरण हैं जिनकी व्याख्या अलग-अलग तरीकों से की जा सकती है।

बस:

1. भविष्य में, हम हायर-ऑर्डर फ़ंक्शंस की अवधारणा पर लौटेंगे

2. लेख शब्द पहलू का सामना करता है, जो कि अंग्रेजीवाद और AOP पहलू में अवधारणा है

 fun updateUserPermissions(…) { requireRole(Role.Admin) // throws SecurityException // logic here } 

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

अन्य प्रकार के पहलुओं के लिए भी यही सच है, जैसे लेनदेन। दुर्भाग्य से, कार्यात्मक रूप से जावा में अधिक जटिल अवधारणाओं को प्रस्तुत करना बोझिल और असुविधाजनक है, जो जावा पारिस्थितिकी तंत्र में एओपी फ्रेमवर्क की कृत्रिम लोकप्रियता बनाता है।

कोपलिन में, AOP और एनोटेशन का उपयोग करते हुए जावा की तरह लेन-देन के दृष्टिकोण के बजाय:

 @Transactional fun updateUserPermissions(…) { // logic here } 

यह पठनीय भी है और एक कार्यात्मक दृष्टिकोण के साथ एनोटेशन के बिना फिर से लिखे जाने पर साफ दिखता है।

 fun updateUserPermissions(…) = transactional { // logic here } 

इस दृष्टिकोण का लाभ यह है कि आप हमेशा Ctrl / Cmd + दबा सकते हैं अपने IDE में लेनदेन समारोह की घोषणा पर क्लिक करें और तुरंत देखें कि यह वास्तव में क्या करता है। जो आमतौर पर इस्तेमाल किए जाने वाले एओपी ढांचे में से किसी के साथ संभव नहीं है। यहां तक ​​कि जब आईडीई प्लगइन का उपयोग करके पहलू कोड पर नेविगेशन प्रदान किया जाता है, तो उसके तर्क के डिक्रिप्शन को एक अलग बहुक्रियाशील एपीआई और / या सम्मेलनों के ज्ञान की आवश्यकता होती है।

दुर्भाग्य से, कोटलिन में एओपी एनोटेशन को बदलने के तरीके को स्केल करने में समस्याएं हैं। मामले के लिए जब घुंघराले ब्रेसिज़ और इंडेंट के संचय के साथ एक ही फ़ंक्शन पर कई पहलू लागू होते हैं:

 fun updateUserPermissions(…) = logged { transactional { // logic here } } 

वर्कअराउंड कई पहलुओं को लागू करते समय स्वीकार्य कोड को संरक्षित करने के लिए एक उच्च-क्रम फ़ंक्शन बनाने के लिए है:

 fun updateUserPermissions(…) = loggedTransactional { // logic here } 

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

 fun updateUserPermissions(params: Params) = logged("updateUserPermissions($params)") { // logic here } 

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

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

अनुवादक नोट :
1. मध्यम (संलग्न) पर अनुच्छेद ।
2. मूल लेख के लेखक रोमन एलिसैरोव (टीम लीड जेटब्रेन्स, कोटलिन कोरटाइन और लिबास पर काम कर रहे हैं, स्पोर्ट्स प्रोग्रामिंग / आईसीपीसी, कंसीडर और एल्गोरिदम, गणित / मात्रात्मक वित्त; पूर्व में डेवेक्सपर्ट्स)। हबर एलिज़ारोव पर