लॉगिंग के लिए कौन सा डिज़ाइन पैटर्न अधिक उपयुक्त है?


10

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

MyGloriousLogger.getXXXLogger().Log(LogPlace, new LogObject(z1, z2, z3, z4, ..., z99));

क्या मैं ऑब्ज़र्वर डिज़ाइन पैटर्न का उपयोग करने की गलती करता हूं? मुझे एक और डिज़ाइन पैटर्न चाहिए? या मुझे डिज़ाइन पैटर्न के बारे में सोचना बंद कर देना चाहिए?

PS1। अगर मैं केवल श्रोताओं और पर्यवेक्षकों का उपयोग करके लॉग इन करना चाहता हूं, तो मुझे निश्चित रूप से कार्यक्रम के पर्यवेक्षकों और श्रोताओं को जोड़ना और सुधारना होगा।

पीएस 2। मैं निश्चित रूप से जानता हूं कि जावा में लॉगिंग के लिए अलग-अलग लाइब्रेरी हैं और मैं java.utils.log का उपयोग कर रहा हूं, लेकिन मुझे अपनी विशेष वस्तुओं को लॉग करने के लिए इसके लिए एक रैपर रखना होगा।


2
जावा में पहले से ही 17 लॉगिंग फ्रेमवर्क और मेटा-लॉगिंग फ्रेमवर्क (slf4j) हैं और शायद कुछ मेटा-मेटा-लॉगिंग फ्रेमवर्क और उनमें से कोई भी आपके लिए काम नहीं करता है?
केविन क्लाइन

जवाबों:


15

Loggingआमतौर पर जिम्मेदारी पैटर्न की श्रृंखला के साथ लागू किया जाता है । बेशक, आप (और मैं) इसे एक मुखौटा के साथ जोड़ सकते हैं । मैं वास्तव में खुद को श्रोता (ओं) या प्रेक्षक का उपयोग नहीं करूंगा।

जिम्मेदारी की श्रृंखला - लकड़हारा


क्या यह मूल रूप से कह रहा है "अपने कोड में अपने सार लकड़हारे को लिखें"? मुझे लगता है कि मेरा सवाल यह है: क्या मुझे उन घटनाओं को ट्रिगर करना चाहिए जहां से मैं लॉग इन करना चाहता हूं और एक श्रोता प्रदान करना चाहता हूं जो घटनाओं के जवाब में लॉग इन करता है, या क्या मुझे सीधे अपने लॉगर सेवा (जो आंतरिक रूप से जिम्मेदारी की श्रृंखला का उपयोग करता है) को कॉल करना चाहिए और यही है?
फ्रांसेस्को बेलाडोना

8

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


0

खैर, ऑब्जर्वर लगता है मेरे लिए अनफिट है। इसके अलावा, लकड़हारा कॉल को "जहां भी आपको आवश्यकता होगी" अपने कोड को तोड़ देगा और एसआरपी का उल्लंघन करेगा।

उदाहरण के लिए, आप AOP में रुचि रखते हैं, इसलिए आप विधि एनोटेशन के माध्यम से लकड़हारा कॉल संलग्न कर सकते हैं।


0

चेन की जिम्मेदारी एक अच्छा पैटर्न लगती है जब आपका आउटपुट कई स्थानों पर लैंडअप कर सकता है। यूएमएल में आपके पास अलग-अलग लकड़हारा है जो कंसोल को निर्देशित करता है, अन्य को त्रुटिपूर्ण और 3 को बस जानकारी लकड़हारा।

आमतौर पर मैंने देखा है कि logLvels अलग हैं लेकिन लॉगिंग फ़ाइल समान है।

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

इस तरह मैं देख रहा हूं कि हम अपने लॉगिंग कोड को एप्लिकेशन कोड से अलग कर सकते हैं।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.