ब्रिज / ब्रिज डिज़ाइन पैटर्न का गलत उपयोग

प्रागितिहास

ब्रिज डिजाइन पैटर्न के बारे में मैंने यह लेख पढ़ा। काश, यह बहुत बार गलत तरीके से उपयोग किया जाता है। इसके अलावा, मैंने तब बुक ऑब्जेक्ट ओरिएंटेड डिज़ाइन ट्रिक्स खोला । डिजाइन पैटर्न । यह पता चला - और वहां लेखक बहुत अस्पष्ट रूप से इसकी उपस्थिति के कारणों की घोषणा करते हैं और इसका उपयोग कब करना है। इसलिए, नीचे मैं आपको बताऊंगा कि इसका उपयोग कैसे और क्यों करना है।

अद्यतन

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

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

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

लेकिन मैं प्रकाशित नहीं कर सकता - कोई कर्म नहीं है, लेकिन जैसा कि मैं इसे समझता हूं, जब तक मैं टाइप नहीं करता कोई अन्य विकल्प नहीं हैं। तो आप पढ़ना चाहते हैं, आप जानते हैं कि क्या करना है :)

वास्तव में ब्रिज डिजाइन पैटर्न क्या है

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

आइए देखें कि "ब्रिज" पैटर्न क्या है, इस संक्षिप्त अवधि के पीछे क्या है। यह विरासत और एकत्रीकरण के संयोजन से ज्यादा कुछ नहीं है। काश, वे अक्सर नहीं जानते कि एकत्रीकरण क्या है। सरल शब्दों में, यह तब होता है जब एक वस्तु को दूसरे में शामिल किया जाता है।


ब्रिज पैटर्न का उपयोग करने के सही कारण

पुस्तक के लेखक इस लक्ष्य को घोषित करते हैं: "अमूर्त को इसके कार्यान्वयन से अलग करने के लिए।"

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

लेकिन बात कुछ अलग है। और यह उदाहरणों से स्पष्ट हो जाता है। वे उदाहरण दिखाए जाते हैं जहाँ वंशानुक्रम लागू किया जाता है। लेकिन विरासत सरल नहीं है, लेकिन दो अलग-अलग मानदंडों के अनुसार है। उदाहरण के लिए, "विंडोज" को विभिन्न ऑपरेटिंग सिस्टमों के लिए वर्गीकृत किया जा सकता है: XWindow, PMWindow, ..., और विभिन्न प्रयोजनों के लिए: आइकनों के लिए विंडो (IconWindow), संदेशों के लिए विंडो (MessageWindow) ...

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

ध्यान दें कि यह कई उत्तराधिकार के उपयोग का एक उत्कृष्ट उदाहरण है। यानी XIconWindow IconWindow और XWindow के वंशज हैं। लेकिन हाल के रुझानों ने कई विरासत को अनुचित पीएलओ के रूप में पहचाना है। हम यहां चर्चा नहीं करेंगे, लेकिन वास्तव में सैद्धांतिक रूप से कई विरासत अनावश्यक हैं, और विषय क्षेत्र की गलतफहमी है।

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

और निश्चित रूप से नहीं। यह इस समझ को बचाता है कि वस्तुओं के ये पदानुक्रम उनके गुण हैं। और गुणों को कैसे लागू करें? यह सही है, उन्हें निर्दिष्ट ऑब्जेक्ट में शामिल किया गया है। यानी एकत्रीकरण लागू करें।

यह वही है जो "ब्रिज" पैटर्न बनाता है। लेकिन अनिवार्य रूप से यह पैटर्न OOP के अधिक सामान्य सिद्धांतों का एक अनाड़ी विवरण है।

लेकिन फिर कैसे और अधिक सही ढंग से बहस करने के लिए?

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

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

लेकिन "अलार्म" के अमूर्तन से "अलार्म" के कार्यान्वयन को कभी भी अलग न करें। यह केवल पीएलओ की गलतफहमी को इंगित करता है। तो लेख में, जो इस नोट को लिखने के कारण के रूप में कार्य करता है, अलार्म घड़ी के कार्यान्वयन के रूप में घोषित एक इकाई को "पुल" के रूप में प्रस्तुत किया गया है। दिलचस्प है, लेकिन तथाकथित में क्या रहता है अलार्म अमूर्त - एक कार्यान्वयन नहीं?

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

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

युपीडी। अतिरिक्त स्पष्टीकरण।

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

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

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

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

या यह और भी आसान है - क्या कभी मशीन से इंजन को विरासत में मिला है? या कहें कि पत्र का प्रेषक पत्र? या एक डेटाबेस अमूर्त या खिड़की से एक फ़ाइल वर्ग?

लेकिन "ब्रिज" पैटर्न का उपयोग करने के उदाहरणों में, यह प्रारंभिक स्थिति है, जिसे "ब्रिज" का उपयोग करके ठीक किया जाना चाहिए। लेकिन इस बारे में सोचें कि क्या विरासत के ऐसे रूप संभव हैं। आपको क्या लगता है कि आपने ब्रिज का इस्तेमाल तब भी किया था जब आपकी शुरुआती स्थिति कुछ और थी और कुछ और थी?

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

upd2। आइए एक और गलतफहमी को दूर करने की कोशिश करें।

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

upd3। मुझे टिप्पणियों के साथ कुछ समस्याएं हैं। मैं यहां दो सवालों के जवाब देता हूं।

1. TheShock के लिए कई विरासत के बारे में। खैर, जाहिरा तौर पर क्योंकि संकलक यह जांच नहीं कर सकता है कि आपने ऐसा किया है या नहीं, और इसलिए त्रुटियां संभव हैं।

2. कोल्विन की एक रोचक पहेली। विकल्पों में से एक। पहला कदम जीत और Os2 के वारिस के साथ एक पदानुक्रम, ओएस बनाना है। ImageMap LoadFromFile () और पेंट (BigImage argImage) विधियों के साथ एक ImageProcessing इंटरफ़ेस बनाना। विन और ओएस 2 इमेजप्रोसेसिंग को लागू करते हैं, प्रत्येक अपने तरीके से। मैं तैयार पदानुक्रम में रिफैक्टरिंग करके BigImageImp से छुटकारा पाता हूं। BigImage में, मैं ImageProcessing im इंटरफ़ेस को एकत्रित करता हूं। BigImage के वारिसों में, लोड विधि पहले im.oadFromFile () को कॉल करती है, और अंत में शो को im.Paint (यह) कहती है।

क्या आप कह सकते हैं कि एक पुल भी है? लेकिन फिर, कम से कम, शब्दार्थ एक परिमाण स्पष्ट करने का क्रम बन गया।

विकल्प दो (पहले से बना है, और यहां तक ​​कि समानांतर में भी किया जा सकता है, यानी पहला विकल्प रोबोट को छोड़कर)। आप क्लाइंट का उपयोग OSes कर सकते हैं, अर्थात OS.Paint (argBigImage) को कॉल करके। ऐसा करने के लिए, आपको दूसरे तरीके की आवश्यकता होगी ताकि ओएस बिगइमेज विधियों को कॉल करे। यानी पेंट कॉल argImageMap = LoadFromFile (), फिर argBigImage.Load (argImageMap) - छवि का उत्तराधिकारी, उदाहरण के लिए, BmpBigImage अपनी विशिष्ट विशिष्टता करता है। तब ओएस argBigImage.PrepareForShow () कहता है (यह छवि के शो विधि के अर्थ को स्पष्ट करता है, क्योंकि वास्तव में यह पता चला है कि यह खुद को प्रदर्शित नहीं कर सकता है), और फिर ओएस वास्तव में प्रदर्शित करता है। और पहले से ही कोई पुल नहीं है। और यदि आप पहला समाधान निकालते हैं, तो आप ImageProcessing इंटरफ़ेस से छुटकारा पा सकते हैं, लेकिन यह वैकल्पिक है। और वैसे, हम ध्यान दें कि दूसरे विकल्प का आविष्कार केवल पहले को सही शब्दार्थ में विघटित करके किया जा सकता है, और पुल के ढांचे के भीतर सोच वास्तव में कोई विकल्प नहीं है, और समाधान खराब है।