आईओसी का उपयोग कब उपयुक्त है?

Question

मैं समझता हूं कि आईओसी कंटेनर क्या हैं और संरचना मानचित्र पर पढ़ रहे हैं। तकनीक का उपयोग करने के लिए काफी आसान लगता है। मेरा सवाल है, आईओसी कंटेनर का उपयोग करने के लिए ग्रैन्युलरिटी का उचित स्तर क्या है?

मैं आईओसी के लिए आवेदन की निम्नलिखित संभव स्तर देखें:

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

मुझे पता है कि इस प्रश्न का उत्तर "यह निर्भर करता है", लेकिन आपके अनुभव से, फिर उत्तर किस पर निर्भर करता है? क्या परियोजना का आकार एक कारक है?

इसके अलावा, आईओसी उपयोग करने के लिए समझ में नहीं आता है?

Answer 1

विचार डोमेन ऑब्जेक्ट्स के बीच निर्भरताओं को तोड़ना नहीं है, यह आपके डोमेन को बाहरी दुनिया से ढालना है। आपके डोमेन ऑब्जेक्ट्स जो भी व्यावसायिक समस्या आप हल कर रहे हैं, उसके बारे में होना चाहिए, डेटाबेस, लॉगिंग, कैशिंग, http संदर्भ, बाकी सेवाओं आदि के बारे में नहीं होना चाहिए ...

यह आलेख आपकी ऑब्जेक्ट्स और आईओसी कंटेनर में जिम्मेदारियों को आगे बढ़ाने के बारे में बात करता है।

http://www.agileatwork.com/captcha-and-inversion-of-control/

Answer 2

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

छोटी परियोजनाओं या परियोजनाओं पर आईओसी का उपयोग करने के लिए यह समझ में नहीं आता है कि बड़े पैमाने पर decoupling की आवश्यकता नहीं है।

Answer 3

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

Answer 4

आईओसी के लिए एक परिदृश्य तब होता है जब विकास टीम के बीच एक विशिष्ट कार्यान्वयन निर्णय लिया जाता है। आईओसी न्यूनतम घर्षण के साथ कार्यान्वयन को स्वैप करने में सक्षम होने की लचीलापन देता है। यह किसी भी चीज़ से सामरिक विचार से अधिक है।

Answer 5

आप एक बहुत ठोस घटक कार्यान्वयन पास अनेक प्रकार के नहीं होगा कि प्रोग्रामिंग कर रहे हैं तो ठीक है, आईओसी भावना का एक बहुत नहीं है ...

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