ब्रिज पैटर्न

Question

का लाभ क्या है जब मैं कुछ नया सीखना चाहता हूं, तो मैं खुद से पूछता हूं, जब मैं उस चीज़ को नहीं सीखता तो मुझे क्या खो गया। मैं कुछ डिजाइन पैटर्न सीखने जा रहा हूं और सब कुछ अच्छा है। लेकिन जब मैं Bridge Design Pattern पर पहुंचा तो मैं समस्या में गिर गया। वास्तव में मैं कल्पना नहीं कर सकता कि इस डिजाइन पैटर्न का उपयोग कब करें। और मुझे पता है कि Google और stackoverflow में this जैसे अन्य लिंक हैं।

लेकिन क्या कोई यह कह सकता है कि अगर हम Bridge Design Pattern भूल जाते हैं और इस पैटर्न को आज़माते हैं तो हम क्या खो देते हैं?

Answer 1

ब्रिज पैटर्न बस जिम्मेदारियों converging और उन्हें अलग करने की एक जोड़ी देख रहा है। मैं द गैंग ऑफ फोर (टीजीएफ) के उदाहरण का उपयोग करूंगा क्योंकि मुझे लगता है कि यह वास्तव में अच्छा है:

आपके पास दो उप-वर्गों के साथ एक विंडो इंटरफ़ेस है: एक्सविंडो (एक्स विंडो प्रबंधक के आधार पर) और पीएमविंडो (आधारित आईबीएम के प्रेजेंटेशन मैनेजर (पीएम) विंडो मैनेजर पर ... जिसे मैंने कभी नहीं सुना है)।

अर्थात्:

interface Window {} 
class XWindow : Window {} 
class PMWindow : Window {} 

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

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

interface Window {} 
class XWindow : Window {} 
class PMWindow : Window {} 
interface IconWindow : Window {} 
class XIconWindow : XWindow, IconWindow {} 
class PMIconWindow : PMWindow, IconWindow {} 
interface TransientWindow : Window {} 
class XTransientWIndow : XWindow, TransientWindow {} 
class PMTransientWindow : PMWindow, TransientWindow {} 

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

interface Window {} 
class IconWindow : Window {} //this class... 
class TransientWindow : Window {} //and this one will keep a private reference to aWindowImp 
interface WindowImp: Window {} 
class XWindowImp : WindowImp {} 
class PMWindowImp : WindowImp {} 

बहुत क्लीनर, ज्यादा बेहतर जिम्मेदारी अलगाव, और बहुत आसान लिखने और उपभोग करने के लिए!

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

Answer 2

पुल के फायदे यह है कि अमूर्तता और कार्यान्वयन decoupled हो। कार्यान्वयन को रन टाइम पर गतिशील रूप से भी बदला जाता है और अमूर्तता और कार्यान्वयन की विस्तारशीलता में सुधार होता है।

एक अमूर्तता की पीढ़ी में पैरामीटर निर्दिष्ट करके, कार्यान्वयन को क्लाइंट के कार्यान्वयन के लिए भी चुना जा सकता है। कक्षाओं की संख्या में एक मजबूत वृद्धि से बचा जा सकता है।