आप कैसे निर्धारित करते हैं कि एक आईओसी कंटेनर के माध्यम से कौन से वर्गों का निर्माण किया जाना चाहिए, और कौन से नहीं होना चाहिए। मैंने दोनों चरम सीमाओं के साथ परियोजनाओं पर काम किया है और ऐसा लगता है कि इंटरफेस का उपयोग केवल तभी किया जाना चाहिए जब कक्षाएं एक विशिष्ट टेक्नोलॉजी जैसे लॉगिंग या डेटा एक्सेस निर्दिष्ट करती हैं?आईओसी कंटेनर के माध्यम से क्या बनाया जाना चाहिए?
लोग दोनों के बीच की रेखा कहां खींचते हैं?
मैं किसी भी रेखा को आकर्षित नहीं करता - अधिक, मर्फी।
क्या होता है कि आप अपने एपीआई को छोटी इकाइयों में विभाजित करने के लिए जितना अधिक प्रबंधित कर सकते हैं, उतना ही आप Single Responsibility Principle पर पहुंच सकते हैं, क्योंकि इंटरफ़ेस के पीछे छिपी हुई सभी चीज़ों में केवल एक चीज करने की प्रवृत्ति होगी, और इसे करें कुंआ।
कार्यान्वयन में इंटरफेस इंजेक्शन करके जो अन्य प्रकारों में इंजेक्शन वाले नए इंटरफेस को लागू करते हैं, आदि। आप एक बहुत ही लचीली संरचना के साथ समाप्त होते हैं जहां आप लगभग किसी भी स्तर पर कार्यान्वयन विवरण बदल सकते हैं, और प्रत्येक सहयोगी अपने आप में बहुत ही सरल है।
एक अच्छा डी कंटेनर और कुछ समझदार सम्मेलनों के साथ, डी कंटेनर स्वचालित रूप से आपके लिए अधिकांश तारों का ख्याल रखेगा, इसलिए कॉन्फ़िगरेशन चरम नहीं होना चाहिए।
स्पष्ट रूप से, यह विश्वास करना मुश्किल है कि इस तरह की सलाह गंभीर है। यह मार्टिन फाउलर द्वारा डी पर मूल लेख के पीछे इरादे से पूरी तरह से विरोध करता है। इसके अलावा, पहले से ही "एक इंटरफ़ेस के पीछे छिपा हुआ" वर्ग का कार्यान्वयन: कक्षा का सार्वजनिक इंटरफ़ेस स्वयं! मेरा मतलब है, इसके लिए एक अलग इंटरफ़ेस की आवश्यकता नहीं है। (या क्या आपका मतलब "इंटरफेस" का मतलब है?) ज्यादातर मामलों में, आपको कॉन्फ़िगरेशन के माध्यम से "कार्यान्वयन विवरण बदलना" की आवश्यकता नहीं होती है - डिफ़ॉल्ट रूप से ऐसा करना अति डिज़ाइन होता है, और DI की वास्तविक भावना के विपरीत होता है। –
@Rogerio: सलाह गंभीर है, और मैं वर्षों से बड़ी सफलता के साथ इस सिद्धांत का उपयोग कर रहा हूं। जबकि मैं फाउलर का सम्मान करता हूं, हमें उसे हर शब्द को पवित्रशास्त्र के रूप में नहीं लेना पड़ता है। एक वेब सर्च करें और पता लगाएं कि अत्याधुनिक .NET समुदाय डीओ पर फाउलर और अंकल बॉब के विचारों के बारे में सोचता है। फिर आप अपना दिमाग बदल सकते हैं। –
@ मार्क: ठीक है, हर शब्द "शास्त्र के रूप में" लेने की आवश्यकता नहीं है, लेकिन यहां मौलिक सिद्धांत, जो डी और "सेवा लोकेटर" पैटर्न दोनों के लिए आम है, "उपयोग से अलग विन्यास" है। आईएमओ, जब लोग उस कॉन्फ़िगरेशन की वास्तविक आवश्यकता के बिना DI (या ServiceLocator) का उपयोग करते हैं, तो वे इसका दुरुपयोग कर रहे हैं। और ऐसे दुर्व्यवहार, जैसे कि गोफ पैटर्न (जो बहुत कुछ होता है) के दुरुपयोग की तरह, वास्तविक परियोजनाओं में कुछ गंभीर नुकसान पहुंचाता है, बिना किसी ठोस लाभ के विकास और रखरखाव लागत में वृद्धि।जब मैं इस तरह की "कट्टरपंथी" सलाह ("अधिक, मर्फी") देखता हूं तो यही मुझे चिंतित करता है। –
डीई कंटेनर द्वारा तत्काल होने वाली कक्षाएं (माना जाता है कि एक का उपयोग किया जाता है) उन लोगों को होना चाहिए जो Separated Interface को कार्यान्वित करते हैं, और निष्पादन वातावरण के आधार पर रनटाइम पर चयन करने की आवश्यकता होती है।
आप तब पूछ सकते हैं: कौन से वर्गों को अलग इंटरफ़ेस लागू करना चाहिए, और कौन नहीं चाहिए? वहाँ मूलतः एक नया अलग इंटरफेस बनाने के लिए दो कारण हैं:
संदर्भ के लिए, देखें: http://martinfowler.com/articles/injection.html#SeparatingConfigurationFromUse
डि। सब कुछ। हमेशा। इसलिये। – Aaronaught