एकाधिक विरासत के बिना यह कैसे करें

Question

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

मैं इसे पूरा करने का सबसे अच्छा तरीका जानने का प्रयास कर रहा हूं। मुझे लगता है कि मैंने सी ++ में जो किया होगा वह एकाधिक विरासत है: केवल तीन तरीकों को लागू करने वाले तीन वर्गों को बनाएं, फिर बच्चों को उन तीन वर्गों में से एक के उपयुक्त प्राप्त करें।

जावा में ऐसा करने के लिए कोई सबसे अच्छा अभ्यास है?

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

क्या इनमें से कोई भी समझ में आता है? मैं जल्दी में लिख रहा हूं ...

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

* Delegation 

* Bridge 

* Strategy 

* Composition 

* Decorator (if I was choosing on name alone, I choose this one) 

मैं भी जोड़ने के लिए है कि विधि है कि लागू किया जा रहा है की जरूरत वर्ग की निजी सदस्यों के लगभग सभी के लिए पहुँच की आवश्यकता है। तो यह मेरी पसंद में बड़ा कारक होगा।

Answer 1

यदि आप विरासत के माध्यम से इसे हल करने का आग्रह करते हैं, तो गोफ बुक से bridge pattern यहां सहायता कर सकता है (यह एक उपयुक्त फिट हो सकता है या नहीं, इस पर निर्भर करता है कि कौन से डोमेन चिंताओं को तीन कार्यान्वयन में अलग किया जाता है)। व्यक्तिगत रूप से, मुझे केवल तीन विधि कार्यान्वयन को एक सहायक वर्ग में डालने की संभावना है और कक्षाओं से विधि कॉल को अग्रेषित करने की संभावना है (जेबी निजेट सही ढंग से प्रतिनिधिमंडल के रूप में क्या संदर्भित करता है)।

Answer 2

विरासत के बजाय प्रतिनिधिमंडल का उपयोग करें। अपनी विधि को लागू करने के लिए एक समान सहायक ऑब्जेक्ट में एक ही समूह प्रतिनिधि के सभी वर्ग हैं।

Answer 3

विरासत का उपयोग किए बिना आसान त्वरित आग समाधान कहीं और 3 "सामान्य तरीकों" को सारणित करना होगा, और फिर विधि कॉल दोहराएं।

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

Answer 4

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

दूसरा, आप अपनी "समूह" विधि की कार्यक्षमता को किसी अन्य वर्ग (कार्यान्वयनकर्ता) में हटा सकते हैं। विधि के कार्यान्वयन के साथ 3 अलग-अलग वर्ग बनाएं (या किसी वर्ग में केवल 3 अलग-अलग विधियां) और उन्हें आवश्यकतानुसार बाल कक्षाओं से कॉल करें।

तो, प्रत्येक समूह वर्ग में "समूह" विधि परिभाषित की जाएगी, लेकिन यह केवल 3 संभावित कार्यान्वयनकर्ताओं में से एक को स्पष्ट रूप से कॉल करेगी।

Answer 5

वास्तव में, मैं यहां एक रणनीति पैटर्न गंध करता हूं।

आप बेस क्लास प्रतिनिधि में उस पद्धति को उस रणनीति में प्राप्त कर सकते हैं जो निर्माण पर पारित हो। उप-वर्ग केवल उनके निर्माण के हिस्से के रूप में रणनीतियों के एक सेट में से किसी एक में गुजरते हैं। रणनीतियां स्वयं कक्षा के बाहर या आंतरिक रूप से निजी कक्षाओं के बाहर उपलब्ध कराई जा सकती हैं। यह आपके पदानुक्रम में कुल वर्गों के साथ समाप्त हो सकता है।

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