पर्यवेक्षक पैटर्न को बहिष्कृत क्यों किया जाना चाहिए?

Question

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

मार्टिन ओडरस्की और दोस्तों ने विशेष रूप से आकर्षक शीर्षक, "Deprecating the Observer Pattern" के साथ एक लंबा पेपर लिखा और मैंने अभी तक इसे पढ़ने का समय नहीं बनाया है।

मैं पता है कि इतना और पर्यवेक्षक पैटर्न के साथ गलत इतना (प्रस्तावित या अन्य) विकल्प इस तरह के उज्ज्वल लोग इस पत्र लिखने के लिए नेतृत्व करने के लिए के बारे में बेहतर है करना चाहते हैं।

एक शुरुआत के रूप में, मैं एक (मनोरंजक) कागज here की आलोचना मिला।

Answer 1

the paper से सीधे हवाला देते हुए: माउस खींचकर:

पर्यवेक्षक पैटर्न, हम एक सरल और सर्वव्यापी उदाहरण के साथ शुरू की सटीक समस्याओं इसे समझने के लिए। निम्न उदाहरण एक Path वस्तु में एक खींचें आपरेशन के दौरान माउस के आंदोलनों के निशान और स्क्रीन पर प्रदर्शित करता है यह। चीजों को सरल रखने के लिए, हम स्काला क्लोजर पर्यवेक्षकों के रूप में उपयोग करते हैं।

var path: Path = null 
val moveObserver = { (event: MouseEvent) => 
    path.lineTo(event.position) 
    draw(path) 
} 
control.addMouseDownObserver { event => 
    path = new Path(event.position) 
    control.addMouseMoveObserver(moveObserver) 
} 
control.addMouseUpObserver { event => 
    control.removeMouseMoveObserver(moveObserver) 
    path.close() 
    draw(path) 
} 

ऊपर के उदाहरण हैं, और हम के रूप में में [25] सामान्य रूप में, महत्वपूर्ण सॉफ्टवेयर इंजीनियरिंग के सिद्धांतों के एक प्रभावशाली लाइन अप का उल्लंघन करती है परिभाषित पर्यवेक्षक पैटर्न का तर्क के रूप में:

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

Encapsulation राज्य चर path पर्यवेक्षकों के दायरे निकल जाता है के रूप में, पर्यवेक्षक पैटर्न कैप्सूलीकरण टूट जाता है।

Composability एकाधिक पर्यवेक्षकों के रूप में वस्तुओं है कि एक ही चिंता का विषय से निपटने का एक ढीला संग्रह (या एकाधिक, अगले अंक देखें)। चूंकि कई पर्यवेक्षक पर विभिन्न बिंदुओं पर अलग-अलग बिंदुओं पर स्थापित होते हैं, उदाहरण के लिए, आसानी से उन्हें पूरी तरह से निपटाने के लिए नहीं कर सकते हैं। चिंताओं के

पृथक्करण ऊपर पर्यवेक्षकों केवल माउस पथ का पता लगाने नहीं लेकिन यह भी एक ड्राइंग आदेश कॉल करें, या अधिक आम तौर पर, एक ही कोड स्थान में दो अलग अलग चिंताओं में शामिल हैं। पथ बनाने और इसे प्रदर्शित करने की चिंताओं को अलग करने के लिए अक्सर बेहतर होता है, उदाहरण के लिए, मॉडल-व्यू-कंट्रोलर (एमवीसी) [30] पैटर्न में ।

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

समानता विभिन्न पर्यवेक्षकों को स्थापित करने के लिए विभिन्न विधियां कोड एकरूपता को कम करें।

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

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

सिमेंटिक दूरी अंत में, उदाहरण के को समझने के लिए, क्योंकि नियंत्रण प्रवाह उलटी, जो बहुत ज्यादा बॉयलरप्लेट कोड है कि प्रोग्रामर इरादा और वास्तविक कोड के बीच अर्थ दूरी बढ़ जाती है में परिणाम कठिन है।

[25] ई। गामा, आर। हेल्म, आर जॉनसन, और जे। Vlissides। डिजाइन पैटर्न: पुन: प्रयोज्य ऑब्जेक्ट उन्मुख सॉफ़्टवेयर के तत्व। एडिसन-वेस्ले लॉन्गमैन पब्लिशिंग कं, इंक, बोस्टन, एमए, यूएसए, 1 99 5। आईएसबीएन 0-201-63361-2।

Answer 2

मेरा मानना ​​है कि ऑब्जर्वर पैटर्न में मानक कमियां होती हैं जो decoupling चीजों के साथ आती हैं। विषय पर्यवेक्षक से decoupled हो जाता है लेकिन आप केवल अपने स्रोत कोड को नहीं देख सकते हैं और यह पता लगा सकते हैं कि कौन इसे देखता है। हार्डकोडेड निर्भरता आमतौर पर पढ़ने और सोचने में आसान होती है लेकिन उन्हें संशोधित करना और पुन: उपयोग करना कठिन होता है। यह एक व्यापार है।

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

के लिए सुलभ है। आप एक एकल (राज्यव्यापी!) पर्यवेक्षक ऑब्जेक्ट भी बना सकते हैं जो सभी OnThis, OnThat, OnWhatever विधियों को लागू करता है और कई स्टेटलेस ऑब्जेक्ट्स में एक राज्य मशीन को अनुकरण करने की समस्या से छुटकारा पाता है।

Answer 3

मैं संक्षिप्त होगा क्योंकि मैं विषय के लिए नया हूं (और अभी तक उस विशिष्ट लेख को नहीं पढ़ा है)।

पर्यवेक्षक पैटर्न सहजता से गलत है: ऑब्जेक्ट देखने के लिए पता है कि कौन देख रहा है (विषय <> - पर्यवेक्षक)। यह वास्तविक जीवन के खिलाफ है (घटना-आधारित परिदृश्यों में)। अगर मैं चिल्लाता हूं, मुझे नहीं पता कि कौन सुन रहा है; अगर एक रोशनी, फर्श पर हिट करता है ... बिजली नहीं जानता है कि जब तक यह हिट नहीं हो जाता है! केवल पर्यवेक्षकों को पता है कि वे क्या देख सकते हैं।

जब इस तरह की चीजें होती हैं तो सॉफ़्टवेयर एक गड़बड़ी के लिए उपयोग करता है - क्योंकि हमारे सोचने के तरीके के खिलाफ बनाया गया है। ऐसा लगता है जैसे और ऑब्जेक्ट जानता था कि अन्य ऑब्जेक्ट्स उसकी विधियों को कैसे कॉल कर सकते हैं।

आईएमओ "पर्यावरण" जैसी एक परत घटनाओं को लेने और प्रभावित लोगों को सूचित करने का प्रभारी है। (या घटना और उस घटना के जेनरेटर को मिलाता है)

इवेंट-सोर्स (विषय) पर्यावरण को घटनाओं को उत्पन्न करता है। पर्यावरण पर्यवेक्षक को घटना प्रदान करता है। पर्यवेक्षक उन घटनाओं के लिए पंजीकरण कर सकता है जो उन्हें प्रभावित करते हैं या वास्तव में पर्यावरण में परिभाषित किया जाता है। दोनों संभावनाएं समझ में आती हैं (लेकिन मैं संक्षिप्त होना चाहता था)।

मेरी समझ में पर्यवेक्षक पैटर्न पर्यावरण को एक साथ रखता है & विषय।

पीएस। पैराग्राफ अमूर्त विचारों में डालने से नफरत है! : पी