मैं विंडसर आईओसी/डी ढांचे का उपयोग करके कुछ कोड दोबारा प्रतिक्रिया देना चाहता हूं, लेकिन मेरी समस्या यह है कि मेरे पास कुछ सिंगलटन कक्षाएं और फैक्ट्री पैटर्न कक्षाएं हैं और मुझे यकीन नहीं है कि कोई सिंगलटन या डीआई का उपयोग कर फैक्टरी।एक कार्यान्वयन में डी और सिंगलटन पैटर्न
क्या कोई भी विचार है यदि यह संभव है और कैसे?
सिंगलटन डिज़ाइन पैटर्न DI के साथ बाधाओं पर है। हालांकि सिंगलटन को खोलना संभव है कि DI और Open/Closed Principle समझने लगते हैं, यह सिंगलटन को इतना बदल देगा कि यह लगभग सिंगलटन होने से रोकता है।
थ्रेड सुरक्षा एक बड़ी समस्या है जो कि जब आप सिंगलटन खोलना शुरू करते हैं तो दिमाग में आता है।
अपने दायरे पर विचार किए बिना बस अपनी सेवाओं और कक्षाओं को परिभाषित करना बेहतर है। यदि आपके पास एक ऑब्जेक्ट है जिसे आप एकाधिक उपभोक्ताओं के बीच साझा करना चाहते हैं, तो अधिकांश डी कंटेनरों में सिंगलटन आजीवन की अवधारणा है, जो किसी भी कमी से पीड़ित बिना सिंगलटन डिज़ाइन पैटर्न के लाभों की नकल करता है।
संक्षेप में: सिंगलेट्स बुरा हैं और उन्हें टालना चाहिए।
Abstract Factory दूसरी ओर, बहुत DI प्रयोजनों के लिए उपयोगी है।
आप नहीं करते हैं, आपने आईओसी कंटेनर को ऐसा करने दिया है। किसी ऑब्जेक्ट के सिंगलटन इंस्टेंस को प्राप्त करने के लिए आपके पास फैक्ट्री को स्पष्ट कॉल करने से पहले, अब आपके पास आईओसी कंटेनर आपके लिए ऑब्जेक्ट्स का ग्राफ बनाता है, और यह सबकुछ ऊपर रखता है जहां यह संबंधित है। कंटेनर सुनिश्चित करता है कि आपके सिंगलेट्स सिंगलेट हैं, और यह कारखाने के रूप में कार्य करता है।
यदि आप किसी कारखाने को चलाने के बारे में बात कर रहे हैं, तो किस प्रकार की वस्तु को पूरा करने के लिए, डीआई लागू नहीं है, सिवाय इसके कि आप डी कंटेनर कारखाने को इंजेक्ट कर सकते हैं जहां आप इसे चाहते हैं और इसके लिए अपना दायरा प्रबंधित कर सकते हैं ।
क्या आईओसी ढांचे में यह तय करने की क्षमता नहीं है कि कौन सा ऑब्जेक्ट रनटाइम पर सेवा करेगा? तो DI का उपयोग करते समय कारखाने का उपयोग क्यों करें? मैं एक ही या समान वर्गों के कई उदाहरण बनाने के लिए एक कारखाने का उपयोग करता हूं ... –
मेरा मतलब है कि आईओसी का उपयोग करते समय, 'डीआई का उपयोग नहीं' –
आमतौर पर आईओसी फ्रेमवर्क बहुत स्थिर हैं, वे कॉन्फ़िगरेशन (xml, एनोटेशन, प्रॉपर्टी फाइलें, जो भी हो), तो नहीं, फ्लाई पर क्या बनाना है यह तय करने की ज्यादा क्षमता नहीं है। –
अधिकांश आधुनिक निर्भरता इंजेक्शन ढांचे आपको यह निर्दिष्ट करने की अनुमति देते हैं कि उन्हें एप्लिकेशन के जीवन (या अनुरोध) के लिए एक ऑब्जेक्ट इंस्टेंस की सेवा करनी चाहिए या हर बार जब आप एक के लिए पूछते हैं तो नए उदाहरण बना सकते हैं।
आप उचित होने पर कारखानों पर निर्भरताओं को हल करने के लिए डीआई फ्रेमवर्क का भी उपयोग कर सकते हैं (यदि आपका मतलब है)। यदि आप कारखाने रनटाइम डेटा के आधार पर उप-वर्ग का चयन करते हैं, या यदि किसी आश्रित ऑब्जेक्ट को कई IFoo उदाहरण बनाने की आवश्यकता है, तो आप ऐसा कर सकते हैं, इस मामले में आप IFooFactory इंजेक्ट कर सकते हैं।
मेरा मतलब फैक्ट्री का उपयोग करके एक निश्चित वर्ग के कई उदाहरण बनाने के बाद है, फिर कारखाने को किसी वर्ग में इंजेक्ट करना है। –
सिंगलेट्स कुछ ऐसा है जो मैं अक्सर उपयोग करता हूं, लेकिन इसे पढ़ रहा है, ऐसा लगता है कि मुझे अपनी रणनीति बदलनी होगी! मैंने उन्हें कुछ स्थितियों में काफी उपयोगी पाया ... लेकिन मैं देख सकता हूं कि आप थ्रेड सुरक्षा से कहां से आ रहे हैं। –
थ्रेड सुरक्षा एक बात है, लेकिन मुख्य समस्या ओपन/क्लोज़ड सिद्धांत का उल्लंघन है। –
यदि मैं एक सिंगलटन के दायरे को प्रबंधित करने के लिए एक डी कंटेनर का उपयोग करता हूं तो वह ओसीपी का उल्लंघन क्यों करता है? क्योंकि मैं कार्यान्वयन के लिए स्थैतिक तरीकों पर भरोसा नहीं करता हूं, फिर भी मैं इसे उपclass कर सकता हूं, मुझे लगता है कि सिंगलटन के लिए एक डी कंटेनर का उपयोग करने से मुझे ओसीपी को संरक्षित करने की सुविधा मिलती है। ? –