परिपत्र पैकेज निर्भरता को कैसे हल करें

Question

मैं एक बड़े कोडबेस को रिफैक्ट कर रहा हूं जहां अधिकांश कक्षाएं एक पैकेज में स्थित हैं। बेहतर प्रतिरूपकता के लिए, मैं प्रत्येक कार्यक्षमता के लिए सबपैकेज बना रहा हूं।

मुझे याद है कि कहीं न कहीं पैकेज डिपेंडेंसी ग्राफ में लूप नहीं होना चाहिए, लेकिन मुझे यह नहीं पता कि निम्न समस्या को कैसे हल किया जाए: Figureपैकेज figureमें Layoutहै, पैकेज में है layout, Layoutलेआउट करने के लिए फिगर की जरूरत है, इसलिए पैकेज पैकेज layoutपर निर्भर करता है figure। लेकिन दूसरी ओर, इसके अंदर Figureअन्य Figureएस हो सकते हैं , इसका अपना होना Layout, जो पैकेज figureपर निर्भर करता है layout।

मेरे पास हालांकि कुछ समाधान हैं, जैसे कि एक Containerइंटरफ़ेस बनाना जो Figureइसे लागू करता है और इसे Layoutपैकेज में रखता है । क्या यह एक अच्छा उपाय है? किसी भी अन्य संभावनाओं?

धन्यवाद

Comments

यह मॉड्यूल है (उदाहरण के लिए अलग जार) में परिपत्र निर्भरता नहीं हो सकती है। पैकेज कर सकते हैं और जब तक वे एक ही मॉड्यूल से संबंधित होते हैं, तब तक गोलाकार चित्रण हो सकता है।

— लोरेंस

@lorus तो यह एक डिजाइन समस्या नहीं है?

— vainolo

नहीं ऐसा नहीं है। पैकेज आम तौर पर केवल एक नामस्थान होते हैं। यह केवल तब बदल सकता है जब वे किसी और चीज़ के लिए उपयोग करते हैं, उदाहरण के लिए OSGi वातावरण में अपनी सामग्री दृश्यता को बदलने के लिए। अन्यथा परेशान मत करो।

— कोरस

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

— किलन फ़ॉथ

Answer 1

आपको उलटा नियंत्रण के बारे में सोचना चाहिए

आप मूल रूप से अपने लिए एक इंटरफ़ेस परिभाषित करते हैं Layoutजो आपके लेआउट वर्ग के पास कहीं एक ही पैकेज में स्थित है ताकि आपके पास एक कार्यान्वयन पैकेज और एक सार्वजनिक इंटरफ़ेस पैकेज हो - उदाहरण के लिए इसे कॉल करें Layoutable(मुझे नहीं पता कि यह उचित अंग्रेजी है)। अब - लेआउट उस इंटरफ़ेस को लागू नहीं करेगा लेकिन Figureवर्ग। इसी तरह आप Drawableउदाहरण के लिए चित्रा के लिए एक इंटरफ़ेस बनाएंगे ।

इसलिए

my.public.package.Layoutable
my.implementation.package.Layout
my.public.package.Drawable
my.implementation.package.Figure

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

फिर आपके पास एक निर्माता की तरह कुछ होगा जो दोनों को एक साथ बांधता है। तो निर्माता को एक निर्भरता के लिए होता है Layoutऔर साथ ही के लिए Figureहै, लेकिन Layoutऔर Figureखुद को स्वतंत्र होगा।

यही मोटा विचार है।

इस समस्याओं के समाधान के लिए एक उत्कृष्ट स्रोत किर्क नोएर्नस्चिल्ड द्वारा बुक जावा एप्लिकेशन आर्किटेक्चर है।

Comments

क्या यह Containerप्रश्न में सुझाए गए इंटरफ़ेस के समान नहीं है ?

— विन्गंड्रोइड

हां - और नहीं - मैंने उन दोनों को एक ही पैकेज में नहीं रखा, जैसा कि मैंने कहा। और इसके पीछे बहुत सिद्धांत नहीं था। और इस मामले में यह एक तरफ करने के लिए पर्याप्त नहीं है, आपको इसे दोनों तरफ करना होगा। ठीक है?

— michael_s

ओह, मैं मूल प्रश्न में थोड़ा सा चूक गया, Containerजैसा कि उसी पैकेज में जा रहा था Layout। यह काम नहीं करेगा, जबकि आपका समाधान होगा।

— विन्गंड्रोइड

आह - ठीक है - मुझे लग रहा था कि जब मैं हैक कर रहा था तब कंटेनर के साथ भाग छूट गया था - इसे कंटेनर का नाम देना चाहिए था;)

— michael_s

Answer 2

मैं बहुत स्पष्ट नहीं हूं कि क्या Figureहै, लेकिन शायद यह उसी पैकेज में होना चाहिए Layout?

आपका प्रस्तावित Containerइंटरफ़ेस समाधान काम नहीं करेगा - जब तक आप Containerइंटरफ़ेस को तीसरे पैकेज में नहीं डालते हैं, तब भी आपके पास दो पैकेजों के बीच एक परिपत्र निर्भरता होगी। कुछ के लिए michael_s का उत्तर देखें जो काम करेगा।

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