इसका एक अच्छा उदाहरण क्या है cross-cutting concern? विकिपीडिया पृष्ठ पर मेडिकल रिकॉर्ड उदाहरण मुझे अधूरा लगता है।
विशेष रूप से इस उदाहरण से, लॉगिंग कोड डुप्लिकेट ( बिखरने ) की ओर क्यों ले जाएगा ? (साधारण कॉल जैसे log("....")हर जगह, जो एक बड़ी बात नहीं लगती)।
A core concernऔर a के बीच क्या अंतर है cross-cutting concern?
मेरा अंतिम लक्ष्य AOP की बेहतर समझ प्राप्त करना है।
जवाबों:
समझने से पहले Crosscutting चिंता है, हम समझना होगा चिंता ।
एक चिंता एक शब्द है जो कार्यक्षमता के आधार पर विभाजित प्रणाली के एक हिस्से को संदर्भित करता है।
चिंताएँ दो प्रकार की होती हैं:
यह आंकड़ा एक विशिष्ट एप्लिकेशन का प्रतिनिधित्व करता है जो मॉड्यूल में टूट गया है। प्रत्येक मॉड्यूल की मुख्य चिंता अपने विशेष डोमेन के लिए सेवाएं प्रदान करना है। हालाँकि, इनमें से प्रत्येक मॉड्यूल को समान सहायक क्रियाओं की भी आवश्यकता होती है, जैसे कि सुरक्षा लॉगिंग और लेनदेन प्रबंधन। क्रॉसकिटिंग चिंताओं का एक उदाहरण "लॉगिंग" है, जिसे अक्सर ट्रेसिंग मेथड कॉल द्वारा डिबगिंग की सहायता के लिए वितरित अनुप्रयोगों में उपयोग किया जाता है। मान लीजिए कि हम प्रत्येक फ़ंक्शन बॉडी की शुरुआत और अंत दोनों पर लॉगिंग करते हैं। यह उन सभी वर्गों को पार करने का परिणाम देगा जिनके पास कम से कम एक फ़ंक्शन है।
मुझे लगता है कि क्रॉस-कटिंग चिंता का एकमात्र सबसे अच्छा उदाहरण व्यवहार व्यवहार है। उदाहरण के लिए, आपके सभी सेवा विधियों में कमिट और रोलबैक कॉल के साथ ट्राई-कैच ब्लॉक रखना, उदाहरण के लिए विकर्षक होगा। एक मार्कर के साथ तरीकों का उल्लेख करना जो AOP उन्हें वांछित लेनदेन व्यवहार के साथ एनकैप्सुलेट करने के लिए उपयोग कर सकता है, एक बड़ी जीत है।
क्रॉस-कटिंग चिंता का एक और अच्छा उम्मीदवार प्राधिकरण है। एक मार्कर के साथ एक सेवा पद्धति की व्याख्या करना जो बताता है कि कौन इसे कॉल कर सकता है, और कुछ AOP सलाह दे सकता है कि विधि को कॉल करने की अनुमति दे या नहीं, सेवा पद्धति कोड में इसे संभालने के लिए बेहतर हो सकता है।
एओपी सलाह के साथ लॉगिंग को लागू करना अधिक लचीलापन प्राप्त करने का एक तरीका हो सकता है, ताकि आप लॉगपॉइंट को बदलकर जो भी लॉग इन करते हैं उसे बदल सकें। व्यवहार में, मैं ऐसी परियोजनाओं को अक्सर नहीं देखता हूँ। आमतौर पर Log4j जैसी लाइब्रेरी का उपयोग करने से आप लॉग-लेवल और श्रेणी के आधार पर फ़िल्टर कर सकते हैं, यदि आपको जरूरत है तो रनटाइम के दौरान, यह काफी अच्छी तरह से काम करता है।
एक मुख्य चिंता एक कारण है कि आवेदन मौजूद है, व्यापार तर्क है कि आवेदन स्वचालित है। यदि आपके पास एक लॉजिस्टिक्स एप्लिकेशन है जो शिपिंग फ्रेट को संभालता है, तो यह पता लगाना कि आप ट्रक पर कितना माल पैक कर सकते हैं या ट्रक के लिए सबसे अच्छा रास्ता क्या है कि इसकी डिलीवरी बंद हो जाए। क्रॉस-कटिंग चिंताएं आमतौर पर कार्यान्वयन विवरण हैं जिन्हें व्यावसायिक तर्क से अलग रखने की आवश्यकता होती है।
स्वीकृत उत्तर के अलावा मैं एक और उदाहरण के लिए एक क्रॉस-कटिंग चिंता का उल्लेख करना चाहता हूं: रीमोटिंग। कहो कि मैं अपने पारिस्थितिक तंत्र में अन्य घटकों को स्थानीय रूप से कॉल करना चाहता हूं जैसे कि वे प्रक्रिया में चल रहे थे। शायद कुछ मामलों में वे भी करते हैं। लेकिन अब मैं अपनी सेवाओं को क्लाउड या क्लस्टर में वितरित करना चाहता हूं। मुझे एप्लिकेशन डेवलपर के रूप में इस पहलू की परवाह क्यों करनी चाहिए? एक पहलू यह पता लगाने का ध्यान रख सकता है कि किसे कॉल करना है और कैसे, यदि आवश्यक हो और एक दूरस्थ कॉल कर रहा है, तो प्रसारित डेटा को प्रसारित करना। यदि सब कुछ प्रक्रिया में चल रहा था तो पहलू स्थानीय कॉल को आगे बढ़ाएगा। कैलली पक्ष पर पहलू डेटा को डिस्क्राइबलाइज करेगा, स्थानीय कॉल करेगा और परिणाम लौटाएगा।
अब मैं आपको लॉग आउटपुट के बारे में "तुच्छ" चीजों के बारे में एक छोटी सी कहानी बताता हूं: कुछ हफ्ते पहले मैंने एक क्लाइंट के लिए एक जटिल, लेकिन बहुत बड़े कोड बेस (कोड के 250K लाइनों) के बारे में नहीं बताया। कुछ सौ वर्गों में एक प्रकार की लॉगिंग रूपरेखा का उपयोग किया गया था, कुछ अन्य सौ में। तब कई हजार लाइनें थींSystem.out.println(*)जहां वास्तव में लॉग आउटपुट होना चाहिए था। इसलिए मैंने कोड बेस में बिखरी हजारों लाइनों को ठीक करने के साथ समाप्त किया। सौभाग्य से मैं पूरी कार्रवाई को गति देने के लिए IntelliJ IDEA (संरचनात्मक खोज और प्रतिस्थापन) में कुछ चतुर चाल का उपयोग कर सकता था, लेकिन लड़का आपको नहीं लगता कि यह तुच्छ था! यकीन है, दृढ़ता से संदर्भ-निर्भर डिबग लॉगिंग हमेशा एक विधि निकाय के भीतर होगी, लेकिन कई महत्वपूर्ण प्रकार की लॉगिंग जैसे ट्रेसिंग विधि कॉल (यहां तक कि एक अच्छी तरह से इंडेंट आउटपुट के साथ पदानुक्रम), दोनों संभाला या अखंडित अपवाद लॉगिंग, उपयोगकर्ता ऑडिटिंग (कॉलिंग लॉगिंग) उपयोगकर्ता भूमिकाओं पर आधारित प्रतिबंधित तरीके) और इसके बाद स्रोत कोड को प्रदूषित किए बिना आसानी से पहलुओं में लागू किया जा सकता है। रोजमर्रा के एप्लिकेशन डेवलपर को इसके बारे में सोचने की जरूरत नहीं है या यहां तक कि कोड बेस पर बिखरे हुए लकड़हारा कॉल को भी देखने की जरूरत नहीं है।
मैं अन्य क्रॉस-कटिंग चिंताओं के लिए इसी तरह के स्पष्टीकरण के साथ आ सकता हूं। कोड को साफ और बिखराव से मुक्त रखना और आईएमओ व्यावसायिकता का विषय है, वैकल्पिक कुछ भी नहीं। अंतिम लेकिन कम से कम यह कोड को पठनीय, बनाए रखने योग्य, अपूरणीय नहीं रखता है। तथास्तु।
क्रॉस कटिंग चिंताएं ऐसे परिदृश्य हैं जो हमेशा आवेदन के प्रकार के बावजूद मौजूद होने चाहिए।
उदाहरण के लिए, लॉगिंग, सुरक्षा, प्रदर्शन रूपरेखा, स्थानीयकरण, पहुंच, लेन-देन इत्यादि। सॉफ्टवेयर के बावजूद हम लॉगिंग कर रहे हैं (अन्यथा कोई कैसे डिबग करेगा या ठेस डेटा से कुछ प्रासंगिक जानकारी प्राप्त करेगा)। सुरक्षा (प्रमाणीकरण / प्राधिकरण आदि) की आवश्यकता है, जहां केवल प्रामाणिक उपयोगकर्ता विशेषाधिकार के सही सेट के साथ आवेदन में प्रवेश कर सकते हैं। हमें यह जानने की आवश्यकता है कि आपका आवेदन कैसे प्रदर्शन करता है तो हमें प्रोफाइलिंग करने की आवश्यकता है। यदि आवेदन अंतर्राष्ट्रीय उपयोगकर्ताओं द्वारा उपयोग किया जाता है (अपनी स्थानीय भाषा के साथ), तो हमें आवेदन में उसी का समर्थन करने की आवश्यकता है। अक्षमता हमारे आवेदन का उपयोग करने के लिए अक्षम लोगों के लिए प्रयोज्य मामले हैं।
अब चाहे हमारा आवेदन डेस्कटॉप आधारित हो, वेब आधारित आदि, यदि इसे उत्पादन परिवेश में भूगोल के अंत उपयोगकर्ताओं द्वारा उपयोग करने की आवश्यकता है तो क्रॉस कट की आवश्यकता है। अब तक मैंने इस बारे में कुछ भी नहीं कहा है कि आवेदन आदि के बारे में क्या है, लेकिन उन चिंताओं की सूची दी है, जिन्हें उत्पादन वातावरण में उपयोगकर्ताओं को समाप्त करने से पहले इसे संबोधित किया जाना चाहिए। और यह सब क्रॉस कट चिंताओं के बारे में है (जिसे विभिन्न स्तरों पर सभी अनुप्रयोगों / विधियों / कक्षाओं द्वारा नियंत्रित किया जाना चाहिए)।