विरासत एकत्रीकरण

Question

कैसे सबसे अच्छा, विस्तार को बढ़ाने, और एक वस्तु उन्मुख प्रणाली में कोड पुन: उपयोग करने पर दो विचारधारायें हैं:

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

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

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

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

Answer 1

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

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

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

हालांकि, एक बड़ा ग्रे क्षेत्र है। तो हमें कई अन्य चाल की जरूरत है।

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

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

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

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

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; 

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

Answer 2

अंतर आम तौर पर "एक है" और "है" के बीच अंतर के रूप में व्यक्त किया जाता है। विरासत, "एक" संबंध है, Liskov Substitution Principle में अच्छी तरह से संक्षेप में है। एकत्रीकरण, "एक है" रिश्ते, बस यही है - यह दिखाता है कि समेकित वस्तु में समेकित वस्तुओं में से एक है।

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

Answer 3

GOF की शुरुआत में वे कक्षा विरासत से अधिक

फ़ेवर वस्तु रचना राज्य।

यह आगे चर्चा की है here

Answer 4

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

यहां विरासत? एक समुद्री, हरा beret & एक स्निपर है। ये सैनिकों के प्रकार हैं। तो, समुद्री, ग्रीन बेरेट & स्निपर के साथ एक बेस क्लास सैनिक है जो व्युत्पन्न कक्षाओं के रूप में

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

Answer 5

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

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

Answer 6

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

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

दोनों की जगह है, लेकिन विरासत जोखिम भरा है।

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

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

Answer 7

प्रश्न सामान्यतः Composition vs. Inheritance के रूप में phrased है, और इससे पहले यहां पूछा गया है।

Answer 8

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

1. इसके इंटरफ़ेस: वस्तु के "सार्वजनिक चेहरा"

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

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

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

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

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

तो, जब भी मैं ऑब्जेक्ट उन्मुख सॉफ़्टवेयर विकसित कर रहा हूं, मैं लगभग हमेशा विरासत पर एकत्रीकरण पसंद करता हूं।

Answer 9

मैंने "Is a" vs "Has a" : which one is better? का उत्तर दिया।

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

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

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

Answer 10

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

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

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

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

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

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

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

Answer 11

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

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

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

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

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

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

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

Answer 12

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

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

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