असली चीजों के रिश्तों को प्रतिबिंबित करने के लिए आंतरिक कक्षाओं का उपयोग

Question

यह एक वैचारिक प्रश्न है। मुझे पता है कि मैं क्या करने की कोशिश कर रहा हूं। मैं सोच रहा हूं कि यह करने के लिए सही बात है या नहीं।

मैं कुछ ऐसे व्यक्ति का प्रतिनिधित्व करने की कोशिश कर रहा हूं जिसमें वास्तविक जीवन में घोंसले का थोड़ा सा हिस्सा शामिल है। यह एक दस्तावेज है जो वस्तुओं के एक सेट के साथ गतिविधियों को निर्दिष्ट करता है। एक दस्तावेज़ में कई आइटम शामिल हो सकते हैं और प्रत्येक आइटम में कई गतिविधियां हो सकती हैं।

तो पदानुक्रम दस्तावेज़ -> आइटम -> गतिविधि होगी।

मेरी वर्तमान सोच यह दर्शाती है कि यह एक शीर्ष स्तर की कक्षा, दस्तावेज़, जिसमें एक आंतरिक वर्ग, आइटमप्रोग्राम होता है, जिसमें स्वयं एक आंतरिक वर्ग, गतिविधि होती है। हां, यह घोंसले के दो स्तर हैं।

public class Document { 

    // Properties of the document itself 

    private Map<Item, ItemProgram> itemPrograms; // Map of item programs 

    public class ItemProgram { 

     // Properties of the item program itself 

     private List<Activity> activities; // List of activities 

     public class Activity { 
     // Properties of the activity 
     } 
    } 
} 

आंतरिक कक्षाएं सार्वजनिक होनी चाहिए, लेकिन मैं रचनाकारों को निजी बना रहा हूं ताकि वे केवल अपने बाहरी वर्गों में विधियों को जोड़ सकें। जैसा कि आप देख सकते हैं, मैं एक प्रकार के संग्रह का उपयोग करके उदाहरणों को संग्रहित करता हूं।

क्या यह इस बारे में जाने का सही तरीका है? डबल घोंसला?

क्या आंतरिक कक्षा के सभी उदाहरणों के संदर्भों को संग्रहीत करने के लिए बाहरी वर्ग में संग्रह का उपयोग करना उचित है? जबकि वहाँ प्रत्येक का एक प्रकार है, मन (और टिप्पणियों में दस्तावेज़) में रखें कि यदि आप कई प्रकार के या Document, Activity के derivations जरूरत के लिए शुरू करने या ItemProgram आप सबसे अधिक संभावना इस विभाजित करने के लिए की आवश्यकता होगी

Answer 1

इस विशेष दृष्टिकोण ठीक है एक और स्केलेबल पैटर्न बनाने के अलावा वर्ग।

Document अपने स्वयं के तर्क, प्लस ItemProgram उदाहरणों के निर्माण के लिए Activity उदाहरणों के निर्माण और तर्क के तर्क हैं, तो यह SRP (एकल जिम्मेदारी सिद्धांत) के मार्गदर्शन के खिलाफ है। यह सिद्धांत आपको स्केल आउट करने और कक्षा विस्फोटों को रोकने में समस्याओं को रोकने में मदद करता है, जहां आप रचनात्मक पैटर्न का उपयोग करने के बजाय संयोजनों का प्रतिनिधित्व करने वाले वर्ग प्राप्त करना शुरू करते हैं।

मैं यह भी कहूंगा कि नेस्टेड कक्षाएं ठीक हैं अगर उन वर्गों के ग्राहक केवल माता-पिता (संलग्न) वर्ग हैं और यदि आप उन्हें कहीं और उपयोग कर रहे हैं तो मैं इसे अलग कर दूंगा।

संपादित है, उन सभी ने कहा है, उन्हें, अलग वर्ग के रूप में होने के कम से कम में कोई लाभ यह है कि सकारात्मक प्रणाली आप विकसित कर रहे हैं प्रभाव को लेकर कक्षाओं घोंसला बनाने से कोई लाभ नहीं है:

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

Answer 2

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

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

इस तरह से डबल घोंसला 'असामान्य' है और आपके कोड को पढ़ने वाले अन्य लोगों को भ्रमित कर सकता है।

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

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

क्या आपने सोचा है कि यह डिज़ाइन आपके कोड की टेस्टेबिलिटी को कैसे प्रभावित कर सकता है? क्या होगा यदि आप गतिविधि वर्ग को यूनिट-टेस्ट करना चाहते हैं - क्या आप ऐसा इस तरह से कर सकते हैं कि परीक्षण विफलता निश्चित रूप से गतिविधि में समस्या का संकेत देगी, न कि माता-पिता कक्षाओं में से एक में?