उन मामलों में निर्भरता इंजेक्शन के क्या लाभ हैं जहां लगभग सभी को एक सामान्य डेटा संरचना तक पहुंच की आवश्यकता होती है?


20

ओओपी में ग्लोबल्स बुराई के कारण बहुत सारे हैं

यदि साझाकरण की आवश्यकता वाली वस्तुओं की संख्या या आकार फ़ंक्शन मापदंडों में कुशलता से पारित होने के लिए बहुत बड़ी है, तो आमतौर पर हर कोई वैश्विक वस्तु के बजाय निर्भरता इंजेक्शन की सिफारिश करता है ।

हालांकि, इस मामले में जहां लगभग सभी को एक निश्चित डेटा संरचना के बारे में जानने की जरूरत है, डिपेंडेंसी इंजेक्शन वैश्विक वस्तु से बेहतर क्यों है?

उदाहरण (एक सरलीकृत एक, आम तौर पर बिंदु दिखाने के लिए, एक विशिष्ट अनुप्रयोग में बहुत अधिक गहराई के बिना)

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

भोला समाधान सिर्फ उनमें से एक वैश्विक कंटेनर बनाने के लिए होगा, जैसे

vector<Vehicle> vehicles;

जिसे कहीं से भी एक्सेस किया जा सकता है।

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

हालांकि, अगर अधिकांश वर्गों को कंटेनर तक पहुंच प्राप्त होगी, तो क्या यह वास्तव में एक वैश्विक से अलग है? अगर कंटेनर में कई वर्गों के डेटा की जरूरत है, तो क्या "निर्भरता इंजेक्शन तरीका" सिर्फ एक प्रच्छन्न वैश्विक नहीं है?

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


6
रुको, आप गैर-उत्परिवर्ती ग्लोबल्स के बारे में बात करते हैं और इसे सही ठहराने के लिए "वैश्विक स्थिति खराब क्यों है" के लिए एक लिंक का उपयोग करें? WTF?
तैलस्टिन

1
मैं ग्लोबल्स को बिल्कुल भी सही नहीं ठहरा रहा हूं। मुझे लगता है कि यह स्पष्ट है कि मैं इस तथ्य से सहमत हूं कि ग्लोबल्स अच्छा समाधान नहीं है। मैं सिर्फ एक ऐसी स्थिति के बारे में बात कर रहा हूं, जब निर्भरता इंजेक्शन का उपयोग करने के लिए सर्बल्स से बहुत बेहतर (या शायद लगभग अप्रभेद्य भी नहीं) हो सकता है। तो एक उत्तर इस स्थिति में निर्भरता इंजेक्शन का उपयोग करते हुए अभी भी अन्य छिपे हुए लाभों को इंगित कर सकता है, या कि अन्य दृष्टिकोण di से बेहतर होंगे
vsz

9
लेकिन केवल पठनीय और वैश्विक स्थिति के बीच एक निश्चित अंतर है।
तेलस्टिन


1
@vsz वास्तव में नहीं - सवाल कई अलग-अलग वस्तुओं की समस्या के आसपास सेवा लोकेटर कारखानों के बारे में है; लेकिन इसके उत्तर भी कक्षाओं में पारित होने वाले वैश्विक डेटा के बजाय कक्षाओं को वैश्विक डेटा तक पहुंचने की अनुमति देने के आपके प्रश्न का उत्तर देते हैं।
gbjbaanb

जवाबों:


37

उस मामले में जहां लगभग सभी को एक निश्चित डेटा संरचना के बारे में जानने की आवश्यकता है, डिपेंडेंसी इंजेक्शन वैश्विक वस्तु से बेहतर क्यों है?

कटा हुआ ब्रेड के बाद से निर्भरता इंजेक्शन सबसे अच्छी बात है , जबकि वैश्विक वस्तुओं को दशकों से सभी बुराई का स्रोत माना जाता है , इसलिए यह एक दिलचस्प सवाल है।

निर्भरता इंजेक्शन की बात बस यह सुनिश्चित करने के लिए नहीं है कि प्रत्येक अभिनेता को जो कुछ संसाधन की आवश्यकता है, वह हो सकता है, क्योंकि जाहिर है, यदि आप सभी संसाधनों को वैश्विक बनाते हैं, तो हर अभिनेता की पहुंच हर संसाधन तक होगी, समस्या हल हो जाएगी, सही?

निर्भरता इंजेक्शन की बात यह है:

  1. अभिनेताओं को आवश्यकता के आधार पर संसाधनों का उपयोग करने की अनुमति देना , और
  2. किसी भी एक्टर द्वारा किसी संसाधन का कौन सा उदाहरण एक्सेस किया जाता है, इस पर नियंत्रण रखना ।

तथ्य यह है कि आपके विशेष कॉन्फ़िगरेशन में सभी अभिनेताओं को उसी संसाधन उदाहरण तक पहुंच की आवश्यकता होती है जो अप्रासंगिक है। मेरा विश्वास करो, आपको एक दिन चीजों को फिर से कॉन्फ़िगर करने की आवश्यकता होगी ताकि अभिनेताओं के पास संसाधन के विभिन्न उदाहरणों तक पहुंच होगी, और फिर आपको एहसास होगा कि आपने खुद को एक कोने में चित्रित किया है। कुछ उत्तर पहले से ही इस तरह के कॉन्फ़िगरेशन को इंगित कर चुके हैं: परीक्षण

एक और उदाहरण: मान लीजिए कि आपने अपने एप्लिकेशन को क्लाइंट-सर्वर में विभाजित कर दिया है। क्लाइंट पर सभी कलाकार क्लाइंट पर केंद्रीय संसाधनों के एक ही सेट का उपयोग करते हैं, और सर्वर पर सभी कलाकार सर्वर पर केंद्रीय संसाधनों के एक ही सेट का उपयोग करते हैं। अब मान लीजिए, एक दिन, कि आप अपने क्लाइंट-सर्वर एप्लिकेशन का "स्टैंडअलोन" संस्करण बनाने का निर्णय लेते हैं, जहां क्लाइंट और सर्वर दोनों एक ही निष्पादन योग्य और एक ही वर्चुअल मशीन में चल रहे हैं। (या अपनी पसंद की भाषा के आधार पर रनटाइम वातावरण।)

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

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

फिर, आपको विचार करना होगा: क्या सभी अभिनेताओं को वास्तव में उस संसाधन तक पहुंच की आवश्यकता है? वास्तव में?

यह संभव है कि आपने उस संसाधन को देव वस्तु में बदलने की गलती की हो, (इसलिए, निश्चित रूप से सभी को उस तक पहुंच की आवश्यकता है) या शायद आप अपनी परियोजना में उन अभिनेताओं की संख्या को बहुत कम कर रहे हैं जिन्हें वास्तव में उस संसाधन तक पहुंच की आवश्यकता है ।

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

  • छोटे उप-संसाधनों में उस बड़े बड़े विशाल ईश्वर संसाधन को रिफ्लेक्टर करता है, इसलिए विभिन्न अभिनेताओं को इसके विभिन्न टुकड़ों तक पहुंच की आवश्यकता होती है, लेकिन शायद ही किसी अभिनेता को इसके सभी टुकड़ों की आवश्यकता होती है, या

  • अपने अभिनेताओं को बदले में, केवल उस समस्या के सबसेट के मापदंडों के रूप में स्वीकार करते हैं, जिस पर उन्हें काम करने की आवश्यकता होती है, इसलिए उन्हें हर समय कुछ बड़े बड़े केंद्रीय संसाधनों से परामर्श करने की आवश्यकता नहीं होती है।


मुझे यकीन नहीं है कि मैं यह समझता हूं - एक तरफ आप कहते हैं कि DI आपको एक संसाधन के कई उदाहरणों का उपयोग करने की अनुमति देता है और ग्लोबल्स नहीं है, जो स्पष्ट रूप से बकवास है जब तक कि आप बहु-त्वरित वस्तुओं के खिलाफ एक एकल स्थिर चर का सामना नहीं कर रहे हैं - कोई कारण नहीं है वह "वैश्विक" या तो एकल उदाहरण या एकल वर्ग होना चाहिए।
gbjbaanb 14

3
@gbjbaanb मान लीजिए कि संसाधन एक Zork है। ओपी कह रहा है कि उसके सिस्टम में हर एक ऑब्जेक्ट को काम करने के लिए Zork की जरूरत नहीं है, बल्कि यह भी है कि केवल एक Zork ही मौजूद रहेगा, और यह कि उसकी सभी वस्तुओं को केवल Zork के उस एक उदाहरण तक पहुंच की आवश्यकता होगी। मैं कह रहा हूं कि इन दोनों में से कोई भी धारणा उचित नहीं है: यह शायद सच नहीं है कि उसकी सभी वस्तुओं को एक ज़ोर्क की आवश्यकता होती है, और कई बार कुछ वस्तुओं को ज़ोर्क के एक निश्चित उदाहरण की आवश्यकता होगी, जबकि अन्य वस्तुओं की आवश्यकता होगी Zork के विभिन्न उदाहरण।
माइक नाकिस

2
@ GBjbaanb मुझे नहीं लगता कि आप मुझे यह बताने के लिए कह रहे हैं कि यह बेवकूफ के दो वैश्विक उदाहरण क्यों होंगे, उन्हें ZorkA और ZorkB नाम दें, और हार्ड-कोड को उन वस्तुओं में शामिल करें, जो ZorkA का उपयोग करेंगे और जो ZorkB का उपयोग करेंगे। सही?
माइक नाकीस

1
मैंने सभी को नहीं कहा, मैंने लगभग सभी को कहा । सवाल का मुद्दा यह था कि क्या डीआई के पास उन कुछ अभिनेताओं तक पहुंच से इनकार करने के अलावा अन्य लाभ हैं जिन्हें इसकी आवश्यकता नहीं है। मुझे पता है कि "देव वस्तुएं" एक विरोधी पैटर्न हैं, लेकिन आँख बंद करके सर्वोत्तम प्रथाओं का पालन भी किया जा सकता है। ऐसा हो सकता है कि एक कार्यक्रम का पूरा उद्देश्य एक निश्चित संसाधन के साथ विभिन्न चीजें करना है, उस स्थिति में लगभग सभी को उस संसाधन तक पहुंच की आवश्यकता होती है। एक अच्छा उदाहरण एक प्रोग्राम होगा जो एक छवि पर काम करता है: इसमें लगभग सब कुछ छवि डेटा के साथ कुछ करना है।
vsz

1
@gbjbaanb मेरा मानना ​​है कि विचार यह है कि एक ग्राहक वर्ग विशेष रूप से या तो ZorkA या ZorkB पर काम करने में सक्षम है, ग्राहक वर्ग को यह तय करने के लिए नहीं कि उनमें से किसको हथियाना है।
यूजीन रयबत्सेव

39

ओओपी में गैर-उत्परिवर्ती ग्लोबल्स बुराई के कारण बहुत सारे हैं।

यह एक संदिग्ध दावा है। सबूत के रूप में आप जिस लिंक का उपयोग करते हैं, वह राज्य - म्यूटेबल ग्लोबल्स को संदर्भित करता है । वे निश्चित रूप से बुरे हैं। केवल ग्लोबल्स पढ़ें केवल स्थिरांक हैं। स्थिर अपेक्षाकृत स्थिर होते हैं। मेरा मतलब है, आप अपने सभी वर्गों में पाई के मूल्य को इंजेक्ट नहीं करेंगे, क्या आप करेंगे?

यदि साझाकरण की आवश्यकता वाली वस्तुओं की संख्या या आकार फ़ंक्शन मापदंडों में कुशलता से पारित होने के लिए बहुत बड़ी है, तो आमतौर पर हर कोई वैश्विक वस्तु के बजाय निर्भरता इंजेक्शन की सिफारिश करता है।

नहीं, वे नहीं करते।

यदि आपके कार्यों / कक्षाओं में बहुत अधिक निर्भरताएँ हैं, तो लोग आपको रोकने और एक नज़र लेने की सलाह देते हैं कि आपका डिज़ाइन इतना खराब क्यों है। आश्रितों की नाव पर चढ़ना इस बात का संकेत है कि आपका वर्ग / कार्य संभवतः बहुत अधिक कार्य कर रहा है और / या आपके पास पर्याप्त अमूर्तता नहीं है।

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

यह एक डिजाइन बुरा सपना है। आपके पास सामान का एक गुच्छा है जिसका उपयोग किया जा सकता है / सत्यापन के किसी भी तरीके के साथ दुर्व्यवहार नहीं किया जा सकता है, संगामिति सीमाओं का कोई तरीका नहीं है - यह सिर्फ मेरे ऊपर युग्मन है।

हालांकि, अगर अधिकांश वर्गों को कंटेनर तक पहुंच प्राप्त होगी, तो क्या यह वास्तव में एक वैश्विक से अलग है? अगर कंटेनर में कई वर्गों के डेटा की जरूरत है, तो क्या "निर्भरता इंजेक्शन तरीका" सिर्फ एक प्रच्छन्न वैश्विक नहीं है?

हां, हर जगह आम डेटा के लिए युग्मन एक वैश्विक से बहुत अलग नहीं है, और इस तरह, अभी भी बुरा है।

उल्टा यह है कि आप उपभोक्ताओं को वैश्विक चर से ही अलग कर रहे हैं। यह आपको कुछ लचीलापन प्रदान करता है कि उदाहरण कैसे बनाया जाता है। यह आपको केवल एक उदाहरण के लिए बाध्य नहीं करता है । आप अपने अलग-अलग उपभोक्ताओं को अलग-अलग कर सकते हैं। तब आपको प्रति उपभोक्ता को अपने इंटरफ़ेस के अलग-अलग क्रियान्वयन भी करने चाहिए।

और परिवर्तन के कारण जो अनिवार्य रूप से सॉफ्टवेयर की स्थानांतरण आवश्यकताओं के साथ आता है, लचीलापन का ऐसा बुनियादी स्तर महत्वपूर्ण है


"नॉन-म्यूटेबल" के साथ भ्रम के लिए खेद है, मैं उत्परिवर्तित कहना चाहता था, और किसी तरह मेरी गलती को पहचान नहीं पाया।
vsz

"यह एक बुरा सपना है" - मुझे पता है कि यह है। लेकिन यदि आवश्यकताएं यह हैं कि उन सभी घटनाओं को डेटा में परिवर्तन करने में सक्षम होना चाहिए, तो इवेंट्स को डेटा से युग्मित किया जाएगा, भले ही मैं विभाजन की एक परत के तहत उन्हें विभाजित और छिपा दूं। पूरा कार्यक्रम इस डेटा के बारे में है । उदाहरण के लिए, यदि किसी प्रोग्राम को किसी छवि पर बहुत सारे अलग-अलग ऑपरेशन करने पड़ते हैं, तो उसकी सभी या लगभग सभी कक्षाओं को किसी न किसी तरह से इमेज डेटा से जोड़ दिया जाएगा। सिर्फ यह कहना "चलो एक प्रोग्राम लिखें जो कुछ अलग करता है" स्वीकार्य नहीं है।
19

2
कई ऑब्जेक्ट्स जो कुछ डेटाबेस को नियमित रूप से एक्सेस करते हैं, वे बिल्कुल अभूतपूर्व नहीं हैं।
रॉबर्ट हार्वे

@RobertHarvey - यकीन है, लेकिन क्या वे "एक डेटाबेस का उपयोग कर सकते हैं" या "कुछ निरंतर डेटा स्टोर के लिए" पर निर्भर है foo?
20

1
एक दिलबर्ट की याद दिलाता है जहाँ PHB 500 सुविधाएँ मांगता है और दिलबर्ट कहते हैं कि नहीं। तो PHB 1 सुविधा मांगता है और दिलबर्ट निश्चित रूप से कहता है। अगले दिन दिलबर्ट को प्रत्येक सुविधा के लिए 500 अनुरोध मिले। अगर कुछ पैमाने पर नहीं है, तो यह कोई फर्क नहीं पड़ता कि आप इसे कैसे पहनते हैं।
corsiKa

16

तीन मुख्य कारण हैं जिन पर आपको विचार करना चाहिए।

  1. पठनीयता। यदि कोड की प्रत्येक इकाई में वह सब कुछ है जो उसे इंजेक्ट करने या पैरामीटर के रूप में पारित करने की आवश्यकता है, तो कोड को देखना आसान है और तुरंत देखें कि यह क्या कर रहा है। यह आपको फ़ंक्शन का एक क्षेत्र प्रदान करता है, जो आपको बेहतर चिंताओं को अलग करने में सक्षम बनाता है और आपको सोचने के लिए मजबूर करता है ...
  2. प्रतिरूपकता। पार्सर को वाहनों की पूरी सूची और उनके सभी गुणों के बारे में क्यों पता होना चाहिए? यह शायद नहीं है। हो सकता है कि यह क्वेरी करने की आवश्यकता है कि क्या एक वाहन आईडी मौजूद है या क्या वाहन X में संपत्ति Y. ग्रेट है, इसका मतलब है कि आप एक सेवा लिख ​​सकते हैं जो ऐसा करती है, और केवल उस सेवा को अपने पार्सर में इंजेक्ट करें। अचानक आप एक ऐसे डिज़ाइन के साथ समाप्त होते हैं जो कहीं अधिक समझ में आता है, हर बिट कोड के साथ केवल उस डेटा को संभालना जो उसके लिए प्रासंगिक है। जो हमें ले जाता है ...
  3. Testability। एक विशिष्ट इकाई परीक्षण के लिए आप कई अलग-अलग परिदृश्यों के लिए अपना वातावरण स्थापित करना चाहते हैं और इंजेक्शन इसे लागू करना बहुत आसान बनाता है। फिर से, पार्सर के उदाहरण पर लौटते हुए, क्या आप हमेशा अपने पार्सर के लिए लिखने वाले हर टेस्ट केस के लिए पूरी तरह से विकसित वाहनों की पूरी सूची को हस्त-शिल्प करना चाहते हैं? या आप केवल उपरोक्त सेवा की वस्तु का एक नकली कार्यान्वयन बना सकते हैं, अलग-अलग आईडी की संख्या लौटाएंगे? मुझे पता है कि मैं किसे चुनूंगा।

तो इसे योग करने के लिए: DI एक लक्ष्य नहीं है, यह सिर्फ एक उपकरण है जो एक लक्ष्य को प्राप्त करना संभव बनाता है। यदि आप इसका दुरुपयोग करते हैं (जैसे यह प्रतीत होता है कि आप अपने उदाहरण में करते हैं), तो आपको लक्ष्य के करीब नहीं मिलेगा, डीआई की कोई जादुई संपत्ति नहीं है जो खराब डिजाइन को अच्छा बना देगा।


रखरखाव के मुद्दों पर केंद्रित संक्षिप्त जवाब के लिए +1। अधिक पी: एसई उत्तर इस तरह होना चाहिए।
dodgethesteamroller

1
आपका योग कितना अच्छा है। सूo अच्छा। अगर आपको लगता है कि [महीने का डिज़ाइन पैटर्न] या [महीने का buzzword] जादुई रूप से आपकी समस्याओं को हल कर देगा तो आपके पास बुरा समय होगा।
corsiKa

@corsiKa I लंबे समय तक DI (या स्प्रिंग, अधिक सटीक होने के लिए) का विरोधी था क्योंकि मैं इसके बिंदु को नहीं देख सकता था। यह बिना किसी ठोस लाभ के एक भयानक परेशानी की तरह लग रहा था (यह एक्सएमएल कॉन्फ़िगरेशन दिनों में वापस आ गया था)। काश मुझे कुछ दस्तावेज़ीकरण मिला होता, जो डीआई वास्तव में आपको वापस खरीदता है। लेकिन मैंने ऐसा नहीं किया, इसलिए मुझे इसका पता लगाना पड़ा। इसमें बहुत समय लगा। :)
बाइज़िकलॉप

3

परीक्षण क्षमता के बारे में वास्तव में - आमतौर पर एक वैश्विक वस्तु बहुत ही रख-रखाव और पढ़ने / समझने में आसान है (एक बार जब आप इसके बारे में जानते हैं, तो निश्चित रूप से) लेकिन यह एक स्थायी स्थिरता है और जब आप अपनी कक्षाओं को अलग-अलग परीक्षणों में विभाजित करते हैं, तो आप पाते हैं कि आपका वैश्विक वस्तु यह कहते हुए अटक गई है कि "मेरे बारे में क्या" और इस प्रकार आपके अलग-थलग परीक्षणों के लिए वैश्विक वस्तु को उनमें शामिल करने की आवश्यकता है। यह मदद नहीं करता है कि अधिकांश परीक्षण ढांचे आसानी से इस परिदृश्य का समर्थन नहीं करते हैं।

तो हाँ, यह अभी भी एक वैश्विक है। यह होने का मूल कारण नहीं बदला है, केवल जिस तरीके से इसे एक्सेस किया गया है।

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

इन सब के बावजूद, इसका एक उदाहरण 'पूंछ वैगिंग द डॉग' है, परीक्षण करने की आवश्यकता यह है कि कोडबेस को कैसे आर्किटेक्चर किया जाता है (इसी तरह की समस्याएं जैसे स्थैतिक कक्षाएं, जैसे वर्तमान डेटाइम)।

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


"आम तौर पर एक वैश्विक वस्तु बहुत बनाए रखने योग्य है" - न कि अगर यह परस्पर है। मेरे अनुभव में, इतना अधिक परिवर्तनशील वैश्विक स्थिति होना एक बुरा सपना हो सकता है (हालांकि इसे सहने योग्य बनाने के तरीके हैं)।
साल्स्के

3

पहले से ही आपके पास उत्तर के अलावा,

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

ओओपी प्रोग्रामिंग की एक विशेषता केवल एक विशिष्ट वस्तु के लिए आवश्यक गुणों को रखना है,

अब यदि आपकी वस्तु में बहुत अधिक गुण हैं - आपको अपनी वस्तु को उप-वस्तुओं में और नीचे तोड़ देना चाहिए।

संपादित करें

पहले ही उल्लेख किया गया है कि वैश्विक वस्तुएं खराब क्यों हैं, मैं इसमें एक उदाहरण जोड़ूंगा।

आपको विंडोज़ फॉर्म के GUI कोड पर यूनिट टेस्टिंग करने की ज़रूरत है, यदि आप ग्लोबल का उपयोग करते हैं, तो आपको सभी बटन बनाने की आवश्यकता होगी और उदाहरण के लिए यह एक उचित टेस्ट केस बनाने के लिए ईवेंट्स हैं ...


सच है, लेकिन उदाहरण के लिए, किसी भी आदेश के कारण पार्सर को सब कुछ जानना आवश्यक होगा, जो किसी भी चीज में परिवर्तन कर सकता है।
vsz

1
"इससे पहले कि मैं आपके वास्तविक प्रश्न पर आता हूं" ... क्या आप उसके प्रश्न का उत्तर देने जा रहे हैं?
gbjbaanb

@ जीबीजैनब प्रश्न में बहुत पाठ मिला है, कृपया मुझे इसे पढ़ने के लिए कुछ समय दें, ठीक से
गणित
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.