किसी ईवेंट लॉग पार्सर के लिए उपयुक्त डिज़ाइन पैटर्न?

Question

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

एक ही लॉग में 500,000 घटनाएं हो सकती हैं, और लगभग 60 प्रकार की घटनाएं हैं, जिनमें से सभी 7 मूल गुणों को साझा करते हैं और फिर ईवेंट प्रकार के आधार पर 0 से 15 अतिरिक्त गुण होते हैं। घटना का प्रकार प्रत्येक पंक्ति में लॉग फ़ाइल में दूसरी संपत्ति है।

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

मैंने सभी संभावित गुणों के संघ के साथ आधार "घटना" कक्षा की कोशिश की है। मैंने "नया इवेंट" कॉल से बचने की कोशिश की है (क्योंकि वहां बड़ी संख्या में ईवेंट हो सकते हैं और ईवेंट ऑब्जेक्ट्स आम तौर पर कम रहते हैं) और आदिम संपत्ति तर्कों के साथ प्रति प्रकार कॉलबैक विधियां हैं। मैंने 7 सामान्य आधार गुणों के साथ एक अमूर्त इवेंट पेरेंट के साथ 60 घटना प्रकारों में से प्रत्येक के लिए उप-वर्ग होने का प्रयास किया है।

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

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

Answer 1

अच्छी तरह से ... सभी गुणों के एक संघ के साथ एक एकल घटना वर्ग की बजाय एक चीज़ के लिए, या 61 घटना वर्ग (1 आधार, 60 subs), उस परिदृश्य में एक बहुत परिदृश्य में, मैं परीक्षा दूंगा इवेंट की जानकारी स्टोर करने के लिए एक सिंगल इवेंट क्लास है जो एक संपत्ति बैग (शब्दकोश, हैशटेबल, डब्ल्यू/ई आपकी नाव तैरती है) का उपयोग करती है। घटना का प्रकार केवल एक और संपत्ति मूल्य है जो बैग में डाल दिया जाता है। मुख्य कारण यह है कि मैं इस तरह दुबला होगा क्योंकि मैं किसी भी चीज़ के 60 व्युत्पन्न वर्गों को बनाए रखने के लिए नाराज हूं।

बड़ा सवाल यह है कि ... पर आपको प्रक्रियाओं के साथ क्या करना है। क्या आप उन्हें एक रिपोर्ट में प्रारूपित करते हैं, उन्हें डेटाबेस तालिका में व्यवस्थित करते हैं, कुछ घटनाएं होने पर लोगों को जगाते हैं ... क्या?

क्या यह एक वास्तविक तथ्य पार्सर या रीयल-टाइम इवेंट हैंडलर होना है?मेरा मतलब है, क्या आप लॉग की निगरानी कर रहे हैं क्योंकि घटनाएं आती हैं, या अगले दिन लॉग फाइलों को पार्स कर रही हैं?

Answer 2

संभवतः Hashed Adapter Objects (आप वेब पर इसके बारे में एक अच्छा विवरण मिल सकता है - वे की कमी कर रहे हैं।)

Answer 3

रणनीति वस्तुओं की एक फ्लायवेट कारखाने, एक प्रति घटना की 'क्लास' पर विचार करें।

घटना डेटा की प्रत्येक पंक्ति के लिए, फ्लाईवेट फैक्ट्री से उचित पार्सिंग रणनीति देखें, और फिर ईवेंट डेटा को पार्सिंग के लिए रणनीति में पास करें। 60 रणनीति वस्तुओं में से प्रत्येक एक ही कक्षा का हो सकता है, लेकिन फील्ड पार्सिंग ऑब्जेक्ट्स के एक अलग संयोजन के साथ कॉन्फ़िगर किया गया है। अधिक जानकारी के बिना और अधिक विशिष्ट होना मुश्किल है।

Answer 4

मुझे यकीन नहीं है कि मैं समस्या को सही ढंग से समझता हूं। मुझे लगता है कि एक जटिल 'मॉडल अद्यतन तर्क' है। 60 वर्गों के माध्यम से इसे वितरित न करें, इसे एक ही स्थान पर रखें, इसे ईवेंट कक्षाओं (मध्यस्थ पैटर्न, प्रकार) से बाहर ले जाएं।

आपका मध्यस्थ घटना वर्गों के साथ काम करेगा (मुझे नहीं लगता कि आप यहां फ्लाईवेट का उपयोग कैसे कर सकते हैं), घटनाएं खुद को पार्स कर सकती हैं।

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

Answer 5

बस ऊपर से:

मैं संपत्तियों की एक नक्शे के साथ केवल एक ही वर्ग होने के बारे में स्वीकार किए जाते हैं जवाब में सुझाव पसंद है। मुझे यह भी लगता है कि व्यवहार को इस तरह से भी इकट्ठा किया जा सकता है:

class Event 
{ 
    // maps property name to property value 
    private Map<String, String> properties; 

    // maps property name to model updater 
    private Map<String, ModelUpdater> updaters; 

    public void update(Model modelToUpdate) 
    { 
     foreach(String key in this.properties.keys) 
     { 
      ModelUpdater updater = this.updaters[key]; 
      String propertyValue = this.properties[key]; 

      updaters.updateModelUsingValue(model, propertyValue); 
     } 
    } 

} 

मॉडल अपडेटर क्लास चित्रित नहीं किया गया है। यह एक संपत्ति के आधार पर आपके मॉडल को अद्यतन करता है। मैंने लूप बनाया; यह वास्तव में आपका एल्गोरिदम क्या हो सकता है या नहीं हो सकता है। मैं शायद एक मॉडल के मॉडलअपडेटर को अधिक बना दूंगा। प्रत्येक कार्यान्वयन प्रति संपत्ति होगी और मॉडल को अपडेट करेगा।

तब मेरे "मुख्य पाश" होगा:

Model someModel; 

foreach(line in logFile) 
{ 
    Event e = EventFactory.createFrom(line); 
    e.update(someModel); 
} 

EventFactory फ़ाइल से घटनाओं निर्माण करती है। यह घटना के गुणों के आधार पर दो मानचित्रों को पॉप्युलेट करता है। इसका तात्पर्य है कि किसी संबंधित संपत्ति अद्यतनकर्ता के साथ संपत्ति से मिलान करने का कोई तरीका है।

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