design patterns - क्रॉस कटिंग चिंता उदाहरण




design-patterns aop (2)

मुझे लगता है कि एक क्रॉस-कटिंग चिंता का एकमात्र सबसे अच्छा उदाहरण लेनदेन संबंधी व्यवहार है। उदाहरण के लिए, आपकी सभी सेवा विधियों में प्रतिबद्ध और रोलबैक कॉल के साथ प्रयास-पकड़ ब्लॉक डालना होगा, उदाहरण के लिए। एक मार्कर के साथ विधियों की व्याख्या करना कि एओपी वांछित लेनदेन व्यवहार के साथ उन्हें encapsulate करने के लिए उपयोग कर सकते हैं एक बड़ी जीत है।

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

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

एक मुख्य चिंता एक कारण है कि आवेदन मौजूद है, व्यवसाय तर्क है कि एप्लिकेशन स्वचालित करता है। यदि आपके पास एक रसद अनुप्रयोग है जो शिपिंग माल ढुलाई करता है, यह पता लगाता है कि आप ट्रक पर कितना माल पैक कर सकते हैं या ट्रक के वितरण के लिए ट्रक के लिए सबसे अच्छा मार्ग क्या है, यह मुख्य चिंता हो सकती है। क्रॉस-कटिंग चिंताओं आमतौर पर कार्यान्वयन विवरण होते हैं जिन्हें व्यावसायिक तर्क से अलग रखा जाना चाहिए।

एक cross-cutting concern का एक अच्छा उदाहरण क्या है? wikipedia पेज पर मेडिकल रिकॉर्ड उदाहरण मेरे लिए अधूरा लगता है।

विशेष रूप से इस उदाहरण से, लॉगिंग कोड कोड डुप्लिकेशन ( स्कैटरिंग ) क्यों ले जाएगी? (सरल कॉल के अलावा log("....") हर जगह, जो एक बड़े सौदे की तरह प्रतीत नहीं होता है)।

core concern और cross-cutting concern बीच क्या अंतर cross-cutting concern ?

मेरा अंत लक्ष्य एओपी की बेहतर समझ प्राप्त करना है।


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

अब मैं आपको लॉग आउटपुट जैसी "छोटी" चीजों के बारे में एक छोटी सी कहानी बताता हूं: कुछ हफ्ते पहले मैंने एक जटिल, लेकिन बहुत बड़ा कोड बेस (कोड की लगभग 250 के लाइनों) के लिए प्रतिक्रिया नहीं दी थी। कुछ सौ वर्गों में एक और लॉगिंग ढांचे का इस्तेमाल किया गया था, कुछ और सौ में। फिर System.out.println(*) की कई हजार लाइनें थीं जहां वास्तव में लॉग आउटपुट होना चाहिए था। तो मैं कोड बेस भर में बिखरे हुए कोड की हजारों लाइनों को ठीक करने के साथ समाप्त हुआ। सौभाग्य से मैं पूरी कार्रवाई को तेज करने के लिए इंटेलिजे आईडीईए (संरचनात्मक खोज और प्रतिस्थापन) में कुछ चालाक चाल का उपयोग कर सकता हूं, लेकिन लड़का आपको नहीं लगता कि यह छोटा था! निश्चित रूप से, दृढ़ता से संदर्भ-निर्भर डीबग लॉगिंग हमेशा एक विधि निकाय के भीतर होती है, लेकिन कई महत्वपूर्ण प्रकार के लॉगिंग जैसे कि ट्रेसिंग विधि कॉल (यहां तक ​​कि पदानुक्रमित रूप से अच्छी तरह से इंडेंट आउटपुट के साथ), दोनों हैंडल या अनचाहे अपवादों को लॉगिंग करना, उपयोगकर्ता ऑडिटिंग (लॉगिंग कॉल उपयोगकर्ता भूमिकाओं के आधार पर प्रतिबंधित विधियां) और आगे स्रोत कोड को प्रदूषित किए बिना पहलुओं में आसानी से कार्यान्वित किया जा सकता है। रोज़ाना एप्लिकेशन डेवलपर को इसके बारे में सोचना या कोड बेस पर बिखरे हुए लॉगर कॉल को देखने की आवश्यकता नहीं है। कोई भी पहलू को अद्यतित रखने के लिए ज़िम्मेदार है और लॉगिंग रणनीति या पूरे लॉगिंग फ्रेमवर्क को एक स्थान पर भी स्विच कर सकता है।

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





cross-cutting-concerns