मैं वर्तमान में मार्क सीमैन और स्टीवन वैन ड्यूरसन की पुस्तक "डिपेंडेंसी इंजेक्शन" (दूसरा संस्करण, लेकिन वही उदाहरण पहले संस्करण में है) पढ़ रहा हूं।

अध्याय ९.२.२ में "डेकोरेटर पैटर्न का उपयोग करके अपवादों की रिपोर्ट करना" वह एक अपवाद हैंडलिंग डेकोरेटर का प्रस्ताव करता है जो कुछ अपवादों को पकड़ने के साथ एक अमूर्त को सजाता है और उपभोक्ता को अपवाद को बबल करने के बजाय अलर्ट बॉक्स खोलता है।

वह कहता है कि एसआरपी और ओसीपी का पालन करता है, जिसका मैं पालन कर सकता हूं।

हालांकि, मेरी राय में, यह Liskov प्रतिस्थापन सिद्धांत का उल्लंघन करता है।

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

मेरी राय में उपभोक्ता को यह नहीं पता होना चाहिए कि एक अमूर्त सजाया गया था, उसे उस अनुबंध का पालन करना चाहिए जो अमूर्त प्रदान करता है।

मेरा प्रस्ताव एक नया इंटरफ़ेस IExceptionHandlingAbstraction होगा जो एक एडेप्टर द्वारा कार्यान्वित किया जाता है जो IAbstraction के अपवादों को पकड़ता है और इसे अलर्ट बॉक्स में बदल देता है। इस तरह उपभोक्ता IExceptionHandlingAbstraction के अनुबंध पर भरोसा कर सकता है और स्पष्ट रूप से जानता है कि उसे स्वयं अपवादों को संभालने की आवश्यकता नहीं है।

क्योंकि मुझे मार्क की पोस्ट, उत्तर और किताबों पर वास्तव में बहुत भरोसा है, मुझे पूरा यकीन नहीं है कि मुझे यहां कुछ याद आ रहा है।

0
Creepin 24 जून 2019, 10:04

1 उत्तर

सबसे बढ़िया उत्तर

उपभोक्ता को यह नहीं पता होना चाहिए कि एक अमूर्त सजाया गया था, उसे उस अनुबंध का पालन करना चाहिए जो अमूर्त प्रदान करता है।

यह सही है। एलएसपी का पालन करने के लिए, अमूर्त के दोनों कार्यान्वयनों को एक ही अनुबंध का पालन करना चाहिए। लेकिन अब सवाल यह हो जाता है: अनुबंध वास्तव में क्या है? उपभोक्ता क्या उम्मीद कर सकता है।

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

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

हालांकि, उस उदाहरण का मतलब पूर्ण-प्रूफ, 100% सॉलिड सॉल्यूशन नहीं है, बल्कि डेकोरेटर्स का उपयोग करके इंटरसेप्शन की शक्ति को प्रदर्शित करने के लिए एक उदाहरण के रूप में है। और यह भी ध्यान दें कि अध्याय १० में हम बताते हैं कि १००% ठोस होना न तो संभव है और न ही वांछनीय। यह सब ट्रेडऑफ़ के बारे में है और शायद यह डेकोरेटर उदाहरण आपके द्वारा बनाए जा रहे विशेष क्लाइंट एप्लिकेशन में अच्छी तरह से काम करता है, हालांकि मुझे उम्मीद है कि एक उपभोक्ता (एक फॉर्म) को यह जानने की जरूरत है कि क्या ऑपरेशन सफल हुआ है, क्योंकि आप आमतौर पर फॉर्म को पूरा होने पर बंद करना चाहते हैं। . लेकिन उस मामले में, मैं उम्मीद करता हूं कि अध्याय 10 में निर्धारित एक डिजाइन एक बेहतर समाधान होगा।

मेरा प्रस्ताव एक नया इंटरफ़ेस IExceptionHandlingAbstraction होगा जो एक एडेप्टर द्वारा कार्यान्वित किया जाता है जो IAbstraction के अपवादों को पकड़ता है और इसे अलर्ट बॉक्स में बदल देता है

एक नया अमूर्त बनाना जो उपभोक्ता को विफलताओं के बारे में सूचित या सूचित करने की अनुमति देता है, एलएसपी उल्लंघन के आसपास एक अच्छा समाधान है।

0
Steven 24 जून 2019, 08:13