मुझे विजुअल स्टूडियो सॉल्यूशन मिला है जिसमें परियोजनाओं के बीच कई परिपत्र संदर्भ शामिल हैं।परिपत्र संदर्भ कभी आवश्यक हैं?
क्या ऐसी कोई स्थिति है जहां यह दूरस्थ रूप से स्वीकार्य है?
बस मेरे संदेह की पुष्टि करने का प्रयास कर रहा है कि यह एप्लिकेशन बहुत ही डिज़ाइन किया गया है। अग्रिम में धन्यवाद।
मैंने एक बार एक कॉलम पढ़ा जहां उन्होंने 3 प्रकार के मॉडल की तुलना की: स्पेगेटी मॉडल, Lasagna मॉडल और Ravioli मॉडल।
स्पेगेटी मॉडल में, सभी कोड एक दूसरे के साथ जुड़े हुए हैं, कोई स्पष्ट संरचना नहीं है। यह भयानक है, और हम शायद उस पर सहमत हो सकते हैं।
में Lasagna मॉडल, कोड अलग-अलग परतों में विभाजित है, और केवल एक उच्च स्तरीय परत निम्न स्तर की परत तक पहुंच सकती है, कभी दूसरी तरफ नहीं।
में Ravioli मॉडल, कोड छोटे मॉड्यूल में समूहित किया गया है। प्रत्येक मॉड्यूल केवल खुलासा करता है कि किस चीज का खुलासा किया जाना चाहिए, लेकिन प्रत्येक मॉड्यूल अभी भी हर दूसरे मॉड्यूल तक पहुंच सकता है।
लगभग 10 साल पहले, मुझे लगता था कि रैवियोली मॉडल Lasagna मॉडल से बेहतर है। आखिरकार, जावा में आपके पास जावा मॉड्यूल भी हैं जो आसानी से एक दूसरे को कॉल कर सकते हैं (और मुझे लगता है कि सभी अलग-अलग जावा मॉड्यूल के बीच कोई वास्तविक संरचना नहीं थी)। मेरे लिए, Lasagna मॉडल गैर-ऑब्जेक्ट उन्मुख पुराने कोड का परिणाम प्रतीत होता था, जबकि Ravioli मॉडल अधिक आधुनिक, अधिक ऑब्जेक्ट उन्मुख लग रहा था।
आजकल, मैं लासगना मॉडल पर वापस जाता हूं, लेकिन एक रैवियोली मॉडल अंतर्निहित है।यह वह जगह है:
कुछ परिपत्र संदर्भों को हटाने के लिए मुश्किल या असंभव हो सकता है। एक उदाहरण निम्नलिखित है: मान लीजिए कि आपके पास आपके एप्लिकेशन और एक डीबग क्लास में एक फ़ाइलवाइटर क्लास है। डीबग क्लास को फाइलवाइटर क्लास की आवश्यकता होगी क्योंकि इसे डीबग जानकारी के साथ फाइलें लिखनी होंगी। दूसरी ओर, फ़ाइलवाइटर क्लास भी डीबग क्लास का उपयोग करना चाह सकता है।
ध्यान दें कि इस उदाहरण में परिपत्र संदर्भ पहले से ही समस्याएं पैदा कर सकता है (फ़ाइल लिखने के दौरान फ़ाइलवाइटर क्लास डीबग क्लास को कॉल कर सकता है, लेकिन डीबग क्लास डीबग जानकारी लिखने के लिए फ़ाइलवाइटर क्लास का उपयोग करती है, परिणाम: स्टैक ओवरफ़्लो) ।
इस मामले में, समस्या को डीबग क्लास में फ़ाइलवाइटर क्लास का उपयोग न करके आसानी से हल किया जा सकता है, लेकिन मूल iostreams (यदि आप C++ में विकसित हो रहे हैं) का उपयोग करने के लिए आसानी से हल किया जा सकता है। अन्य मामलों में, समस्या हल करने के लिए बहुत कठिन हो सकता है।
परिपत्र परियोजना संदर्भ खराब डिजाइन का संकेत हैं और यदि संभव हो तो हटा दिया जाना चाहिए।
एक परिपत्र संदर्भ रखने के लिए मैं सोच सकता हूं कि एकमात्र औचित्य एक बैक कंपैट मुद्दा होगा। फिर भी ऐसा लगता है कि इसे टाइप फॉरवर्डर्स और अन्य असेंबली
अच्छे सॉफ़्टवेयर को उनके बीच स्पष्ट रूप से सीमांकित सीमाओं के साथ परतों में डिज़ाइन किया गया है। यानी: यदि आपके पास एक परत है, तो आपको स्पष्ट रूप से स्पष्ट करने में सक्षम होना चाहिए कि यह क्या करता है, यह क्यों है, और यह किस पर निर्भर करता है। परिपत्रों को हासिल करना मुश्किल हो जाता है, और आम तौर पर हटा दिया जाना चाहिए। (माइक्रोसॉफ्ट ने परिपत्रों को हटाकर विंडोज़ की परत को बेहतर बनाने के लिए विंडोज 7 में बहुत सारे प्रयास किए हैं।)
बस मेरे संदेह की पुष्टि करने की कोशिश कर रहा है कि यह एप्लिकेशन बहुत ही डिज़ाइन किया गया है।
यह निश्चित रूप से उस सिद्धांत का समर्थन करेगा, लेकिन आईएमओ, आपको उस निष्कर्ष को आकर्षित करने के लिए केवल कुछ परिपत्र संदर्भों की आवश्यकता होगी।
अपने मूल प्रश्न का उत्तर देने के लिए: हाँ, परिपत्र संदर्भ कई बार सहायक हो सकते हैं। पारस्परिक रूप से पुनरावर्ती कार्य उस तरह की चीज़ का एक अच्छा उदाहरण हैं। हालांकि ... यह एक मॉड्यूल के भीतर सुरक्षित रूप से छिपी हुई एक परिपत्र संदर्भ है। अंतर-मॉड्यूल निर्भरताओं के लिए, एक गोलाकार निर्भरता आमतौर पर इसका मतलब है कि आपका कोड मॉड्यूल में सही ढंग से विभाजित नहीं होता है, और इसे ठीक करने के लिए कुछ महत्वपूर्ण रिफैक्टरिंग की आवश्यकता हो सकती है। (अंतराल को पुल करने के लिए abstctions के नए प्रकार को जोड़ने सहित)
कंक्रीटली मैं dependency cycles का पता लगाने और इससे बचने के लिए एनडीपेन्ड का उपयोग करने की सलाह दूंगा। लेख से
अंश (मैंने लिखा): Control component dependencies to gain clean architecture घटकों के बीच
निर्भरता चक्र जो सामान्यतः स्पेगेटी कोड और उलझा कोड कहा जाता है के लिए सीसा। यदि घटक ए बी पर निर्भर करता है जो सी पर निर्भर करता है जो ए पर निर्भर करता है, घटक ए को बी और सी ए, बी और सी से स्वतंत्र रूप से विकसित और परीक्षण नहीं किया जा सकता है, एक अविभाज्य इकाई, एक प्रकार का सुपर-घटक। स्केल घटना की बीमारियों की वजह से ए, बी और सी पर लागत के योग की तुलना में इस सुपर-कंपोनेंट की लागत अधिक है (सॉफ्टवेयर अनुमान में अच्छी तरह से प्रलेखित: स्टीव मैककनेल द्वारा ब्लैक आर्ट डेमस्टिफाइंग)। असल में, यह मानता है कि कोड के एक अविभाज्य टुकड़े को विकसित करने की लागत तेजी से बढ़ जाती है।
इससे पता चलता है कि 500 एलओसी (कोड ऑफ लाइन्स) के विकास और रखरखाव की संभावना 500 एलओसी के विकास और रखरखाव की तुलना में तीन या चार गुना अधिक होगी, जब तक कि इसे प्रत्येक 500 एलओसी के दो स्वतंत्र गांठों में विभाजित नहीं किया जा सके। इसलिए स्पेगेटी के साथ तुलना जो उलझन वाले कोड का वर्णन करती है जिसे बनाए रखा नहीं जा सकता है। आर्किटेक्चर को तर्कसंगत बनाने के लिए, किसी को यह सुनिश्चित करना चाहिए कि घटकों के बीच कोई निर्भरता चक्र न हो, लेकिन यह भी जांचें कि प्रत्येक घटक का आकार स्वीकार्य है (500 से 1000 LOC)।
संदेह की पुष्टि! – mclark1129