एओपी बनाम कार्य

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

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

@RequireRole (भूमिका.एडमिन) // स्पष्ट रूप से दिखाई देने वाला पहलू
मजेदार अपडेटउपयोगकर्ता (…) {
    // यहाँ तर्क
}

हालाँकि, पठनीयता के दृष्टिकोण से, यह @RequireRole एनोटेशन के बजाय आवश्यकता फ़ंक्शन का उपयोग करके एक ही समस्या के लिए एक कार्यात्मक दृष्टिकोण से बहुत अलग नहीं है:

मजेदार अपडेटउपयोगकर्ता (…) {
    आवश्यकता होती है (भूमिका। भूमिका) // फेंकता SecurityException
    // यहाँ तर्क
}

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

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

हालांकि कोटलिन के साथ ऐसा नहीं है। कोपलिन में, AOP के साथ लेन-देन के लिए जावा की तरह दृष्टिकोण के बजाय और इस तरह एनोटेशन:

@Transactional
मजेदार अपडेटउपयोगकर्ता (…) {
    // यहाँ तर्क
}

कार्यात्मक रूप में दोबारा लिखे जाने पर यह उतना ही पठनीय और साफ-सुथरा होता है:

मजेदार अपडेटउपयोगकर्ता (…) = लेन-देन {
    // यहाँ तर्क
}

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

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

मजेदार अपडेटउपयोगकर्ता (…) = लॉग इन {
    लेन-देन {
        // यहाँ तर्क
    }
}

काम-के आसपास कई पहलुओं के उपयोग-स्थल को साफ-सुथरा रखने के लिए एक संयुक्त उच्च-क्रम फ़ंक्शन बनाने के लिए है:

मजेदार अपडेटउपयोगकर्ता (…) = लॉगऑनसैशनल {
    // यहाँ तर्क
}

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

मजेदार अपडेटउपयोगकर्ता (params: Params) =
    लॉग इन किया गया ("अपडेटउपकरणों ($ params)") {
        // यहाँ तर्क
    }

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

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