परिपत्र संदर्भों में क्या गलत है?


160

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

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

संपादित करें: मैं सम-विषम परिपत्र संदर्भों के बारे में नहीं पूछ रहा हूं, जैसे कि एक डबल-लिंक्ड सूची या पॉइंटर-टू-पैरेंट में। यह प्रश्न वास्तव में "बड़े दायरे" परिपत्र संदर्भों के बारे में पूछ रहा है, जैसे कि libA कॉलिंग libB जो liba को वापस बुलाता है। यदि आप चाहें तो 'मॉड्यूल' को 'पसंद' के लिए रखें। अब तक के सभी उत्तर के लिए धन्यवाद!


क्या पुस्तकालयों और हेडर फ़ाइलों से संबंधित परिपत्र संदर्भ है? वर्कफ़्लो में, नया प्रोजेक्टबी कोड एक फाइल को संसाधित करेगा जो कि लीगेसी प्रोजेक्टए कोड से आउटपुट है। ProjectA से यह आउटपुट ProjectB द्वारा संचालित एक नई आवश्यकता है; ProjectB में एक कोड होता है जो सामान्य रूप से यह निर्धारित करने की सुविधा देता है कि कौन से क्षेत्र कहाँ जाते हैं, आदि बिंदु, विरासत प्रोजेक्टा नए ProjectB में कोड का पुन: उपयोग कर सकता है , और ProjectB विरासत प्रोजेक्ट में उपयोगिता कोड का पुन: उपयोग न करने के लिए मूर्खतापूर्ण होगा (उदाहरण के लिए: वर्ण सेट पहचान और ट्रांसकोडिंग, रिकॉर्ड पार्सिंग, डेटा सत्यापन और परिवर्तन, आदि)।
Luv2code

1
@ Luv2code यह केवल तभी मूर्खतापूर्ण हो जाता है जब आप परियोजनाओं के बीच कोड को काटते और चिपकाते हैं या संभवतः जब दोनों परियोजनाएं एक ही कोड में संकलित और लिंक करती हैं। यदि वे इस तरह के संसाधनों को साझा कर रहे हैं, तो उन्हें एक पुस्तकालय में डालें।
डैश-टॉम-बैंग

जवाबों:


220

वहाँ एक महान हैं कई चीजें वृत्तीय संदर्भ के साथ गलत:

  • परिपत्र वर्ग के संदर्भ उच्च युग्मन बनाते हैं ; दोनों वर्गों हर बार कंपाइल किया जाना चाहिए या तो उनमें से बदला गया है।

  • परिपत्र विधानसभा संदर्भ स्थिर लिंकिंग को रोकते हैं , क्योंकि बी ए पर निर्भर करता है लेकिन बी को पूरा होने तक ए को इकट्ठा नहीं किया जा सकता है।

  • परिपत्र वस्तु संदर्भ स्टैक ओवरफ्लो के साथ भोले पुनरावर्ती एल्गोरिदम (जैसे धारावाहिक, आगंतुक और सुंदर-प्रिंटर) को क्रैश कर सकते हैं । अधिक उन्नत एल्गोरिदम में चक्र का पता लगाया जाएगा और केवल अधिक वर्णनात्मक अपवाद / त्रुटि संदेश के साथ विफल हो जाएगा।

  • परिपत्र वस्तु संदर्भ भी निर्भरता इंजेक्शन को असंभव बनाते हैं , आपके सिस्टम की परीक्षण क्षमता को काफी कम करते हैं।

  • एक बहुत बड़ी संख्या में परिपत्र संदर्भ वाली वस्तुएं अक्सर देव वस्तुएं होती हैं । यहां तक ​​कि अगर वे नहीं हैं, तो उनके पास स्पेगेटी कोड का नेतृत्व करने की प्रवृत्ति है ।

  • परिपत्र इकाई संदर्भ (विशेष रूप से डेटाबेस में, लेकिन डोमेन मॉडल में भी) गैर-अशक्तता अवरोधों के उपयोग को रोकते हैं , जिससे अंततः डेटा भ्रष्टाचार या कम से कम असंगति हो सकती है।

  • सामान्य रूप से परिपत्र संदर्भ बस भ्रामक होते हैं और यह समझने का प्रयास करते समय संज्ञानात्मक भार में काफी वृद्धि होती है कि प्रोग्राम कैसे कार्य करता है।

कृपया, बच्चों के बारे में सोचें; जब भी आप कर सकते हैं परिपत्र संदर्भ से बचें।


32
मैं विशेष रूप से अंतिम बिंदु की सराहना करता हूं, "संज्ञानात्मक भार" एक ऐसी चीज है जिसके बारे में मैं बहुत सचेत हूं, लेकिन इसके लिए एक महान संक्षिप्त शब्द नहीं था।
डैश-टॉम-बैंग

6
अच्छा उत्तर। परीक्षण के बारे में कुछ कहा जाए तो बेहतर होगा। यदि मॉड्यूल ए और बी परस्पर निर्भर हैं, तो उन्हें एक साथ परीक्षण किया जाना चाहिए। इसका मतलब है कि वे वास्तव में अलग मॉड्यूल नहीं हैं; साथ में वे एक टूटे हुए मॉड्यूल हैं।
केविन क्लाइन

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

3
@ BlueRaja-DannyPflughoeft: मेरा मानना ​​है कि एक विरोधी पैटर्न, जैसा कि DI के कई अन्य चिकित्सक करते हैं, क्योंकि (ए) यह स्पष्ट नहीं है कि एक संपत्ति वास्तव में एक निर्भरता है, और (बी) ऑब्जेक्ट को "इंजेक्ट" आसानी से नहीं किया जा सकता है। अपने स्वयं के आक्रमणकारियों पर नज़र रखें। इससे भी बदतर, कैसल विंडसर जैसे कई सबसे परिष्कृत / लोकप्रिय ढांचे उपयोगी त्रुटि संदेश नहीं दे सकते हैं यदि एक निर्भरता को हल नहीं किया जा सकता है; आप एक कष्टप्रद अशक्त संदर्भ के साथ अंत में एक विस्तृत विवरण के बजाय अंत में निर्भरता जिसमें निर्माणकर्ता को हल नहीं किया जा सकता है। सिर्फ इसलिए कि आप कर सकते हैं , इसका मतलब यह नहीं है कि आपको चाहिए
एरॉन को

3
मैं यह दावा नहीं कर रहा था कि यह एक अच्छा अभ्यास है, मैं सिर्फ इशारा कर रहा था कि यह असंभव नहीं है जैसा कि उत्तर में दावा किया गया है।
ब्लूराजा - डैनी पफ्लुगुएफ्ट

22

एक परिपत्र संदर्भ एक गैर-परिपत्र संदर्भ के युग्मन से दोगुना है।

यदि फू को बार के बारे में पता है, और बार को फू के बारे में पता है, तो आपके पास दो चीजें हैं जिन्हें बदलने की आवश्यकता है (जब आवश्यकता आती है कि फोस और बार्स को अब एक दूसरे के बारे में पता नहीं होना चाहिए)। यदि फू बार के बारे में जानता है, लेकिन एक बार फू के बारे में नहीं जानता है, तो आप बार को छुए बिना फू को बदल सकते हैं।

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


17

जब आप कोड के दो बिट्स को एक साथ जोड़ते हैं, तो आपके पास प्रभावी रूप से कोड का एक बड़ा टुकड़ा होता है। थोड़ा कोड बनाए रखने की कठिनाई कम से कम इसके आकार का वर्ग है, और संभवतः अधिक है।

लोग अक्सर एकल वर्ग (/ फ़ंक्शन / फ़ाइल / आदि) की जटिलता को देखते हैं और भूल जाते हैं कि आपको वास्तव में सबसे छोटी वियोज्य (इनकैप्सुलेटिव) इकाई की जटिलता पर विचार करना चाहिए। एक परिपत्र निर्भरता होने से उस इकाई का आकार बढ़ जाता है, संभवतः अदृश्य रूप से (जब तक आप फ़ाइल 1 को बदलने की कोशिश शुरू नहीं करते हैं और महसूस करते हैं कि फाइलों में 2-127 में भी बदलाव की आवश्यकता होती है)।


14

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


10

हम्म ... जो इस बात पर निर्भर करता है कि आप परिपत्र निर्भरता से क्या मतलब रखते हैं, क्योंकि वास्तव में कुछ परिपत्र निर्भरताएं हैं जो मुझे लगता है कि बहुत फायदेमंद हैं।

एक्सएमएल डोम पर विचार करें - यह प्रत्येक नोड के लिए अपने माता-पिता के लिए एक संदर्भ है, और प्रत्येक माता-पिता के लिए अपने बच्चों की एक सूची है। संरचना तार्किक रूप से एक पेड़ है, लेकिन एक कचरा संग्रह एल्गोरिदम के दृष्टिकोण से या इसी तरह की संरचना परिपत्र है।


1
वह पेड़ नहीं होगा?
कॉनराड फ्रैक्स

@ कोनराड: मुझे लगता है कि यह एक पेड़ के रूप में सोचा जा सकता है, हाँ। क्यों?
बिली ओनेल

1
मैं पेड़ के परिपत्र के बारे में नहीं सोचता क्योंकि आप इसके बच्चों को नीचे उतार सकते हैं और समाप्त कर देंगे (माता-पिता के संदर्भ की परवाह किए बिना)। जब तक एक नोड के पास एक बच्चा नहीं था, वह भी एक पूर्वज था जो मेरे दिमाग में यह एक ग्राफ बनाता है न कि एक पेड़।
कॉनराड फ्रैक्स

5
एक परिपत्र संदर्भ होगा यदि नोड के बच्चों में से एक पूर्वज को वापस लूप दिया गया था।
मैट ओलेनिक

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

9

की तरह है चिकन या अंडा समस्या।

ऐसे कई मामले हैं जिनमें परिपत्र संदर्भ अपरिहार्य हैं और उपयोगी हैं लेकिन, उदाहरण के लिए, निम्नलिखित मामले में यह काम नहीं करता है:

प्रोजेक्ट A, प्रोजेक्ट B पर निर्भर करता है और B, A पर निर्भर करता है। A को B में उपयोग किए जाने के लिए संकलित किए जाने की आवश्यकता है, जिसमें A से पहले B को संकलित करने की आवश्यकता होती है, जिसे A से पहले B को संकलित करने की आवश्यकता होती है ...


6

हालांकि मैं यहां अधिकांश टिप्पणियों से सहमत हूं, लेकिन मैं "माता-पिता" / "बच्चे" के परिपत्र संदर्भ के लिए एक विशेष मामला दर्ज करना चाहूंगा।

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

आप एक युक्त वर्ग के बिना एक परिपत्र संदर्भ के बिना ऐसा कर सकते हैं ताकि पहले जो "अभिभावक" था वह अब एक भाई है, लेकिन ऐसा करने के लिए मौजूदा कोड को फिर से फैक्टर करना हमेशा संभव नहीं होता है।

दूसरा विकल्प यह है कि एक बच्चे को अपने कंस्ट्रक्टर में जरूरत के सभी डेटा को पास करना चाहिए, जो अंत में सिर्फ सादा भयानक होता है।


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

5

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


4

मैं इस सवाल को मॉडलिंग के दृष्टिकोण से ले जाऊंगा।

जब तक आप किसी ऐसे रिश्ते को नहीं जोड़ते जो वास्तव में वहां नहीं हैं, आप सुरक्षित हैं। यदि आप उन्हें जोड़ते हैं, तो आपको डेटा में कम अखंडता मिलती है (क्योंकि वहाँ अतिरेक है) और अधिक कसकर युग्मित कोड।

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

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

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

(अब डेटाबेस के बारे में बात करने जा रहे हैं) बहुत से लोग दो-रिश्तों के समाधान के लिए चुनते हैं क्योंकि वे "प्राथमिक" को एक अद्वितीय सूचक मानते हैं और एक विदेशी कुंजी एक सूचक की तरह है। तो विदेशी कुंजी का उपयोग करने के लिए बात होनी चाहिए, है ना? गलत। विदेशी कुंजी रिश्तों का प्रतिनिधित्व करती है लेकिन "प्राथमिक" एक रिश्ता नहीं है। यह एक आदेश का एक विकृत मामला है जहां एक तत्व सभी से ऊपर है और बाकी का आदेश नहीं दिया गया है। यदि आपको कुल ऑर्डर करने की आवश्यकता है, तो आप निश्चित रूप से इसे एक रिश्ते की विशेषता के रूप में मानेंगे क्योंकि मूल रूप से कोई अन्य विकल्प नहीं है। लेकिन जिस समय आप इसे पतित करते हैं, वहाँ एक विकल्प होता है और काफी भयानक होता है - कुछ ऐसा करने के लिए जो एक रिश्ते के रूप में एक रिश्ता नहीं है। तो यहाँ यह आता है - रिश्ता अतिरेक जो निश्चित रूप से कम करके आंका नहीं जाना है।

इसलिए, जब तक यह पूरी तरह से स्पष्ट नहीं हो जाता कि मैं जिस चीज से मॉडलिंग कर रहा हूं, यह एक स्पष्ट संदर्भ नहीं होने देता।

(ध्यान दें: यह डेटाबेस डिजाइन के लिए थोड़ा पक्षपाती है, लेकिन मैं शर्त लगा सकता हूं कि यह अन्य क्षेत्रों में भी लागू हो)


2

मैं उस सवाल का जवाब एक और सवाल के साथ दूंगा:

आप मुझे क्या स्थिति दे सकते हैं जहां एक परिपत्र संदर्भ मॉडल रखते हुए आप जो निर्माण करने की कोशिश कर रहे हैं उसके लिए सबसे अच्छा मॉडल है?

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


1
यह हो सकता है कि एक परिपत्र लिंक्ड सूची (सिंगल-लिंक्ड या डबल-लिंक्ड) एक कार्यक्रम के लिए केंद्रीय घटना कतार के लिए एक उत्कृष्ट डेटा संरचना होगी जो "कभी नहीं रोकना" चाहिए (कतार में महत्वपूर्ण एन चीजों को चिपकाएं, एक के साथ "फ्लैग डिलीट न करें" फ्लैग सेट, फिर बस खाली होने तक कतार को पार करें; जब नए कार्यों (क्षणिक या स्थायी) की आवश्यकता होती है, तो उन्हें कतार में एक उपयुक्त स्थान पर चिपका दें; जब भी आप "डिलीट न करें" ध्वज के बिना भी सेवा करते हैं; , इसे फिर कतार से उतार लें)।
वेटिन

1

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


1

एक परिपत्र संदर्भ निर्माण समस्याग्रस्त है, न केवल एक डिजाइन दृष्टिकोण से, बल्कि एक त्रुटि पकड़ने वाले दृष्टिकोण से भी।

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

परिपत्र संदर्भों के साथ, आपकी समस्याएं अब दोगुनी हो गई हैं। क्योंकि आपकी प्रक्रियाएँ कसकर बंधी हुई हैं, आपके पास यह जानने का कोई तरीका नहीं है कि किस कक्षा में किस त्रुटि के कारण या त्रुटि आई है, क्योंकि एक वर्ग दूसरे पर निर्भर है, दूसरे पर निर्भर है। अब आपको यह पता लगाने के लिए दोनों वर्गों के संयोजन में समय बिताना होगा कि त्रुटि के लिए वास्तव में कौन जिम्मेदार है।

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


1

कुछ कचरा संग्रहकर्ताओं को उन्हें साफ करने में परेशानी होती है, क्योंकि प्रत्येक वस्तु को दूसरे द्वारा संदर्भित किया जा रहा है।

संपादित करें: जैसा कि नीचे दी गई टिप्पणियों से उल्लेख किया गया है, यह केवल एक कचरा संग्रहकर्ता के लिए एक अत्यंत भोले प्रयास के लिए सही है , न कि आप कभी भी अभ्यास में सामना करेंगे।


11
हम्म .. किसी भी कचरा कलेक्टर ने इसे ऊपर उठाया है यह एक सच्चा कचरा संग्रहकर्ता नहीं है।
बिली ओनेल

11
मुझे किसी भी आधुनिक कचरा संग्रहकर्ता के बारे में जानकारी नहीं है जिसे परिपत्र संदर्भों की समस्या होगी। यदि आप संदर्भ गणना का उपयोग कर रहे हैं तो परिपत्र संदर्भ एक समस्या है, लेकिन अधिकांश कचरा संग्रहकर्ता अनुरेखण शैली हैं (जहां आप ज्ञात संदर्भों की सूची से शुरू करते हैं और अन्य सभी को खोजने के लिए उनका अनुसरण करते हैं, बाकी सब कुछ एकत्र करते हैं)।
डीन हार्डिंग

4
Sct.ethz.ch/teaching/ws2005/semspecver/slides/takano.pdf देखें, जो विभिन्न प्रकार के कचरा लेनेवालों को कमियां बताते हैं - यदि निशान और झाडू लें और लंबी पॉज़ टाइम (जैसे पीढ़ियों का निर्माण) कम करने के लिए इसे अनुकूलित करना शुरू करें , आपको परिपत्र संरचनाओं (जब परिपत्र ऑब्जेक्ट अलग-अलग पीढ़ियों में होते हैं) के साथ समस्या है। यदि आप संदर्भ गणना लेते हैं और परिपत्र संदर्भ समस्या को ठीक करना शुरू करते हैं, तो आप अंत में लंबे ठहराव के समय को चिह्नित करते हैं जो निशान और स्वीप की विशेषता है।
केन ब्लूम

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

1
वस्तुनिष्ठ-ग में, परिपत्र संदर्भ इसे बनाते हैं, इसलिए जब आप जारी करते हैं तो रेफरी की संख्या शून्य से नहीं टकराती है, जो कचरा इकट्ठा करने वाले तक जाती है।
डेक्सटरडब्ल्यू

-2

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

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

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

मैं कहता हूँ कि उपकरण के साथ एक समस्या है सिद्धांत के साथ कोई समस्या नहीं है।


एक वाक्य की राय जोड़ने से पद में योगदान नहीं होता है या उत्तर की व्याख्या नहीं होती है। क्या आप इस बारे में विस्तार से बता सकते हैं?

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

मैंने पाया है कि आपके प्रोग्राम को चलाने और चलाने में आसानी होती है, लेकिन आम तौर पर इसे बोलने से अंततः सॉफ्टवेयर को बनाए रखना कठिन हो जाता है क्योंकि आप पाते हैं कि तुच्छ परिवर्तनों का कैस्केडिंग प्रभाव पड़ता है। A, B में कॉल करता है जो A से कॉल बैक करता है जो B से कॉल बैक करता है ... मैंने पाया है कि इस प्रकृति के परिवर्तनों के प्रभावों को समझना वास्तव में कठिन है, खासकर जब A और B पॉलीमॉर्फिक हैं।
डैश-टॉम-बैंग
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.