वंशानुक्रम बनाम एकत्रीकरण [बंद]


151

ऑब्जेक्ट-ओरिएंटेड सिस्टम में कोड को सर्वश्रेष्ठ रूप से बढ़ाने, बढ़ाने और पुन: उपयोग करने के बारे में विचार के दो स्कूल हैं:

  1. वंशानुक्रम: एक उपवर्ग बनाकर एक वर्ग की कार्यक्षमता का विस्तार करें। नई कार्यक्षमता प्रदान करने के लिए उपवर्गों में सुपरक्लास सदस्यों को ओवरराइड करें। सबक्लासेस को "फिल-इन-द-ब्लक्स" के लिए बाध्य करने के लिए तरीकों को अमूर्त / आभासी बनाएं जब सुपरक्लास एक विशेष इंटरफ़ेस चाहता है लेकिन इसके कार्यान्वयन के बारे में अज्ञेय है।

  2. एकत्रीकरण: अन्य वर्गों को लेने और उन्हें एक नई कक्षा में शामिल करके नई कार्यक्षमता बनाएं। अन्य कोड के साथ इंटरऑपरेबिलिटी के लिए इस नए वर्ग के लिए एक सामान्य इंटरफ़ेस संलग्न करें।

प्रत्येक के लाभ, लागत और परिणाम क्या हैं? क्या अन्य विकल्प हैं?

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


9
अच्छा सवाल, दुर्भाग्य से मेरे पास अब पर्याप्त समय नहीं है।
तून Krijthe

4
एक अच्छा जवाब एक तेजी से एक से बेहतर है ... मैं अपना सवाल देख रहा हूं, इसलिए मैं आपको कम से कम वोट करूंगा :-P
क्रेग वॉकर

जवाबों:


181

यह कोई बात नहीं है कि कौन सा सबसे अच्छा है, लेकिन कब क्या उपयोग करना है।

'सामान्य' मामलों में एक साधारण प्रश्न यह जानने के लिए पर्याप्त है कि क्या हमें विरासत या एकत्रीकरण की आवश्यकता है।

  • नया वर्ग तो है मूल वर्ग के रूप में कम या ज्यादा। विरासत का उपयोग करें। नया वर्ग अब मूल वर्ग का उपवर्ग है।
  • नया वर्ग चाहिए है मूल वर्ग। एकत्रीकरण का उपयोग करें। नए वर्ग में अब मूल वर्ग एक सदस्य के रूप में है।

हालांकि, एक बड़ा ग्रे क्षेत्र है। इसलिए हमें कई अन्य ट्रिक्स चाहिए।

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

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

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

एक उदाहरण जोड़ते हैं। हमारे पास विधियों के साथ एक वर्ग 'डॉग' है: 'खाओ', 'चलो', 'बार्क', 'खेलो'।

class Dog
  Eat;
  Walk;
  Bark;
  Play;
end;

हमें अब एक वर्ग 'कैट' की आवश्यकता है, जिसे 'ईट', 'वॉक', 'पूर' और 'प्ले' की आवश्यकता है। इसलिए पहले इसे डॉग से बढ़ाने की कोशिश करें।

class Cat is Dog
  Purr; 
end;

लगता है, ठीक है, लेकिन रुको। यह बिल्ली बार्क (बिल्ली प्रेमी मुझे उसके लिए मार देगा)। और एक भौंकने वाली बिल्ली ब्रह्मांड के सिद्धांतों का उल्लंघन करती है। इसलिए हमें बार्क विधि को ओवरराइड करने की आवश्यकता है ताकि यह कुछ भी न करे।

class Cat is Dog
  Purr; 
  Bark = null;
end;

ठीक है, यह काम करता है, लेकिन यह बदबू आ रही है। तो एक एकत्रीकरण की कोशिश करते हैं:

class Cat
  has Dog;
  Eat = Dog.Eat;
  Walk = Dog.Walk;
  Play = Dog.Play;
  Purr;
end;

ठीक है, यह अच्छा है। यह बिल्ली अब भौंकती नहीं है, चुप भी नहीं। लेकिन फिर भी इसमें एक आंतरिक कुत्ता है जो बाहर चाहता है। तो समाधान नंबर तीन आज़माएं:

class Pet
  Eat;
  Walk;
  Play;
end;

class Dog is Pet
  Bark;
end;

class Cat is Pet
  Purr;
end;

यह बहुत क्लीनर है। कोई आंतरिक कुत्ते नहीं। और बिल्ली और कुत्ते एक ही स्तर पर हैं। हम मॉडल का विस्तार करने के लिए अन्य पालतू जानवरों को भी पेश कर सकते हैं। जब तक कि यह एक मछली नहीं है, या ऐसा कुछ जो नहीं चलता है। उस मामले में हमें फिर से विचार करने की आवश्यकता है। लेकिन यह एक अन्य समय के लिए कुछ है।


5
"एक वर्ग के लगभग सभी कार्यक्षमता का पुन: उपयोग" एक बार मैं वास्तव में विरासत पसंद करते हैं। मैं वास्तव में क्या पसंद करूंगा , यह एक ऐसी भाषा है जिसमें आसानी से "इन विशिष्ट तरीकों के लिए इस एकत्रित वस्तु को सौंपने" की क्षमता है; यह दोनों दुनिया के लिए सबसे अच्छा है।
क्रेग वाकर

मुझे अन्य भाषाओं के बारे में निश्चित नहीं है, लेकिन डेल्फी में एक तंत्र है, जो सदस्यों को इंटरफ़ेस का हिस्सा लागू करने देता है।
तून Krijthe

2
ऑब्जेक्टिव C उन प्रोटोकॉल का उपयोग करता है जो आपको यह तय करने देते हैं कि आपका फ़ंक्शन आवश्यक है या वैकल्पिक।
cantfindaname88

1
व्यावहारिक उदाहरण के साथ शानदार जवाब। मैं एक विधि के साथ पेट क्लास को डिजाइन करूंगा makeSoundऔर प्रत्येक उपवर्ग को अपनी तरह की ध्वनि को लागू करने दूंगा। यह तब उन स्थितियों में मदद करेगा जहां आपके पास कई पालतू जानवर हैं और बस करते हैं for_each pet in the list of pets, pet.makeSound
ब्लोंगो

38

GOF की शुरुआत में वे राज्य करते हैं

वर्ग विरासत पर अनुकूल वस्तु रचना।

इसकी चर्चा यहाँ पर की गई है


27

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

आगे के भेद भी मौजूद हैं - C ++ में निजी उत्तराधिकार "इंगित करता है" रिश्ते के संदर्भ में कार्यान्वित किया जाता है, जिसे (गैर-उजागर) सदस्य वस्तुओं के एकत्रीकरण द्वारा भी मॉडल किया जा सकता है।


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

मुझे यह दृष्टिकोण पसंद नहीं है, यह रचना के बारे में अधिक है
अलिर्ज़ा रहमानी खलीली

15

यहाँ मेरा सबसे आम तर्क है:

किसी भी वस्तु-उन्मुख प्रणाली में, किसी भी वर्ग के दो भाग होते हैं:

  1. इसका इंटरफ़ेस : ऑब्जेक्ट का "सार्वजनिक चेहरा"। यह क्षमताओं का वह समूह है जो दुनिया के बाकी हिस्सों की घोषणा करता है। बहुत सारी भाषाओं में, सेट को "क्लास" में अच्छी तरह से परिभाषित किया गया है। आमतौर पर ये ऑब्जेक्ट के विधि हस्ताक्षर होते हैं, हालांकि यह भाषा से थोड़ा भिन्न होता है।

  2. इसका कार्यान्वयन : "पर्दे के पीछे" काम जो ऑब्जेक्ट अपने इंटरफ़ेस को संतुष्ट करने और कार्यक्षमता प्रदान करने के लिए करता है। यह आमतौर पर ऑब्जेक्ट का कोड और सदस्य डेटा होता है।

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

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

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

इसलिए, जब भी मैं ऑब्जेक्ट-ओरिएंटेड सॉफ़्टवेयर विकसित कर रहा हूं, मैं लगभग हमेशा विरासत पर एकत्रीकरण पसंद करता हूं।


मुझे लगता है कि आप एक इंटरफ़ेस को परिभाषित करने के लिए एक सार वर्ग का उपयोग करते हैं और फिर प्रत्येक ठोस कार्यान्वयन वर्ग के लिए प्रत्यक्ष उत्तराधिकार का उपयोग करते हैं (इसे बहुत सुंदर बनाते हैं)। कोई भी एकत्रीकरण ठोस कार्यान्वयन के अधीन है।
orcmid

यदि आपको उससे अतिरिक्त इंटरफेस की आवश्यकता है, तो उन्हें मुख्य-स्तरीय अमूर्त इंटरफ़ेस के इंटरफ़ेस पर विधियों के माध्यम से लौटाएं, फिर से दोहराएं।
23

क्या आपको लगता है, इस परिदृश्य में एकत्रीकरण बेहतर है? एक किताब एक SellItem है, एक DigitalDisc एक SelliingItem codereview.stackexchange.com/questions/14077/…
LCJ

11

मैंने "एक" बनाम "एक है" का उत्तर दिया है : कौन सा बेहतर है?

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

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

वे मजबूत संकेत हैं कि एकत्रीकरण उस मामले में बेहतर विकल्प है।


6

मैं इस और संबंधित प्रश्नों पर "बहुत-बहुत बनाम एक है; वे वैचारिक रूप से अलग हैं" प्रतिक्रियाएं देखते हैं।

मेरे अनुभव में जो एक चीज मुझे मिली है, वह यह निर्धारित करने की कोशिश करना है कि क्या कोई रिश्ता "है-एक" या "है-ए" विफल है। यहां तक ​​कि अगर आप सही ढंग से वस्तुओं के लिए उस दृढ़ संकल्प को बना सकते हैं, तो बदलती आवश्यकताओं का मतलब है कि आप भविष्य में किसी बिंदु पर गलत होंगे।

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

और, जैसा कि मैंने इस पोस्ट में कहीं और उल्लेख किया है, एकत्रीकरण विरासत की तुलना में कम लचीला है।

जब भी आपको एक या दूसरे को चुनना हो, तो आपके पास वंशानुक्रम के खिलाफ तर्क का एक सही तूफान है:

  1. आपकी पसंद संभवतः किसी बिंदु पर गलत होगी
  2. आपके द्वारा इसे बना लेने के बाद उस विकल्प को बदलना मुश्किल है।
  3. अधिक विवश होने के कारण वंशानुक्रम एक बुरा विकल्प है।

इस प्रकार, मैं एकत्रीकरण का चयन करता हूं - तब भी जब एक मजबूत रिश्ता है-प्रतीत होता है।


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

मुझे पूछताछ और पूछताछ की यह पंक्ति पसंद है। Blurrung के बारे में चिंतित है एक, एक है, और एक का उपयोग करता है, हालांकि। मैं इंटरफेस के साथ शुरू करता हूं (लागू किए गए अमूर्त को पहचानने के साथ मैं इंटरफेस चाहता हूं)। अप्रत्यक्ष का अतिरिक्त स्तर अमूल्य है। अपने एकत्रीकरण के निष्कर्ष का पालन न करें।
orcmid

हालांकि मेरी बात बहुत सुंदर है। विरासत और एकत्रीकरण दोनों समस्या को हल करने के तरीके हैं । उन तरीकों में से एक सभी प्रकार के दंडों को लागू करता है जब आपको कल समस्याओं को हल करना होता है।
क्रेग वॉकर

मेरे दिमाग में, एकत्रीकरण + इंटरफेस विरासत / उपवर्ग के विकल्प हैं; आप अकेले एकत्रीकरण के आधार पर बहुरूपता नहीं कर सकते।
क्रेग वाकर

3

प्रश्न को सामान्यतया कम्पोजिशन बनाम इनहेरिटेंस के रूप में वर्णित किया जाता है , और यह यहाँ पहले पूछा गया है।


सही है आप .. मज़ेदार है कि SO ने संबंधित प्रश्नों में से एक को नहीं दिया।
क्रेग वॉकर

2
एसओ खोज अभी भी बड़े समय बेकार है
विंको व्रसालोविक

माना। इसलिए मैंने इसे बंद नहीं किया। यह, और बहुत से लोगों ने पहले ही यहाँ उत्तर दिया था।
छिपकली

1
अतः 1 में 2 सवाल (और अपनी प्रतिक्रिया) रोल करने के लिए एक सुविधा की जरूरत है
क्रेग वॉकर

3

मैं इसे मूल प्रश्न पर टिप्पणी करना चाहता था, लेकिन 300 पात्रों को काटता है [; <)।

मुझे लगता है कि हमें सावधान रहने की जरूरत है। सबसे पहले, प्रश्न में किए गए दो विशिष्ट उदाहरणों की तुलना में अधिक स्वाद हैं।

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

उदाहरण के लिए, आप क्या पूरा करने के लिए बाहर हैं, आपके पास क्या है जो आपको शुरू करने के लिए उपलब्ध है, और क्या बाधाएं हैं?

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

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

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


2

मैं जहां-जहां-हो सकता है-भाग लागू करूंगा। यहाँ खेल परिदृश्य में दोनों का उदाहरण दिया गया है। मान लीजिए, एक खेल है जिसमें विभिन्न प्रकार के सैनिक हैं। प्रत्येक सैनिक के पास एक नैकपैक हो सकता है जो विभिन्न चीजों को पकड़ सकता है।

इनहेरिटेंस यहाँ? वहाँ एक समुद्री, हरी बेरी और एक स्नाइपर है। ये सैनिक के प्रकार हैं। इसलिए, व्युत्पन्न वर्गों के रूप में एक बेस क्लास सोल्जर विद मरीन, ग्रीन बेरेट और स्निपर है

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


2

मुझे लगता है कि यह या तो / या बहस नहीं है। ये बस यही है:

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

दोनों का अपना स्थान है, लेकिन उत्तराधिकार जोखिम भरा है।

हालाँकि यह निश्चित रूप से एक वर्ग आकार 'होने नहीं होगा' एक 'प्वाइंट और एक वर्ग वर्ग है। यहाँ वंशानुक्रम देय है।

जब लोग किसी चीज़ को डिज़ाइन करने की कोशिश कर रहे होते हैं, तो वह विरासत के बारे में सोचना शुरू कर देते हैं, जो कि गलत है।


1

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

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

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


0

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

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.