एक दूसरे के लिए निर्भरता के साथ दो वस्तुओं। कि बुरा है?

Question

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

वर्तमान में मैं कई ग्राहकों के साथ सॉकेट का उपयोग करके थोड़ा चैट-सर्वर बना रहा हूं।

1. व्यक्ति श्रेणी जो निक, उम्र और एक रूम-वस्तु की तरह जानकारी रखता: अभी मैं तीन वर्गों की है।
2. कक्ष श्रेणी जो की तरह कमरे के नाम, विषय और वर्तमान में है कि कमरे में व्यक्तियों की एक सूची जानकारी रखती है।
3. होटल-श्रेणी जिसमें व्यक्तियों की एक सूची है और सर्वर पर कमरों की एक सूची है।

मैं एक चित्र बना दिया है यह वर्णन करने के लिए:

मैं होटल श्रेणी में सर्वर पर व्यक्तियों की एक सूची है, क्योंकि यह है कि कितने वहाँ ऑनलाइन सही कह रहे हैं का ट्रैक रखने के अच्छा होगा अब (सभी कमरों के माध्यम से फिर से शुरू किए बिना)। व्यक्ति होटल-कक्षा में रहते हैं क्योंकि मैं कमरे की खोज किए बिना एक विशिष्ट व्यक्ति की तलाश करने में सक्षम होना चाहता हूं।

क्या यह खराब डिज़ाइन है? क्या इसे हासिल करने का दूसरा तरीका है?

धन्यवाद।

Answer 1

आपसी निर्भरता वर्गों के बीच समस्या, कडाई के साथ इंटरफेस (सार कक्षाएं, अगर अपनी भाषा है जैसे सी ++ या अजगर) का उपयोग कर IRoom और IPerson द्वारा हल किया जा सकता है; वास्तविक कार्यान्वयन इंटरफेस की जरूरत है केवल इंटरफेस पर निर्भर करते हैं - स्यूडोकोड

interface IPerson 
    IRoom getRoom() 
    // etc 

interface IRoom 
    iter<IPerson> iterPerson() 
    // etc 

में यह केवल इंटरफेस परस्पर एक दूसरे पर निर्भर करता है।

यह आपको कार्यान्वयन के मामले में बहुत कम छूट देता है, यदि आप परिपत्र संदर्भ लूप से बचाना चाहते हैं (जो परेशान हो सकता है उदा।कचरा संग्रह को धीमा करके सीपीथॉन में) - आप कमजोर संदर्भों का उपयोग कर सकते हैं, एक सामान्य "एक से कई रिश्ते" टेबल इत्यादि के साथ एक अंतर्निहित रिलेशनल डेटाबेस। और पहले सरल प्रोटोटाइप के लिए आप अपनी चुनी भाषा में सबसे सरल क्या कर सकते हैं PersonRoom और Room को list<Person> पर संदर्भित करने के साथ संभवतः सरल, और आवश्यक रूप से परिपत्र, संदर्भ [[पॉइंटर्स, सी ++ में] संदर्भ []।

Answer 2

मुझे यह पसंद नहीं है। एक होटल के कमरे शामिल है, और कमरे लोग होते हैं। लोगों में कमरे नहीं होते हैं, वे उनके हैं।

आप आवश्यक रूप से अपने अतिथि गणना प्राप्त करने में पुनरावृति की जरूरत नहीं है। आप केवल एक चलती गिनती ($ Hotel-> total_guests) रख सकते हैं और इसे बदलते समय संशोधित कर सकते हैं।

Answer 3

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

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

Answer 4

म्यूचुअल निर्भरता अपने अधिकार में बुरा नहीं है। कभी-कभी डेटा उपयोग की आवश्यकता होती है।

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

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