2009-02-21 27 views
15

क्या कोई भी एकाधिक विरासत का उपयोग करने के लिए किसी भी स्थिति के बारे में सोच सकता है? हर मामला मैं के बारे में सोच सकते हैं विधि ऑपरेटर द्वारा हल किया जा सकताएकाधिक विरासत के लिए उपयोग?

AnotherClass() { return this->something.anotherClass; } 
+0

क्या यह आपके प्रश्न का उत्तर देता था?यदि ऐसा है, तो कृपया एक उत्तर स्वीकार करें। (संकेत: +12 उत्तर उत्तर हो सकता है) –

उत्तर

21

पूर्ण पैमाने एकाधिक विरासत के अधिकांश उपयोग मिश्रित के लिए हैं। एक उदाहरण के रूप:

class DraggableWindow : Window, Draggable { } 
class SkinnableWindow : Window, Skinnable { } 
class DraggableSkinnableWindow : Window, Draggable, Skinnable { } 

आदि ...

ज्यादातर मामलों में, यह सख्ती से इंटरफ़ेस विरासत करने के लिए एकाधिक वंशानुक्रम उपयोग करने के लिए सबसे अच्छा है।

class DraggableWindow : Window, IDraggable { } 

फिर आप अपने ड्रैगगेबलविंडो क्लास में आईडीग्रैगबल इंटरफ़ेस को लागू करते हैं। अच्छा मिश्रण वर्ग लिखना बहुत मुश्किल है।

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

उदाहरण के लिए, कई वर्ग चौखटे में आप कुछ इस तरह देखें:

class Control { } 
class Window : Control { } 
class Textbox : Control { } 

अब, मान लीजिए आप विंडो विशेषताओं के साथ एक पाठ बॉक्स चाहते थे? , Dragable जा रहा है एक शीर्षक पट्टी होने, आदि की तरह ... आप कुछ इस तरह कर सकता है:

class WindowedTextbox : Control, IWindow, ITexbox { } 

एकल विरासत मॉडल में, आप आसानी से डुप्लिकेट नियंत्रण के साथ कुछ समस्या हो रही बिना दोनों खिड़की और पाठ बॉक्स से विरासत नहीं कर सकते वस्तुओं और अन्य प्रकार की समस्याएं। आप खिड़की वाले टेक्स्टबॉक्स को विंडो, टेक्स्टबॉक्स या कंट्रोल के रूप में भी इलाज कर सकते हैं।

इसके अलावा, अपने .anotherClass() idiom को संबोधित करने के लिए .anotherClass() एक अलग वस्तु देता है, जबकि एकाधिक विरासत एक ही ऑब्जेक्ट को विभिन्न उद्देश्यों के लिए उपयोग करने की अनुमति देती है।

12

मैं जब mixin वर्गों का उपयोग एकाधिक वंशानुक्रम विशेष रूप से उपयोगी पाते हैं।

के रूप में विकिपीडिया में कहा गया है:

ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग भाषाओं में, mixin एक वर्ग है कि एक उपवर्ग द्वारा विरासत में मिली होने के लिए एक निश्चित सुविधा प्रदान करता है है, लेकिन अकेले खड़े करने के लिए नहीं है ।

हमारे उत्पाद मिश्रित वर्गों का उपयोग करने का एक उदाहरण है कॉन्फ़िगरेशन सहेजने और उद्देश्यों को पुनर्स्थापित करने के लिए। एक अमूर्त मिश्रित वर्ग है जो शुद्ध आभासी तरीकों के एक सेट को परिभाषित करता है। सहेजने योग्य कोई भी वर्ग जो मिक्सिन क्लास को सहेजने/पुनर्स्थापित करने से प्राप्त होता है जो स्वचालित रूप से उन्हें उपयुक्त सहेजने/पुनर्स्थापित करने की कार्यक्षमता देता है।

लेकिन वे अपने सामान्य वर्ग संरचना के हिस्से के रूप में अन्य वर्गों से भी उत्तराधिकारी हो सकते हैं, इसलिए इन वर्गों के लिए इस संबंध में एकाधिक विरासत का उपयोग करना आम बात है।

एकाधिक वंशानुक्रम का एक उदाहरण:

class Animal 
{ 
    virtual void KeepCool() const = 0; 
} 

class Vertebrate 
{ 
    virtual void BendSpine() { }; 
} 


class Dog : public Animal, public Vertebrate 
{ 
    void KeepCool() { Pant(); } 
} 

क्या सबसे महत्वपूर्ण है जब सार्वजनिक विरासत (एक या कई) के किसी भी रूप कर सम्मान करने के लिए एक संबंध है। एक वर्ग को केवल एक या अधिक कक्षाओं से वंचित होना चाहिए यदि यह उन वस्तुओं में से एक है। यदि यह केवल उन वस्तुओं में से एक "शामिल" होता है, तो इसके बजाय एकत्रीकरण या संरचना का उपयोग किया जाना चाहिए।

ऊपर दिया गया उदाहरण अच्छी तरह से संरचित है क्योंकि एक कुत्ता एक जानवर है, और एक कशेरुका भी है।

+0

यह एकाधिक विरासत नहीं है। यह इंटरफेस का उपयोग है, लेकिन सी ++ बस इसे उसी तरह लागू करने के लिए होता है। – erikkallen

+0

@Erik - यह केवल एक इंटरफ़ेस है यदि मिश्रित वर्ग पूरी तरह से सार है। कोड उदाहरण में मैंने दिया, Vertebrate :: BendSpine() में एक कार्यान्वयन है, यद्यपि एक खाली एक। मैं अभी भी यह एकाधिक विरासत कहूंगा, भले ही यह सबसे अच्छा उदाहरण न हो। – LeopardSkinPillBoxHat

+1

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

2

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

2

मुझे लगता है कि एफएमएसएफ उदाहरण एक बुरा विचार है। एक कार टायर या इंजन नहीं है। आप इसके लिए संरचना का उपयोग करना चाहिए।

एमआई (कार्यान्वयन या इंटरफ़ेस का) कार्यक्षमता जोड़ने के लिए उपयोग किया जा सकता है। इन्हें अक्सर मिक्स्ड कक्षा कहा जाता है .. कल्पना कीजिए कि आपके पास एक जीयूआई है। व्यू क्लास है जो ड्राइंग को संभालने और ड्रैग करने वाले & ड्रॉप क्लास को खींचती है। कभी कभी यह उपयोगिता वर्गों है कि आप की जरूरत की वजह से लेकिन उनके डिजाइन की वजह से आवश्यक हो सकता है: आप एक वस्तु है कि करता है दोनों आप

class DropTarget{ 
public void Drop(DropItem & itemBeingDropped); 
... 
} 

class View{ 
    public void Draw(); 
... 
} 

/* View you can drop items on */ 
class DropView:View,DropTarget{ 

} 
0

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

4

अधिकांश लोग कक्षा में एकाधिक इंटरफेस लागू करने के संदर्भ में एकाधिक विरासत का उपयोग करते हैं। यह दृष्टिकोण जावा और सी # है, दूसरों के बीच, लागू करें।

सी ++ आपको प्रकारों के बीच एक रिश्ते में, कई आधार वर्गों को काफी स्वतंत्र रूप से लागू करने की अनुमति देता है। इसलिए, आप किसी व्युत्पन्न वस्तु का इलाज किसी भी आधार वर्ग की तरह कर सकते हैं।

LeopardSkinPillBoxHat points out के रूप में एक और उपयोग, मिश्र-मिश्रण में है। आंद्रेई अलेक्जेंड्रेस्कू की पुस्तक आधुनिक सी ++ डिजाइन से, इसका एक उत्कृष्ट उदाहरण Loki library है। वह नीति वर्ग का उपयोग करता है जो विरासत के माध्यम से किसी दिए गए वर्ग के व्यवहार या आवश्यकताओं को निर्दिष्ट करता है।

फिर भी एक और उपयोग एक मॉड्यूलर दृष्टिकोण को सरल बनाता है जो API-independence को डरावनी हीरे पदानुक्रम में बहन-श्रेणी प्रतिनिधिमंडल के उपयोग के माध्यम से अनुमति देता है।

एमआई के लिए उपयोग कई हैं। दुर्व्यवहार की संभावना भी अधिक है।

4

जावा में इंटरफेस हैं। सी ++ नहीं है।

इसलिए, एकाधिक विरासत का उपयोग पर किया जा सकता है इंटरफ़ेस सुविधा का अनुकरण करें। आप एक सी # और जावा प्रोग्रामर रहे हैं, हर बार जब आप एक वर्ग है कि एक आधार वर्ग फैली लेकिन यह भी कुछ इंटरफेस को लागू करता है का उपयोग करें, आप की प्रकार हैं एकाधिक वंशानुक्रम स्वीकार कुछ स्थितियों में उपयोगी हो सकता है।

+0

मैं इस से सहमत हूं :) सी ++ सीखने के बारे में सबसे बुरी चीज और फिर बाद में सी # मिश्रणों का मिश्रण है। मैं कभी-कभी खुद को एक मिश्रित इंटरफ़ेस को कार्यान्वित करने के लिए कॉपी-पेस्ट ढूंढता हूं, जो मेरे हिस्से के लिए खराब कोड या डिज़ाइन हो सकता है, लेकिन मैं कुछ और करने के बारे में नहीं सोच सकता - और एक प्रोग्रामर के रूप में आप कॉपी-पेस्ट से नफरत करते हैं – cwap

+0

सी ++ एम्यूलेट इंटरफेस 100% सार वर्गों के साथ। आप किस बारे में बात कर रहे हैं "इंटरफ़ेस सुविधा" क्या है? इंटरफेस के लिए एकाधिक विरासत का जावा/सी # संस्करण? –

+0

सी ++ में 'इंटरफ़ेस' कीवर्ड नहीं है, क्योंकि इसकी आवश्यकता नहीं है (इसमें एकाधिक विरासत है)। यदि जावा और सी # जैसी अन्य भाषाओं में इंटरफेस हैं, तो सी ++ में एकाधिक विरासत में कुछ उपयोग के मामले होना चाहिए। – luiscubal

2

मुझे लगता है कि यह बॉयलरप्लेट कोड के लिए सबसे उपयोगी होगा। उदाहरण के लिए, IDISposable पैटर्न बिल्कुल .NET में सभी वर्गों के लिए समान है। तो फिर से उस कोड को फिर से टाइप क्यों करें?

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

दुर्भाग्य से एकाधिक विरासत दुरुपयोग के लिए बहुत आसान है। लोग जल्दी ही इसे शामिल करने के बजाय लेबलप्रिंटर क्लास को अपने टीसीपीआईपी कनेक्टर वर्ग से चुपचाप मूर्खतापूर्ण चीजें करना शुरू कर देंगे।

+0

सैद्धांतिक रूप से आप सही हैं लेकिन व्यावहारिक रूप से सही होने के लिए बहुत मुश्किल है। और कीमत (आभासी विरासत रचनाकार) बहुत अधिक है। –

+0

वह कीमत केवल तभी भुगतान की जाती है जब आपको एकाधिक विरासत शाखाओं के माध्यम से एक सामान्य आधारित विरासत प्राप्त करने की आवश्यकता हो। प्रैक्टिस में यह शायद ही कभी होता है (और दोहराव वाले आधार पर कोई गैर-मुद्दा बन जाता है)। – Richard

+1

"लोग जल्दी ही इसमें शामिल होने के बजाय लेबलप्रिंटर क्लास को अपने टीसीपीआईपी कनेक्टर वर्ग से चुपचाप मूर्खतापूर्ण चीजें करना शुरू कर देंगे।" वास्तव में? मैंने यह बहुत कुछ सुना है, लेकिन वास्तव में इसका कोई सबूत कभी नहीं हो रहा है। मैंने जो भी सामग्री पढ़ी है वह रचना और विरासत के बीच एक स्पष्ट स्पष्ट भेद बनाती है, और मुझे नहीं लगता कि कोई भी दो भ्रमित कैसे हो सकता है। –

1

यह एक इंटरफेस (जावा या सी # की तरह) के साथ साथ एक सहायक को अग्रेषित की संरचना एकाधिक वंशानुक्रम (विशेष रूप से mixins) के सामान्य उपयोग के कई का अनुकरण कर सकते हैं कि सच है। हालांकि यह अग्रेषण कोड की लागत पर किया जाता है (और DRY का उल्लंघन)।

एमआई मुश्किल क्षेत्रों की संख्या को खोलने करता है, और अधिक हाल ही में कुछ भाषा डिजाइनरों निर्णय ले लिया है कि एमआई के संभावित नुकसान लाभ को दबा देती।

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

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

+1

यदि कोई भाषा सुविधा संभावित रूप से बहुत उपयोगी है, लेकिन आमतौर पर बुरी तरह दुर्व्यवहार किया जाएगा, तो यह संभवतः सी ++ में मौजूद होगा और जावा में अनुपस्थित होगा। विभिन्न भाषा डिजाइन दर्शन। –

+1

हां। जावा बेवकूफों के लिए बनाया गया है। –

1

हमारे उत्पाद मिश्रित वर्गों का उपयोग करने का एक उदाहरण कॉन्फ़िगरेशन सहेजने और उद्देश्यों को पुनर्स्थापित करने के लिए है। एक अमूर्त मिश्रित वर्ग है जो शुद्ध आभासी तरीकों के एक सेट को परिभाषित करता है। सहेजने योग्य कोई भी वर्ग जो मिक्सिन क्लास को सहेजने/पुनर्स्थापित करने से प्राप्त होता है जो स्वचालित रूप से उन्हें उपयुक्त सहेजने/पुनर्स्थापित करने की कार्यक्षमता देता है।

यह उदाहरण वास्तव में एकाधिक वंशानुक्रम की उपयोगिता को वर्णन नहीं है। यहां परिभाषित किया जा रहा है एक अंतर है। एकाधिक विरासत आपको व्यवहार का वारिस करने की अनुमति भी देती है। मिश्रणों का बिंदु कौन सा है।

एक उदाहरण; पिछली संगतता को संरक्षित करने की आवश्यकता के कारण मुझे अपने स्वयं के क्रमिकरण विधियों को लागू करना होगा।

इसलिए प्रत्येक ऑब्जेक्ट को इस तरह एक रीड और स्टोर विधि मिलती है।

Public Sub Store(ByVal File As IBinaryWriter) 
Public Sub Read(ByVal File As IBinaryReader) 

मैं भी ऑब्जेक्ट असाइन और क्लोन करने में सक्षम होना चाहता हूं। तो मैं इसे हर वस्तु पर पसंद करूंगा।

Public Sub Assign(ByVal tObject As <Class_Name>) 
Public Function Clone() As <Class_Name> 

अब वीबी 6 में मेरे पास यह कोड बार-बार दोहराया गया है।

Public Assign(ByVal tObject As ObjectClass) 
    Me.State = tObject.State 
End Sub 

Public Function Clone() As ObjectClass 
    Dim O As ObjectClass 
    Set O = New ObjectClass 
    O.State = Me.State 
    Set Clone = 0 
End Function 

Public Property Get State() As Variant 
    StateManager.Clear 
    Me.Store StateManager 
    State = StateManager.Data 
End Property 

Public Property Let State(ByVal RHS As Variant) 
    StateManager.Data = RHS 
    Me.Read StateManager 
End Property 

ध्यान दें कि स्टेटमैनगर एक धारा है जो बाइट एरे को पढ़ और स्टोर करती है।

यह कोड दर्जनों बार दोहराया जाता है।

अब .NET में मैं जेनेरिक और विरासत के संयोजन का उपयोग करके इसे प्राप्त करने में सक्षम हूं। .NET संस्करण के तहत मेरा ऑब्जेक्ट AssApp, Clone, और State प्राप्त करता है जब वे MyAppBaseObject से प्राप्त होते हैं। लेकिन मुझे इस तथ्य को पसंद नहीं है कि हर वस्तु MyAppBaseObject से प्राप्त होती है।

मैं बस असाइन क्लोन इंटरफ़ेस और BEHAVIOR में मिश्रण करता हूं। बेहतर और पढ़ें इंटरफ़ेस में अलग-अलग मिश्रण करें और फिर असाइन करें और क्लोन में मिश्रण करने में सक्षम हो। यह मेरी राय में क्लीनर कोड होगा।

लेकिन जब मैं इंटरफेस का उपयोग करता हूं तब तक व्यवहार का पुन: उपयोग करने के समय ड्वर्ड किया जाता है। ऐसा इसलिए है क्योंकि अधिकांश ऑब्जेक्ट पदानुक्रमों का लक्ष्य व्यवहार का पुन: उपयोग करने के बारे में नहीं है बल्कि विभिन्न वस्तुओं के बीच संबंधों को सटीक रूप से परिभाषित करना है। किस इंटरफेस के लिए डिजाइन किए गए हैं। तो यह अच्छा होगा कि सी # (या वीबी.नेट) में ऐसा करने की कुछ क्षमता थी, यह मेरी राय में एक शो स्टॉपर नहीं है।

पूरे कारण यह भी एक मुद्दा है कि सी ++ ने पहली बार गेंद को फेंक दिया जब यह इंटरफेस बनाम विरासत मुद्दे पर आया। जब ओओपी ने सभी को शुरू किया तो सोचा कि व्यवहार पुन: उपयोग प्राथमिकता थी। लेकिन यह एक चिमेरा साबित हुआ और केवल विशिष्ट परिस्थितियों के लिए उपयोगी था, जैसे यूआई ढांचा बनाना।

बाद में मिश्रित (और पहलू उन्मुख प्रोग्रामिंग में अन्य संबंधित अवधारणाओं) का विचार विकसित किया गया था। मिश्रित बनाने में एकाधिक विरासत उपयोगी पाया गया था। लेकिन सी # को व्यापक रूप से पहचाने जाने से ठीक पहले विकसित किया गया था। ऐसा करने के लिए शायद एक वैकल्पिक वाक्यविन्यास विकसित किया जाएगा।

1

मुझे संदेह है कि सी ++ में, एमआई एक ढांचे के हिस्से के रूप में सबसे अच्छा उपयोग होता है (पहले मिश्रित कक्षाओं में मिश्रित कक्षाओं)। एकमात्र चीज जिसे मैं निश्चित रूप से जानता हूं वह यह है कि हर बार जब मैंने इसे अपने ऐप्स में उपयोग करने का प्रयास किया है, तो मैंने पसंद को पछतावा समाप्त कर दिया है, और अक्सर इसे बाहर निकालकर जेनरेट कोड के साथ बदल दिया है।

एमआई उन लोगों में से एक है जिसका उपयोग आपको वास्तव में करने की ज़रूरत है, लेकिन सुनिश्चित करें कि आपको वास्तव में इसकी आवश्यकता है।

0

मैं आज इसका इस्तेमाल करने के लिए किया था, वास्तव में ...

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

class A : Parent 
class B : Parent, Child 
class C : Parent, Child 
class D : Child 

:, तब

class Parent 
{ 
    add(Child c) 
    { 
     children.add(c); 
     c.index = children.Count-1; 
     c.parent = this; 
    } 
    Collection<Child> children 
} 

class Child 
{ 
    Parent p; 
    int index; 
} 

डोमेन प्रकार के लिए, मैं इस किया था वास्तव में कार्यान्वयन इंटरफेस और जेनेरिक के साथ सी # में था, और मैं एकाधिक विरासत नहीं कर सका, जैसे कि भाषा समर्थित है (कुछ प्रतिलिपि पेस्ट करना था)। इसलिए, मैंने सोचा कि मैं यह देखने के लिए एसओ खोजूंगा कि लोग एकाधिक विरासत के बारे में क्या सोचते हैं, और मुझे आपका प्रश्न मिला;)

मैं माता-पिता के लिए जोड़ने के कार्यान्वयन के कारण .anotherClass के आपके समाधान का उपयोग नहीं कर सका (इसका संदर्भ - और मैं चाहता था कि यह कुछ अन्य वर्ग न हो)।

यह बदतर हो गया क्योंकि जेनरेट कोड में एक सबक्लास था जो न तो माता-पिता या बच्चा था ... अधिक प्रतिलिपि पेस्ट।

+1

ऐसा लगता है कि आप इसे आवश्यक से अधिक जटिल बना रहे हैं। क्यों न सिर्फ "नोड" है, जिसमें एक माता-पिता (जो नल हो सकता है) और कई बच्चे (जो खाली हो सकते हैं)। फिर बस ए, बी, सी, और डी सभी नोड से विरासत बनाते हैं। –

+0

मैं यह कहने में सक्षम होना चाहता था कि आप ए के माता-पिता का संदर्भ नहीं दे सकते हैं या बच्चे डी में जोड़ सकते हैं (क्योंकि ए के माता-पिता नहीं हैं, और डी में कोई बच्चा नहीं है)। मेरे कार्यान्वयन के साथ, यदि आप कोशिश करते हैं तो यह संकलित नहीं होगा। मैंने जेनेरिक के साथ इसे भी बेहतर किया ताकि आप ए, सी या डी में सी नहीं जोड़ सकें, या यदि आप बी के माता-पिता को संदर्भित करते हैं, तो आपको इसे ए को डालने की आवश्यकता नहीं होगी (यह एक ए होगा जेनेरिक के माध्यम से पहले से ही), आदि – paquetp

संबंधित मुद्दे