पुल पैटर्न - जावा में संकलन का लाभ?

Question

यह डिजाइन पैटर्न में कहा गया है - पुन: प्रयोज्य वस्तु उन्मुख सॉफ्टवेयर के तत्वों पुस्तक:

स्थितियों में वहाँ जहां केवल एक कार्यान्वयन (एक-से-एक), बनाने में कोई सार implementor वर्ग नहीं है जरूरी है। यह पुल पैटर्न के का एक अपमानजनक मामला है; एब्स्ट्रक्शन और कार्यान्वयनकर्ता के बीच एक-से-एक संबंध है। फिर भी, यह पृथक्करण अभी भी उपयोगी है जब किसी वर्ग के कार्यान्वयन में परिवर्तन को अपने मौजूदा क्लाइंट को प्रभावित नहीं करना चाहिए- यह पुन: संकलित नहीं होना चाहिए , बस relinked।

मुझे संकलन समय के लाभ के बारे में संदेह है क्योंकि मैं जावा में एक केस की कल्पना नहीं कर सकता जहां कार्यान्वयन में बदलाव इसके सुपरक्लास (इस मामले में सार) को पुन: संकलित करता है।

उदाहरण के लिए, अगर हम एक्स फैली Y और एक ग्राहक की क्या ज़रूरत है:

Y y = new X(); 

एक्स में बदलाव Y एक रखता मतलब यह नहीं है (बेशक हम नहीं विधि हस्ताक्षर बदलना चाहते हैं

YAbstraction yabstraction = new YRefinedAbstraction(new XImplementor()); 

XImplementor में बदलाव YAbstraction एक रखता मतलब यह नहीं है: एक्स का)

यह बिल्कुल वही बात जब पुल पैटर्न का उपयोग कर रहा है।

तो, मेरे अनुसार, यह लाभ जावा में नहीं होता है और एक-से-एक => कोई ब्रिज पैटर्न की आवश्यकता नहीं होती है।

शायद अन्य भाषाओं में एक उप-वर्ग बल सुपरक्लास को बदलने के लिए? स्मॉलटाक और सी ++ की तरह?

आपकी राय क्या हैं?

Answer 1

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

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

एस्ट्रैक्शन के सी ++ ग्राहकों में पुन: संकलित करने की आवश्यकता नहीं होगी, केवल रिंकंक्ड किया जाएगा। जावा में, आपके लिंक करने के बजाय आपको क्लास लोडिंग है और इस प्रकार आपको केवल नई सेटिंग्स और एक नई जार फ़ाइल के साथ एप्लिकेशन को पुनः लोड करना होगा।

उदाहरण के लिए एक स्थिति की कल्पना करें जब एक कमांड लाइन विकल्प या एक पर्यावरण चर का उपयोग एक सार फैक्ट्री द्वारा किया जाता है ताकि पुल को सही प्रकार के कंक्रीटइम्पमेंटर के साथ कॉन्फ़िगर किया जा सके। इस तरह के मामले में आपको बस नई कमांड लाइन/पर्यावरण सेटिंग्स और नए कंक्रीटइम्पमेंटर वाली एक नई जार फ़ाइल के साथ एप्लिकेशन को फिर से लोड करने की आवश्यकता है। आप क्लाइंट कोड को पुन: संकलित किए बिना ऐसा कर सकते हैं।

इस प्रकार आपके प्रश्न का सीधा जवाब प्रदान करने के लिए: जावा में ब्रिज पैटर्न में प्रश्न में वर्णित लाभ होता है। संभवत: अधिक हद तक यदि आप इस तथ्य को गिनते हैं कि कोई रिंकंकिंग नहीं होती है।

Answer 2

जावा में "लिंकिंग" नहीं है जैसे सी/सी ++ करता है। हालांकि, मुझे लगता है कि अवधारणा अब भी लागू होता है: अगर कार्यान्वयन वर्ग अमूर्त से एक अलग पुस्तकालय (.jar फ़ाइल) में है, तो आप .jar अमूर्त युक्त फ़ाइल repackage करने के लिए नहीं है। यह एक जटिल प्रणाली के रखरखाव को सरल बना सकता है। अमूर्त के लिए एक और implementor के लिए एक (XWindowImpl और PMWindowImpl तरह व्युत्पन्न वर्ग के साथ जैसे WindowImpl) (DialogWindow और IconWindow तरह व्युत्पन्न वर्ग के साथ जैसे विंडो):