फेकाडे, प्रॉक्सी, एडाप्टर और सजावट डिजाइन पैटर्न के बीच अंतर?

Question

फेकाडे, प्रॉक्सी, एडाप्टर, और सजावटी डिजाइन पैटर्न के बीच क्या अंतर है?

मैंने कभी स्पष्ट स्पष्टीकरण नहीं पढ़ा है, तुम्हारा क्या है?

Answer 1

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

फेकाडे कार्यक्षमता के एक जटिल सेट के लिए एक सरल गेटवे की तरह है। आप अपने ग्राहकों के लिए कम चिंता करने के लिए एक ब्लैक-बॉक्स बनाते हैं i.e. इंटरफ़ेस को सरल बनाएं।

प्रॉक्सी कक्षा के लिए प्रॉक्सिड के समान इंटरफ़ेस प्रदान करता है और आमतौर पर कुछ हाउसकीपिंग सामान स्वयं ही करता है। (इसलिए भारी वस्तु X की कई प्रतियां बनाने के बजाय आप हल्के प्रॉक्सी P की प्रतियां बनाते हैं जो बदले में X प्रबंधित करता है और आवश्यकतानुसार आपकी कॉल का अनुवाद करता है।) आप क्लाइंट की समस्या को हल कर रहे हैं भारी और/या जटिल वस्तु।

डेकोरेटर अपने वस्तुओं के लिए अधिक बारूद जोड़ने के लिए प्रयोग किया जाता है (ध्यान दें अवधि वस्तुओं - आप आमतौर पर वस्तुओं गतिशील रनटाइम पर सजाने)। आप ऑब्जेक्ट के मौजूदा इंटरफेस को छुपा/खराब नहीं करते हैं लेकिन इसे रनटाइम पर बढ़ाएं।

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

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

Answer 2

फसाड

आप एक मुखौटा इस्तेमाल कर सकते हैं, उदाहरण के लिए, एक API आसान करने के लिए कॉल करने के लिए। रिमोट मुखौटा के this उदाहरण पर एक नज़र डालें। यहां विचार यह है कि सर्वर पर कोड का पूर्ण कार्यान्वयन क्लाइंट से छिपा हुआ है। क्लाइंट 1 एपीआई विधि कॉल करता है जो बदले में, सर्वर पर 1 या अधिक एपीआई कॉल कर सकता है।

एडाप्टर

इस का एक अच्छा उदाहरण here पाया जा सकता है, विकिपीडिया पर।क्लाइंट ऑब्जेक्ट Source किसी अन्य ऑब्जेक्ट Target पर एक विधि को कॉल करना चाहता है, लेकिन उस ऑब्जेक्ट का इंटरफ़ेस क्लाइंट की अपेक्षा करने के लिए अलग है।

एडाप्टर ऑब्जेक्ट दर्ज करें।

यह Source ऑब्जेक्ट से कॉल कर सकता है और दृश्यों के पीछे, Target विधि का उपयोग करना चाहिए जिसका उपयोग किया जाना चाहिए।

Source->CallMethodAOnTarget() ---< Adaptor.CallMethodAOnTarget() this calls ---> Target.MethodWithDifferentSignatureAndName(int i)

प्रॉक्सी के रूप में, मैं इस डिजाइन पैटर्न के किसी भी अनुभव नहीं है।