क्या "सूचना केंद्र" पैटर्न अच्छे या बुरे प्रोग्राम डिज़ाइन को प्रोत्साहित करता है?

13

कभी-कभी मैं इन संदेश-हब-शैली APIs में आता हूं, उदाहरण के लिए कोको NSNotificationCenter: http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Classes/NSNotificationCenter_Class/Reference/Reference.html

आमतौर पर ये एपीआई एक वैश्विक पहुंच बिंदु प्रदान करते हैं, जिस पर आप संदेशों / घटनाओं की सदस्यता या प्रसारण करते हैं। मैं सोच रहा हूं कि यह एक समस्या है क्योंकि यह एक सपाट और असंरचित कार्यक्रम वास्तुकला को प्रोत्साहित करता है, जहां निर्भरता एपीआई में स्पष्ट नहीं है, लेकिन स्रोत कोड में छिपी हुई है। आपको ऑब्जेक्ट ओनरशिप और पदानुक्रम के बारे में सोचने के लिए मजबूर नहीं किया जाता है, बल्कि आपके प्रोग्राम परिणाम में किसी भी कोड को कहीं भी कॉल किए जाने के बजाय किसी भी ऑब्जेक्ट को बना सकता है। लेकिन शायद यह अच्छी बात है?

क्या यह पैटर्न आम तौर पर अच्छे या बुरे प्रोग्राम डिज़ाइन को प्रोत्साहित करता है, और ऐसा क्यों? क्या यह कोड को कठिन या परीक्षण करने में आसान बनाता है?

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

संपादित करें: मुझे लगता है कि इस पैटर्न के साथ मेरा सबसे बड़ा मुद्दा यह है कि एपीआई निर्भरता और ऑब्जेक्ट कपलिंग के बारे में "झूठ" है, और इस उदाहरण के साथ सचित्र किया जा सकता है:

myObj = new Foo();
myOtherObj = new Bar();
print myOtherObj.someValue; // prints 0
myObj.doSomething();
print myOtherObj.someValue; // prints 1, unexpectedly, because I never indicated that these objects had anything to do with each other

— मैग्नस वोल्फेल्ट
स्रोत

क्या आप इस उदाहरण पर विशेष रूप से या सामान्य तौर पर श्रोता पैटर्न पर सवाल उठा रहे हैं?

— TheLQ

मेरा मानना है कि यह श्रोता पैटर्न की तुलना में व्यापक है। श्रोता पैटर्न को एक अच्छी तरह से परिभाषित वस्तु संरचना और विशिष्ट वस्तुओं पर श्रोताओं को पंजीकृत करने के साथ "सफाई से" लागू किया जा सकता है। मेरी अनिश्चितता वैश्विक संदेश / इवेंट हब पैटर्न के बारे में है।

— मैग्नस वोल्फेल्ट

6

मैं यह नहीं कहूंगा कि यह खराब प्रोग्रामिंग को प्रोत्साहित करता है। लेकिन इसका आसानी से दुरुपयोग किया जा सकता है।

वैसे वास्तविक विचार क्या है?
अधिसूचना का स्रोत केवल इसकी अधिसूचना बनाता है। यह संभावित पर्यवेक्षकों या कुछ भी के अस्तित्व के बारे में धारणा नहीं बनाता है। एक पर्यवेक्षक सूचनाओं के लिए रजिस्टर करता है जिसे इसे संभालने के लिए डिज़ाइन किया गया है। पर्यवेक्षक इस बारे में कोई अनुमान नहीं लगा सकता है कि सूचनाओं के लिए कितने संभावित स्रोत हैं जो इसे संभाल सकते हैं।

यह निर्भरता इंजेक्शन को प्राप्त करने का एक तरीका है, बिना कभी स्रोतों को जानने वाले पर्यवेक्षकों या पर्यवेक्षकों को सूत्रों को जानते हैं। हालाँकि पूरी प्रणाली को काम करने के लिए, आपको सही सूचनाओं के लिए सही पर्यवेक्षकों को तार करने की आवश्यकता है, और यह प्रणाली टाइपोस के लिए भी कमजोर है, क्योंकि यह समय की जाँच नहीं हो सकती है।

पाठ्यक्रम का सबसे बड़ा खतरा यह है कि कोई व्यक्ति 1-1 कॉल के लिए विश्व स्तर पर वस्तुओं को उपलब्ध कराने के लिए इसका उपयोग करेगा।

— back2dos
स्रोत

6

एसिंक्रोनस मैसेजिंग बड़े सिस्टम के लिए एक अच्छा वास्तुशिल्प प्रिंसिपल है जिसे स्केल करना चाहिए

इस के बराबर जावा JMS है और आमतौर पर एक अच्छी बात मानी जाती है ।

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

आप संदेश हब के URI को आसानी से बाहरी बना सकते हैं ताकि इसे कॉन्फ़िगर किया जा सके और स्रोत कोड में एम्बेड न किया जा सके।

— गैरी रोवे
स्रोत

4

यह एक विशिष्ट ओवर्सरवर पैटर्न कार्यान्वयन है (या कभी-कभी एक श्रोता पैटर्न या कभी-कभी सब्सक्राइबर / प्रकाशक पैटर्न कहा जाता है)। अनुप्रयोगों में जहां यह व्यवहार उपयोगी है, इसे लागू करने के लिए एक अच्छा पैटर्न है। यदि समाधान में कोई मूल्य नहीं जोड़ा जाता है तो कोई भी पैटर्न लागू नहीं किया जाना चाहिए।

आपके प्रश्न से, ऐसा लगता है जैसे आप चिंतित हैं कि सब कुछ NotificationCenter के बारे में जानता है और वैश्विक चीजें BAD हैं। कभी-कभी, हाँ, वैश्विक चीजें खराब होती हैं। लेकिन आइए विकल्प देखें। मान लीजिए कि आपके पास 2 घटक हैं, इस उदाहरण के लिए यह वास्तव में मायने नहीं रखता कि वे क्या करते हैं या वे क्या हैं। Component1 में कुछ डेटा होते हैं जिन पर किसी तरह से कार्रवाई की गई या बदल दी गई। Component2 उस प्रकार के डेटा में किसी भी बदलाव के बारे में जानना चाहेगा जो Compoent1 प्रबंधित करता है। क्या कॉम्पोनेंट 2 को कंपोनेंट 1 के अस्तित्व के बारे में पता होना चाहिए? या क्या यह Component2 के लिए बेहतर होगा कि एक संदेश के लिए सदस्यता लें / सुनें जो यह बताता है कि ऐप में कुछ घटक ने कुछ डेटा को बदल दिया है जिसमें वह रुचि रखता है? अब इस उदाहरण को लें और इसे दर्जनों या अधिक घटकों से गुणा करें और आप देख सकते हैं कि पैटर्न का मूल्य कहाँ निहित है।

क्या यह हर स्थिति के लिए एक सही समाधान है, नहीं। क्या यह घटकों के बीच में अमूर्त संचार करता है और अधिक ढीली युग्मन प्रदान करता है, हाँ।

— वाल्टर
स्रोत

1

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

— मैग्नस वोल्फेल्ट

0

यह ईवेंट-चालित प्रणालियों के लिए अच्छा है, और ऑब्जर्वरों का एक समूह है जो एक-दूसरे को देख रहे हैं, के विकल्प की तुलना में अच्छा है, क्योंकि आप पर्यवेक्षकों की गोलीबारी के अनजाने अनंत छोरों के साथ हवा की संभावना कम है। पुराने VB दिनों में यह एक वास्तविक समस्या थी, जब आपके पास इवेंट-संचालित ActiveX नियंत्रण थे जो इवेंट हैंडलर के साथ एक-दूसरे को वायर्ड कर सकते थे।

— TMN
स्रोत