एक गहरी विरासत पदानुक्रम के विकल्प?

Question

मैं व्यापक विशेषताओं के सेट के साथ उत्पादों को मॉडल करने का प्रयास कर रहा हूं। आम तौर पर एक ऑनलाइन स्टोर एक विशिष्ट उत्पाद के गुणों को सूचीबद्ध करने के लिए एक टेक्स्ट विवरण का उपयोग करेगा। हालांकि, यह समाधान इष्टतम नहीं है।

उदाहरण के लिए, निम्न लिंक विशेषताओं की विसंगतियों एक ही उत्पाद के लिए एक पाठ वर्णन के भीतर, दिखाने लेकिन विभिन्न निर्माताओं के साथ:

• MSI GTX690
• Gigabyte GTX690
• ASUS GTX690

इस प्रकार, मैंने निम्नानुसार विरासत पदानुक्रम का चयन किया है:

Product>Component>GraphicsCard>NvidiaGraphicsCard

इस का कारण है, क्योंकि मैं प्रत्येक Product की विशेषताओं से अधिक कुशल नियंत्रण चाहते हैं। यह मुझे NvidiaGraphicsCard कहने के लिए विशिष्ट विशेषताओं को शामिल करने की अनुमति देता है जो ATiGraphicsCard पर लागू नहीं हैं।

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

क्या ऐसी गहरी विरासत पदानुक्रम रखने में कोई समस्या है, और यदि इस समस्या को संभालने के लिए कोई समाधान या शायद पैटर्न हैं?

Answer 1

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

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

इसके बजाय, मैं एक Product कक्षा रखने के लिए जाऊंगा, जो उत्पाद विशिष्ट वर्णनकर्ताओं या विशेषताओं के शब्दकोश से बना हो सकता है। OrderItemProduct को संदर्भित करने के लिए विशिष्ट उत्पाद प्रकार को जानने के बिना - polymorphism की आवश्यकता नहीं है। इससे नए प्रकार के उत्पादों की अनुमति भी आसान हो जाएगी - एक नई उप-वर्ग बनाने की आवश्यकता नहीं है।

Answer 2

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

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

ध्यान दें कि गहरी विरासत का कोई प्रदर्शन जुर्माना नहीं है - लंबी विरासत श्रृंखला का मतलब धीमी आभासी विधि कॉल नहीं है (ठीक है, आप केवल वर्चुअल कॉल का उपयोग नहीं करेंगे क्योंकि ये केवल डेटा कंटेनर हैं)।

Answer 3

मैं आपको सजावटी पैटर्न को देखने के लिए सलाह दूंगा। इस तरह आप की जरूरत है कि आप की जरूरत है और एक अरब वर्ग से भी कम है।