2012-11-05 39 views
5

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

कमांड मूल्यांकन किसी प्रकार का मिलान परिणाम। यह इस तरह से एक उपयुक्त ईवेंट सक्रिय:

$dispatcher->dispatch('game_bundle.match_won', new MatchWonEvent($match, $winner)); 

अब मैं कई श्रोताओं रजिस्टर करने के लिए विजेता के फेसबुक पेज और एक और एक विजेता के लिए एक उपलब्धि बुक करने के लिए करने के लिए इस पोस्ट करने के लिए उदाहरण के लिए की तरह इस घटना को संभालने के लिए, चाहते हैं। उदाहरणों में मैंने पाया कि लॉगिन कार्यक्रम को संभालने वाला श्रोता मुख्य रूप से LoginListener जैसा कुछ कहलाता था, लेकिन क्या यह नाम उस घटना के बजाय वास्तविक उपयोग से संबंधित नहीं होना चाहिए? क्योंकि अब मेरे उदाहरण में मुझे MatchWonListener की आवश्यकता होगी, लेकिन क्या इसमें फेसबुक और उपलब्धि तर्क दोनों शामिल होना चाहिए? इससे इवेंट सिस्टम बेकार हो जाएगा ... क्या onMatchWon($event) और एक AchievementListener के साथ onMatchWon($event) विधि के साथ एक बेहतर होना बेहतर नहीं होगा? इससे उदाहरण के लिए FacebookListener में अधिक फेसबुक-संबंधित ईवेंट जोड़ना आसान हो जाएगा।

मैं नमूने में नामकरण के बारे में उलझन में हूं और अब इसके बारे में निश्चित नहीं हूं। क्या मैं इसे पूरी तरह गलत कर रहा हूं?

उत्तर

2

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

तो इस बात पर विचार करते हुए कि आप चिंताओं को अलग करने के लिए घटनाओं को बनाने के लिए अब तक गए हैं, तो आप एक अलग श्रोता में एक अलग श्रोता में क्यों जाएंगे? उस स्थिति में आप किसी ईवेंट को प्रेषित करने के बजाय केवल एक प्रत्यक्ष कॉल कर सकते हैं।

मैं व्यक्तिगत रूप से "ऑनमैचवॉन" जैसे नामों के खिलाफ हूं क्योंकि यह वर्णन नहीं करता कि विधि क्या करती है। आइए मान लें कि आप एक मैच जीतने की घटना सुनना चाहते हैं और जीते गए उपयोगकर्ता की उपलब्धियों को अपडेट करना चाहते हैं। मेरे पास शायद कुछ उपयोगकर्ता प्रबंधक सेवा या विधि updateAchievements(MatchWonEvent $event) के साथ सॉर्ट होगा। लेकिन मुझे लगता है कि यदि आप इच्छुक हैं तो स्वाद, या सम्मेलन का विषय अधिक है।

+0

मैं इसके सामान्य उद्देश्य ('फेसबुक लिस्टर', 'अचीवमेंट लिस्टर') के बाद श्रोता वर्ग का नाम देना चाहता था और वास्तविक विधि जिसे 'onMatchWon'' कहा जाता है। क्योंकि यह कुछ भी नहीं होगा (अभी भी पूरी तरह से नए श्रोताओं के साथ आसानी से विस्तार योग्य होगा। बड़ा लाभ अभी भी है कि इस विधि में बहुत सी सीधी कॉल होने की आवश्यकता नहीं है, घटना को प्रेषित किया गया था। जैसा कि आपने सुझाव दिया था, मैं नहीं चाहता था, मैं नहीं श्रोताओं को कॉल करने का तरीका जानें, क्योंकि कई श्रोताओं (उपलब्धियों, फेसबुक, ...) के बारे में 'MatchWonListener'' कहा जाएगा। –

+0

नहीं, मैंने यह सुझाव नहीं दिया कि, वही है जो मैं लोगों को करने से हतोत्साहित करने की कोशिश कर रहा था। मैंने कहा कि कोई सम्मेलन नहीं है, लेकिन 'मैचवोनलिस्टर' होने के कारण काफी मूर्खतापूर्ण प्रतीत होता है। मुझे लगता है कि आप जो करना चाहते थे वह ठीक है, मुझे कक्षाओं "श्रोताओं" नामकरण पसंद नहीं है क्योंकि इसका मतलब है कि वे जानते हैं कि वे ' जिसे बुलाया जा रहा है, जिसे मैं टालने की कोशिश करता हूं, लेकिन सब कुछ भयानक नहीं है, और जैसा कि मैंने कहा, स्वाद का विषय अधिक है। – fd8s0

+0

आह ठीक है! तो मैं बिल्कुल गलत नहीं था .-) धन्यवाद बहुत ! –