संदेश के साथ प्रत्यक्ष निर्भरता को बदलना
कभी-कभी एक मॉड्यूल को केवल दूसरों को सूचित करने की आवश्यकता होती है कि इसमें कुछ घटनाएँ/परिवर्तन हुए हैं, और इससे कोई फर्क नहीं पड़ता कि बाद में इस जानकारी का क्या होता है।
इस मामले में, मॉड्यूल को "एक दूसरे के बारे में जानने" की बिल्कुल भी आवश्यकता नहीं है, अर्थात, सीधे लिंक होते हैं और सीधे बातचीत करते हैं, लेकिन यह केवल संदेशों (संदेशों) या घटनाओं (घटनाओं) का आदान-प्रदान करने के लिए पर्याप्त है।
कभी-कभी ऐसा लगता है कि संदेश के माध्यम से मॉड्यूल संचार प्रत्यक्ष निर्भरता से बहुत कमजोर है। दरअसल, क्योंकि तरीकों को नहीं कहा जाता है, कक्षाओं के बारे में कोई जानकारी नहीं है। लेकिन यह एक भ्रम से ज्यादा कुछ नहीं है।
विधि के नामों के बजाय, तर्क संदेश प्रकार, उनके पैरामीटर और प्रेषित डेटा से बंधे होने लगते हैं। ऐसे मॉड्यूल की कनेक्टिविटी खराब हो गई है।
यह ऐसा हुआ करता था: हम विधियों को कॉल करते हैं - कनेक्टिविटी है, हम विधियों को कॉल नहीं करते हैं - कोई कनेक्टिविटी नहीं है। अब कल्पना कीजिए कि मॉड्यूल ए ने अपने संदेशों में थोड़ा अलग डेटा भेजना शुरू किया। और साथ ही, इन संदेशों पर निर्भर सभी मॉड्यूल ठीक से काम नहीं करेंगे।
मान लीजिए, पहले, एक नया उपयोगकर्ता जोड़ते समय, प्राधिकरण मॉड्यूल ने USER_ADDED संदेश भेजा था, और अद्यतन के बाद, यह पंजीकरण करने का प्रयास करते समय यह संदेश भेजना शुरू कर दिया और इसके अलावा पैरामीटर में सफल पंजीकरण या नहीं इंगित करता है।
इसलिए, संदेश तंत्र को बहुत सक्षमता से लागू करना बहुत महत्वपूर्ण है। इसके लिए विभिन्न टेम्प्लेट हैं।
देखने वाला। इसका उपयोग एक-से-कई निर्भरता के मामले में किया जाता है, जब कई मॉड्यूल एक - मुख्य एक की स्थिति पर निर्भर करते हैं। यह मेलिंग तंत्र का उपयोग करता है, जिसका अर्थ है कि मुख्य मॉड्यूल अपने सभी ग्राहकों को केवल एक ही संदेश भेजता है, और इस जानकारी में रुचि रखने वाले मॉड्यूल "सब्सक्राइबर" इंटरफ़ेस को लागू करते हैं और मेलिंग सूची की सदस्यता लेते हैं।
यह दृष्टिकोण उपयोगकर्ता इंटरफ़ेस के साथ सिस्टम में व्यापक रूप से उपयोग किया जाता है, जिससे एप्लिकेशन (मॉडल) के मूल को स्वतंत्र रहने की अनुमति मिलती है, जबकि इसके संबद्ध इंटरफेस को सूचित किया जाता है कि कुछ बदल गया है और इसे अद्यतन करने की आवश्यकता है।
यहां ऑपरेटिंग सिस्टम स्तर पर संदेश प्रारूप को मानकीकृत किया गया है, जिसके डेवलपर्स को बैकवर्ड संगतता और अच्छे प्रलेखन का ध्यान रखना चाहिए।
संदेशों के वितरण के माध्यम से बातचीत के संगठन में एक अतिरिक्त "बोनस" है - "प्रकाशित" (यानी बाहर भेजे गए) संदेशों के लिए "सब्सक्राइबर" का वैकल्पिक अस्तित्व। इस तरह की एक अच्छी तरह से डिज़ाइन की गई प्रणाली मॉड्यूल को किसी भी समय जोड़ने/हटाने की अनुमति देती है।
मैसेजिंग बस
आप संदेशों के आदान-प्रदान को व्यवस्थित कर सकते हैं और इसके लिए मध्यस्थ पैटर्न का एक अलग तरीके से उपयोग कर सकते हैं ।
इसका उपयोग तब किया जाता है जब मॉड्यूल के बीच कई-से-कई निर्भरता होती है। मध्यस्थ मॉड्यूल के बीच संचार में एक मध्यस्थ के रूप में कार्य करता है, एक संचार केंद्र के रूप में कार्य करता है और एक दूसरे को स्पष्ट रूप से संदर्भित करने के लिए मॉड्यूल की आवश्यकता को समाप्त करता है।
नतीजतन, एक दूसरे के साथ मॉड्यूल की बातचीत ("सभी के साथ सभी") को केवल एक मध्यस्थ ("सभी के साथ एक") के साथ मॉड्यूल की बातचीत से बदल दिया जाता है। मध्यस्थ को कई मॉड्यूल के बीच बातचीत को समाहित करने के लिए कहा जाता है।
यह तथाकथित स्मार्ट मध्यस्थ है । यह वहाँ है कि डेवलपर्स अक्सर अपनी बैसाखी जोड़ना शुरू करते हैं, जो कुछ संदेशों को चालू / बंद करके व्यक्तिगत मॉड्यूल के व्यवहार को प्रभावित करते हैं।
एक विशिष्ट वास्तविक जीवन का उदाहरण हवाई अड्डा यातायात नियंत्रण है। विमान से सभी संदेश सीधे विमान के बीच भेजे जाने के बजाय नियंत्रक के नियंत्रण टावर में जाते हैं। और नियंत्रक पहले से ही निर्णय लेता है कि कौन से विमान उड़ान भर सकते हैं या उतर सकते हैं, और बदले में, विमानों को संदेश भेज सकते हैं।
महत्वपूर्ण! मॉड्यूल एक दूसरे को न केवल साधारण संदेश भेज सकते हैं, बल्कि वस्तुओं को भी आदेश दे सकते हैं। कमांड टेम्पलेट द्वारा इस तरह की बातचीत का वर्णन किया गया है । लब्बोलुआब यह है कि एक विशिष्ट क्रिया को एक अलग वस्तु के रूप में करने के अनुरोध को समाहित करना है।
वास्तव में, इस ऑब्जेक्ट में एक एकल निष्पादन () विधि होती है, जो तब आपको एक पैरामीटर के रूप में निष्पादन के लिए अन्य मॉड्यूल के लिए इस क्रिया को पास करने की अनुमति देती है और आम तौर पर कमांड ऑब्जेक्ट के साथ कोई भी ऑपरेशन करती है जो सामान्य वस्तुओं पर किया जा सकता है।
डेमेटर का कानून
डेमेटर का कानून अंतर्निहित निर्भरताओं के उपयोग को प्रतिबंधित करता है: "ऑब्जेक्ट ए को सीधे ऑब्जेक्ट सी तक पहुंचने में सक्षम नहीं होना चाहिए यदि ऑब्जेक्ट ए के पास ऑब्जेक्ट बी तक पहुंच है और ऑब्जेक्ट बी की ऑब्जेक्ट सी तक पहुंच है।"
इसका मतलब यह है कि कोड में सभी निर्भरताएँ "स्पष्ट" होनी चाहिए - कक्षाएं / मॉड्यूल केवल अपने काम में "उनकी निर्भरता" का उपयोग कर सकते हैं और उनके माध्यम से दूसरों पर नहीं चढ़ना चाहिए। एक अच्छा उदाहरण त्रि-स्तरीय वास्तुकला है। इंटरफ़ेस लेयर को लॉजिक लेयर के साथ काम करना चाहिए, लेकिन सीधे डेटाबेस लेयर के साथ इंटरैक्ट नहीं करना चाहिए।
संक्षेप में, यह सिद्धांत भी इस तरह तैयार किया गया है: "केवल करीबी दोस्तों के साथ बातचीत करें, न कि दोस्तों के दोस्तों के साथ।" यह कोड के कम सुसंगतता के साथ-साथ इसके डिजाइन की अधिक दृश्यता और पारदर्शिता को प्राप्त करता है।
डेमेटर का कानून पहले से ही उल्लेखित "न्यूनतम ज्ञान के सिद्धांत" को लागू करता है, जो ढीले युग्मन का आधार है और इस तथ्य में शामिल है कि एक वस्तु / मॉड्यूल को अन्य वस्तुओं / मॉड्यूल की संरचना और गुणों के बारे में जितना संभव हो उतना विवरण पता होना चाहिए और सामान्य रूप से कुछ भी, इसके अपने घटकों सहित ।
जीवन से एक सादृश्य: यदि आप चाहते हैं कि कुत्ता दौड़े, तो उसके पंजे को आज्ञा देना मूर्खता है, कुत्ते को आज्ञा देना बेहतर है, और वह अपने पंजे से खुद निपट लेगी।
वंशानुक्रम के बजाय रचना
यह एक बहुत बड़ा और दिलचस्प विषय है और यह कम से कम एक अलग व्याख्यान के योग्य है। इंटरनेट पर इस विषय पर बहुत सारी प्रतियां तब तक तोड़ी गईं जब तक कि एक आम सहमति नहीं बन गई - हम वंशानुक्रम का उपयोग न्यूनतम, रचना - अधिकतम तक करते हैं।
मुद्दा यह है कि वंशानुक्रम वास्तव में वर्गों के बीच सबसे मजबूत संबंध प्रदान करता है, इसलिए इससे बचा जाना चाहिए। यह विषय हर्ब सटर के लेख " वंशानुक्रम से अधिक संरचना को प्राथमिकता दें " में अच्छी तरह से शामिल है।
जब आप डिज़ाइन पैटर्न सीखना शुरू करते हैं, तो आप पैटर्न के एक पूरे समूह में आएँगे जो किसी वस्तु या उसकी आंतरिक संरचना के निर्माण को नियंत्रित करते हैं। वैसे, मैं इस संदर्भ में डेलिगेट / डेलिगेट पैटर्न और गेम से आए कंपोनेंट पैटर्न पर ध्यान देने की सलाह दे सकता हूं ।
हम थोड़ी देर बाद पैटर्न के बारे में और बात करेंगे।