अधिकांश ओओपी प्रशंसक एक ही समय में बहुरूपता के प्रशंसक हैं। कई अच्छी किताबें (यहां तक कि फाउलर की रीफैक्टरिंग भी) चरम सीमा पर जाती हैं और दावा करती हैं कि यदि आप रन टाइम (जैसे जावा में इंस्टोफ ऑपरेशन) में टाइप चेक का उपयोग करते हैं, तो आप सबसे अधिक संभावना दिल में एक भयानक राक्षस हैं। उनमें से जो छोटे बच्चों को
switch डराते हैं।
आमतौर पर, मैं स्वीकार करता हूं कि
instanceof और इसके एनालॉग्स का उपयोग
आमतौर पर अपर्याप्त ओओपी डिज़ाइन कौशल का परिणाम है। बहुरूपता प्रकार की जाँच से बेहतर है। यह कोड को अधिक लचीला और समझने योग्य बनाता है। हालांकि, कम से कम एक सामान्य मामला है जहां आप निश्चित रूप से बहुरूपता का उपयोग नहीं कर सकते हैं। इसके अलावा, यह मामला इतना व्यापक है कि इसे पहले से ही एक पैटर्न माना जा सकता है। मैं इसमें ईमानदारी से बहुरूपता का उपयोग करना पसंद करूंगा। और अगर आप जानते हैं कि यह कैसे करना है - मुझे बताओ। लेकिन मुझे नहीं लगता कि यह संभव है। कम से कम जावा या सी ++ जैसी स्थिर भाषाओं में तो बिल्कुल नहीं।
बहुरूपता की परिभाषा
यदि आप OOP शब्दावली से परिचित नहीं हैं, तो मैं समझाऊंगा कि क्या दांव पर लगा है। बहुरूपता देर बंधन की अवधारणा के लिए एक महत्वाकांक्षी पदनाम है। देर से बाध्यकारी, बदले में, एक दिखावा पदनाम है (यदि आप गहराई से खुदाई करते हैं तो आपको यहां एक पैटर्न मिलेगा) एक ऐसी स्थिति के लिए जिसमें कार्यक्रम शुरू होने तक किसी विशेष विधि के बारे में निर्णय स्थगित कर दिया जाता है। इस प्रकार, वस्तु और संदेश (यानी विधि) के पत्राचार की जांच आवेदन के दौरान पहले से ही की जाएगी।
प्रदर्शन-उन्मुख प्रोग्रामिंग भाषाओं जैसे कि C ++, Java या OCaml में, संख्याएँ विधियों को सौंपी जाती हैं, और फिर प्रत्येक वर्ग के लिए इसके तरीकों की एक तालिका बनाई जाती है। जिससे सर्च रनटाइम पर किया जाता है। लचीलापन और गतिशीलता को पसंद करने वाली भाषाओं में, खोज संख्याओं के बीच नहीं, बल्कि हैशेड विधि नामों के बीच की जाती है। अन्यथा, ये दोनों दृष्टिकोण लगभग समान हैं।
अकेले आभासी तरीके बहुरूपता उत्पन्न नहीं करते हैं। यह तब ही खेल में आता है जब एक वर्ग में कई उपवर्ग होते हैं। इसके अलावा, जिनमें से प्रत्येक अपने स्वयं के, विशेष, बहुरूपी विधि के संस्करण को लागू करता है। पाठ्यपुस्तक से सबसे अधिक प्रतिबंधात्मक उदाहरण में, यह चिड़ियाघर के साथ सादृश्य द्वारा चित्रित किया जाएगा, जिसमें सभी जानवर अलग-अलग संदेश का इलाज करते हैं।
() । (हालांकि पाठ्यपुस्तक वास्तव में झूठ बोलती है - सभी गंध बहुत समान हैं, यह सिर्फ
आकार है । मेरे विनम्र में, निश्चित रूप से। सच है, मैंने अभी भी तय नहीं किया है कि अधिकतम कौन है - हिप्पो या जिराफ? इसके बारे में थोड़ा बाद में पूछें। )
कार्रवाई में बहुरूपता
एक उदाहरण के रूप में, आइए एक गणितीय अभिव्यक्ति की गणना की क्लासिक समस्या पर एक नज़र डालें, जो अक्सर साक्षात्कारों में पाया जाता है। इसका उपयोग पहली बार अमेज़ॅन में रॉन ब्रुनस्टीन द्वारा किया गया था (जहां तक मुझे पता है)। कार्य काफी जटिल है और आपको कई महत्वपूर्ण कौशल के कब्जे की जांच करने की अनुमति देता है। यह ओओपी डिज़ाइन, और पुनरावर्तन, और बाइनरी ट्री, और बहुरूपता गतिशील टाइपिंग, और प्रोग्राम करने की सामान्य क्षमता, और यहां तक कि (यदि आप अचानक कार्य
को अधिकतम करने के लिए जटिल करना चाहते हैं) के साथ जोड़ा गया है।
इसलिए, इस कार्य पर विचार करते हुए, किसी बिंदु पर उम्मीदवार को पता चलता है कि यदि आप केवल बाइनरी संचालन का उपयोग करते हैं, जैसे "+", "-", "*", "/", तो अंकगणितीय अभिव्यक्ति को बाइनरी ट्री के रूप में दर्शाया जा सकता है। पेड़ के सभी पत्ते नंबर होंगे, और सभी मध्यवर्ती नोड्स ऑपरेशन होंगे। पेड़ की ट्रेसिंग करके अभिव्यक्ति की गणना की जाएगी। यदि आवेदक स्वतंत्र रूप से इस तरह के निर्णय के लिए नहीं आ सकता है, तो आप विनम्रतापूर्वक संकेत दे सकते हैं। या, अगर चीजें वास्तव में खराब हैं, तो इसे माथे में कहें। दरअसल, इसके बाद भी, कार्य अभी भी दिलचस्प बना रहेगा।
इसका पहला भाग, जिसे कुछ लोग (जिनके नाम मैं अपने साथ कब्र पर ले जाऊंगा, लेकिन जिनके शुरुआती विली लेविस) उन लोगों के लिए एक आवश्यकता के रूप में मानते हैं, जो खुद को एक डेवलपर के रूप में बुलाना चाहते हैं और अमेज़न में काम करते हैं, वास्तव में काफी जटिल है। यहाँ सवाल यह है कि कैसे एक स्ट्रिंग से एक अंकगणितीय अभिव्यक्ति, जैसे कि "2 + (2)", अभिव्यक्ति ट्री तक जाना है। और यह एक गंभीर सवाल है।
हम समस्या के दूसरे भाग में रुचि रखते हैं: मान लीजिए कि आप इसे एक साथ हल करते हैं और आपका साथी स्ट्रिंग को एक पेड़ में बदलने के लिए जिम्मेदार है (हम उसे विली कहेंगे)। आपको बस यह तय करने की आवश्यकता है कि विली अपने पेड़ों का निर्माण किन वर्गों से करेगा। आप कोई भी भाषा चुन सकते हैं। मुख्य बात, इसे करना न भूलें, क्योंकि विली असेंबलर को वरीयता दे सकते हैं। इसके अलावा, प्रोसेसर द्वारा कोडांतरक को लंबे समय तक बंद कर दिया गया है। यदि आप बुरे मूड में हैं, तो निश्चित रूप से।
आप चकित होंगे कि यह मंच कितने विषयों पर चकराता है।
ऐसा लगता है कि मैंने पहले ही इसे सही उत्तर के बारे में बता दिया है, लेकिन समाधान का एक तरीका या दूसरा तरीका इस प्रकार दिखता है। मानक खराब समाधान
switch या
case (सबसे खराब, अच्छी पुरानी कैस्केडिंग
if ) का उपयोग करने के लिए है। थोड़ा बेहतर समाधान फ़ंक्शन पॉइंटर्स की तालिका का उपयोग करेगा। और अंत में, शायद सबसे अच्छा समाधान बहुरूपता को लागू करेगा। अपने आराम से उनमें से प्रत्येक को लागू करने का प्रयास करें। यह बचाता है!
विडंबना यह है (जैसा कि आप बाद में देखेंगे), बहुरूपता के साथ एक समाधान एक एक्स्टेंसिबल सिस्टम के लिए आदर्श है। यदि आप 500 से मामलों में अपने विशालकाय स्विच ऑपरेटर से अधिक से अधिक मामलों को जोड़ने के बिना और विशेष रूप से, सब कुछ को फिर से जोड़ने के बिना नए कार्यों को जोड़ना चाहते हैं, तो आपको बस बहुरूपता
का उपयोग करना होगा।
तीन बार बहुरूपता बहुरूपता के सम्मान में जयकार करता है
इस प्रकार, बहुरूपता, एक तरह से या किसी अन्य, लेकिन उपयोगी लगता है। शायद सबसे सफल एप्लिकेशन पॉलीमॉर्फिक प्रिंट ऑपरेटर है। यदि आप जावा, पाइथन, रूबी, या किसी अन्य "वास्तविक" ऑब्जेक्ट-ओरिएंटेड भाषा में प्रोग्राम करते हैं, तो आप शायद इसे प्रदान कर सकते हैं। आप वस्तु को खुद से प्रिंट करने के लिए कहते हैं, और वह, वह करता है। प्रत्येक वस्तु अपने बारे में उतनी ही रिपोर्ट करती है जितनी आपको उसकी आंतरिक स्थिति के बारे में जानने की आवश्यकता होती है। यह डिबगिंग, ट्रेसिंग, लॉगिंग और संभवतः प्रलेखन के लिए बहुत उपयोगी है।
यदि आप O ++ भाषा के लिए एक कटे-फटे नकली का उपयोग करते हैं, जैसे C ++ या पर्ल, जिसमें सभी ऑब्जेक्ट-ओरिएंटेशन को 1978 के सुबारू लिगेसी के लिए $ 2500 की डिस्क की तरह खराब कर दिया जाता है, तो आप संभवतः डिबगर में फंस जाते हैं। या
Data::Dumper ई। या ऐसा कुछ और। सामान्य तौर पर, आप बेकार है!
(अलंकारिक प्रश्न: हम C ++ या पर्ल का चयन क्यों करते हैं? ये दुनिया की दो सबसे भयानक भाषाएं हैं! हम पास्कल या कोबोल का उपयोग कर सकते हैं, क्या यह स्पष्ट नहीं है?)
वैसे, पॉलीमॉर्फिक
print मुख्य कारण है जो मैंने हाल ही में ओकेमेल के बारे में नहीं लिखा है। उन कारणों के लिए जो मुझे अभी तक पूरी तरह से समझ में नहीं आए हैं, लेकिन जो निश्चित रूप से द मोस्ट इन्सान लैंग्वेजेज़ डिज़ाइनर्स मोटिव्स की सूची में हैं, ओकेमेल में पॉलीमॉर्फिक
print नहीं है। इसलिए, आप डीबगिंग के लिए कंसोल के लिए मनमाने ऑब्जेक्ट्स आउटपुट नहीं कर सकते। मैं यह
विश्वास करने की कोशिश करता हूं कि पौराणिक प्रदर्शन को प्राप्त करने की आवश्यकता थी जो कि C ++ से भी बेहतर है। क्योंकि कोई अन्य कारण प्रयोज्य के लिए एक राक्षसी अपमान होगा। ठीक है, लेकिन उनके पास एक डिबगर है जो कार्यक्रम को समय पर वापस करने में सक्षम है। यह निश्चित रूप से एक से अधिक बार काम में आएगा।
इसलिए, हम सभी को बहुरूपता पसंद है। यह micromanagement का एक विकल्प है। आप वस्तुओं को बिना कुछ कहे
कैसे करने के लिए कहते हैं, और वे आज्ञाकारी रूप से पालन करते हैं। स्ट्रॉन्ग बैड वीडियो ऑनलाइन देख कर दिन बिताते हैं। ओह, उन मूर्ख वस्तुओं! उनसे प्यार नहीं करना असंभव है!
लेकिन सभी योग्य नायकों की तरह बहुरूपता का एक डार्क साइड है। बेशक, अनकिन स्काईवॉकर के रूप में अंधेरा नहीं है, लेकिन फिर भी।
बहुरूपता का विरोधाभास
बहुरूपता के उपयोग में शायद ही कभी कहा जाता है, लेकिन एक बहुत महत्वपूर्ण शर्त है: आपको भविष्य में कोड को बदलने में सक्षम होना चाहिए। आखिरकार, कम से कम सांख्यिकीय रूप से टाइप की जाने वाली भाषाओं में, जैसे कि जावा और सी ++, जब आप एक पॉलीमॉर्फिक विधि जोड़ते हैं, तो आपको इस पद्धति को लागू करने वाले सभी वर्गों को फिर से जोड़ने की आवश्यकता होती है। और यह बदले में, इसका मतलब है कि आपको उनके स्रोत कोड तक पहुंच की आवश्यकता है। और इसे संशोधित करने की क्षमता भी।
प्रणालियों का एक निश्चित वर्ग है जिसके लिए यह संभव नहीं है - तथाकथित एक्स्टेंसिबल सिस्टम।
मान लीजिए कि आप एक काल्पनिक प्रणाली डिजाइन कर रहे हैं जो उपयोगकर्ताओं को अपना कोड जोड़ने की अनुमति देती है। यह कई कारणों से एक तुच्छ कार्य नहीं है, जिसमें अनधिकृत पहुंच से सुरक्षा की आवश्यकता, स्ट्रीमिंग सुरक्षा सुनिश्चित करना और बहुत कुछ शामिल है। लेकिन ऐसे सिस्टम मौजूद हैं! उदाहरण के लिए, ऑनलाइन गेम हैं जो खिलाड़ियों को मूल स्रोत कोड तक पहुंच के बिना परिवर्तन करने की अनुमति देते हैं। वास्तव में, अधिकांश ऑनलाइन मल्टीप्लेयर गेम इस दिशा में आगे बढ़ रहे हैं - कंपनियों के प्रबंधन ने महसूस किया कि उपयोगकर्ता स्वयं उत्कृष्ट सामग्री बना सकते हैं और बनाएंगे। इसलिए, गेम अपने एपीआई को खोलते हैं और खिलाड़ियों को अपने स्वयं के राक्षसों, उनके मंत्र और सूची में आगे बढ़कर कार्यक्रमों का विस्तार करने की अनुमति देते हैं।
कुछ मुझे बताता है कि वेब सेवाएं ऑनलाइन गेम के समान नाव में हैं।
हर बार जब आप ऐसी एक्सटेंसिबल प्रणाली बनाते हैं, तो आपको तीन गुना अधिक काम करना होगा। आंतरिक एपीआई और कक्षाएं डिज़ाइन करें ताकि उन्हें अंतिम उपयोगकर्ताओं द्वारा संशोधित किया जा सके।
एक अच्छा उदाहरण जावा स्विंग है। प्रत्येक एक्स्टेंसिबल सिस्टम एक आविष्कारक विरोधाभास के साथ सामना किया जाता है। आप इस विरोधाभास के बारे में कहीं और पढ़ सकते हैं, मैं केवल सार के बारे में कहूंगा: आप पहले से अनुमान नहीं लगा सकते हैं कि उपयोगकर्ता क्या बदलाव करना चाहते हैं। आप कुछ भी कर सकते हैं - यहां तक कि कोड की प्रत्येक पंक्ति को एक अलग आभासी फ़ंक्शन के रूप में उजागर करें - लेकिन उपयोगकर्ता अनिवार्य रूप से कुछ ऐसा सामना करेंगे जो वे चाहते हैं या संशोधित नहीं कर सकते हैं। यह एक वास्तविक त्रासदी है - कोई सुंदर समाधान नहीं है। स्विंग बहुत सारे हुक प्रदान करके लड़ने की कोशिश कर रहा है। लेकिन यह इसके एपीआई को बहुत बोझिल और सीखने में मुश्किल बनाता है।
समस्या का सार
वार्तालाप को अधिक विशिष्ट बनाने के लिए, आइए ऑनलाइन गेम के उदाहरण पर वापस जाएं। मान लीजिए कि आपने मंत्र, राक्षस और अन्य गेम ऑब्जेक्ट बनाने और प्रबंधित करने के लिए सभी एपीआई और कक्षाओं को पूरी तरह से डिज़ाइन और प्रकाशित किया है। मान लीजिए कि आपके पास राक्षसों का एक बड़ा आधार है। यदि आप कोशिश करते हैं तो मुझे यकीन है कि आप इसकी कल्पना कर सकते हैं
अब मान लीजिए कि एक खिलाड़ी एक छोटा पालतू जानवर बनाना चाहता था जिसका नाम मूल्यांकन एल्फ है। यह, बेशक, एक दूरगामी उदाहरण है, रोकने की समस्या को साबित करने के लिए समान रूप से काम कर रहा है, लेकिन वास्तविक जीवन में एक समान स्थिति काफी संभव है।
हमारे मूल्यांकन एल्फ के जीवन का एकमात्र उद्देश्य यह घोषणा करना है कि वह अन्य राक्षसों को पसंद करता है या नहीं। वह आपके कंधे पर बैठता है और जब भी आप मिलते हैं, कहते हैं, Orc, वह खून से लथपथ चिल्लाता है: "मुझे orcs से नफरत है !!!" आआआआआआआ !!! ”(वैसे, ये वही भावनाएं हैं जो मैं सी ++ के बारे में महसूस करता हूं)
इस समस्या का एक बहुरूपी समाधान सरल है: अपने प्रत्येक 150 राक्षसों पर पुनरावृति करें और एक विधि जोड़ें जिससे उन्हें
() ।
अरे! यह भी मूर्खतापूर्ण लगता है। लेकिन यह वास्तव में बहुरूपी दृष्टिकोण है, है ना? यदि समान वस्तुओं (हमारे मामले में, राक्षसों) का एक समूह है, और उन सभी को एक ही स्थिति में अलग-अलग तरीकों से प्रतिक्रिया करनी चाहिए, तो आप उनके लिए एक आभासी विधि जोड़ते हैं और इसे अलग-अलग वस्तुओं के लिए अलग-अलग लागू करते हैं। है न?
जाहिर है, यह दृष्टिकोण हमारे मामले में काम नहीं करेगा, और यहां तक कि अगर यह काम
कर सकता है (और यह नहीं कर सकता है - क्योंकि जो उपयोगकर्ता इस छोटे योगिनी ने स्रोत कोड तक पहुंच नहीं है), वह निश्चित रूप से खराब डिजाइन का स्वाद होगा। बेशक, खेल में हर राक्षस के लिए इस तरह की विशिष्ट विधि को जोड़ने का कोई कारण नहीं है। क्या होगा अगर बाद में यह स्पष्ट हो जाए कि मूल्य एल्फ कॉपीराइट का उल्लंघन करता है और उसे हटाने की आवश्यकता है? आपको सभी 150 वर्गों से इस पद्धति को हटाकर अपनी मूल स्थिति में सब कुछ वापस करना होगा।
जहां तक मुझे पता है (और मैं एक अच्छे डिजाइनर की प्रशंसा करने का नाटक नहीं करता हूं, मैं सिर्फ सही उत्तर खोजना चाहता हूं), सही समाधान गतिशील प्रकार का निर्धारण है। कोड कुछ इस तरह दिखेगा:
public boolean ( mon) { if (mon instanceof ) { return false; } if (mon instanceof ) { return true; } ... < 150 > }
बेशक, आप एक OOP सनकी हो सकते हैं और मूल्यांकन एल्फ के लिए 150 हेल्पर कक्षाएं बना सकते हैं, प्रत्येक राक्षस के लिए एक। यह अभी भी समस्या की जड़ को हल नहीं करेगा, क्योंकि इसका सार इस तथ्य में निहित है कि अलग-अलग व्यवहार को बुलाया पार्टी पर लागू नहीं होता है, लेकिन कॉलर को। यह उसका है।
कुछ उच्च-स्तरीय भाषाओं में, समस्या को थोड़ा और सुरुचिपूर्ण ढंग से हल किया जाता है (मैं जोर देता हूं - केवल थोड़ा सा)। रूबी में, उदाहरण के लिए, अन्य वर्गों के तरीकों को जोड़ना समर्थित है। और पुस्तकालय वाले भी। और भले ही आपके पास सोर्स कोड न हों। उदाहरण के लिए, आप मूल्यांकन एल्फ फ़ाइल में निम्न कोड डाल सकते हैं:
class def ; return false; end end class def ; return false; end end class def ; return true; end end ...
रूबी सूचीबद्ध सभी वर्गों को लोड करेगा, अगर वे पहले से लोड नहीं हैं, और उनमें से प्रत्येक में अपनी विधि जोड़ें। यह एक बहुत अच्छी सुविधा है, आम तौर पर बोल रहा हूँ।
लेकिन इस दृष्टिकोण में पेशेवरों और विपक्ष दोनों हैं। यह कैसे काम करता है? रूबी में (अधिकांश अन्य उच्च-स्तरीय भाषाओं में), विधियाँ वर्ग के अनुरूप हैश तालिका में प्रविष्टियाँ हैं। और फिर आप दिखाई देते हैं और प्रत्येक राक्षस उपवर्ग के हैश तालिका में अपनी प्रविष्टि जोड़ते हैं। फायदे:
- मूल्यांकन एल्फ के सभी कोड इसकी फ़ाइल में निहित हैं;
- एक योगिनी फ़ाइल लोड होने तक कक्षाओं में कोड नहीं जोड़ा जाता है;
- न केवल योगिनी, बल्कि सिस्टम में कोई और भी राक्षस से पूछ सकता है कि योगिनी को यह पसंद है या नहीं।
नुकसान यह है कि आपको उस मामले के लिए डिफ़ॉल्ट व्यवहार प्रदान करना होगा जब योगिनी राक्षस को नहीं पहचानती है, क्योंकि यह योगिनी के लिखे जाने के बाद खेल में जोड़ा गया था। अगर कोई ग्रेमलिन के साथ आता है, तो आपका योगिनी फ्रीज़ करेगा, "गॉड लानत क्या है?"
मुझे लगता है कि अगर कोई किसी तरह सिस्टम में सभी वर्गों के माध्यम से छांट सकता है और जांच सकता है कि क्या वे मॉन्स्टर के वंशज हैं, तो सब कुछ कोड की कुछ पंक्तियों के साथ तय किया जाएगा। रूबी में, मुझे यकीन है कि यह संभव है ... लेकिन केवल पहले से लोड की गई कक्षाओं के लिए। डिस्क पर अभी भी कक्षाओं के लिए, यह काम नहीं करेगा! निश्चित रूप से आप इस समस्या को हल कर सकते हैं, लेकिन डिस्क के अलावा, एक नेटवर्क भी है ...
हालाँकि, डिफ़ॉल्ट व्यवहार की आवश्यकता सबसे खराब नहीं है। इसके और भी गंभीर नुकसान हैं। धागा सुरक्षा कहें। यह मुझे गंभीर रूप से परेशान करता है - मुझे नहीं लगता कि इस मामले में धागा सुरक्षा के लिए रूबी के शब्दार्थ स्पष्ट रूप से परिभाषित हैं। क्या कक्षा-स्तरीय सिंक्रनाइज़ेशन होगा? पूर्व-योगिनी वर्ग के उदाहरणों की धाराओं का क्या होगा? मैं विनिर्देशों या स्रोत कोड को समझने के लिए अभी तक पर्याप्त जापानी नहीं जानता।
लेकिन
वास्तव में समस्या क्या है, जो मुझे
वास्तव में परेशान करता है वह यह है कि कोड सिस्टम में सभी वर्गों में गुणा करना शुरू कर देता है। यह एनकैप्सुलेशन उल्लंघन का कारण बनता है।
यह वास्तव में बदतर है। ख़राब डिज़ाइन की गंध। हमें एक ऐसी स्थिति मिलती है जिसमें पर्यवेक्षक एक प्रकार का निर्णय लेता है और हम इन निर्णयों के कोड को अवलोकन की वस्तुओं से जोड़ देते हैं। ऐसा लगता है कि जैसे मैं अपनी मंजिल से सहकर्मियों के आसपास चला गया और प्रत्येक व्यक्ति को शब्दों के साथ एक बिल्ला दिया: “कृपया, कहीं भी ऐसा न करें। मैं उससे समझ सकता हूं कि मैं तुम्हें पसंद करता हूं या नहीं। ” वास्तविक दुनिया में, सब कुछ अलग तरीके से काम करता है, और ओओपी को वास्तविक दुनिया का मॉडल बनाना है।
संशोधन बहुरूपता
खैर, अब जब मैंने अपना विचार
इतनी स्पष्ट रूप से तैयार कर लिया है,
तो बहुरूपता अब चांदी की गोली की तरह नहीं लगती। नॉन-एक्सपेंडेबल सिस्टम में भी, यदि आप ऑब्जेक्ट के प्रकार के आधार पर कुछ विकल्प बनाना चाहते हैं, तो यह चयन को इस ऑब्जेक्ट में स्थानांतरित करने का कोई मतलब नहीं है।
एक उदाहरण के रूप में, प्रमाणीकरण लेने के लिए यह अधिक व्यावहारिक और स्पष्ट है। मुझे आपसे पूछना चाहिए: यदि आप एक एक्सेस कंट्रोल सिस्टम विकसित कर रहे थे, तो क्या आप इस पद्धति को लागू करने के लिए सभी इच्छुक पार्टियों को मजबूर करते हुए, एक्सेस और एक्सेस
() का एक आभासी तरीका बना सकते हैं? वह है - क्या आप प्रवेश द्वार पर एक सुरक्षा गार्ड लगा सकते हैं, प्रत्येक आने वाले व्यक्ति से पूछ रहे हैं कि क्या उसे इमारत में प्रवेश की अनुमति है?
कोई रास्ता नहीं! आपको रनटाइम सत्यापन कोड जोड़ना होगा:
public boolean ( s) { return (s.() || s.() || s.()); }
लेकिन प्रतीक्षा करें - कहीं भी वर्ग सत्यापन सीधे उपयोग नहीं किया जाता है। उदाहरण के लिए, मैंने
s instanceof उदाहरण नहीं लिखा। यहाँ क्या मामला है?
ठीक है, किसी वस्तु का "प्रकार" संक्षेप में, उसके वर्ग का कुल (जो स्पष्ट रूप से तय और अपरिवर्तित है) और उसके गुण (जो या तो निश्चित हो सकते हैं या रन टाइम में बदल सकते हैं)। यह एक और चर्चा के लिए एक विषय है, लेकिन यह मुझे लगता है कि वर्गों द्वारा गुणों की तुलना में अधिक प्रकार निर्धारित किया जाता है। यह उत्तरार्द्ध की अंतर्निहित अनम्यता के कारण है। लेकिन C ++ और Java जैसी "पारंपरिक" भाषाओं में, इस तरह के दृष्टिकोण से प्रतिनिधिमंडल के लिए सिंटैक्स समर्थन की कमी के कारण कोड का पुन: उपयोग थोड़ा अधिक कठिन हो जाएगा। (यदि यह अचानक आपको लगता है कि इसका कोई मतलब नहीं है, तो सब कुछ क्रम में है: मैं पहले से ही अपने तीसरे गिलास शराब को अंतिम चरण के रास्ते पर समाप्त कर रहा हूं। इसलिए, इस विषय को दूसरे नोट के लिए छोड़ दें।)
उसी समय, मुझे उम्मीद है कि मैं स्पष्ट रूप से मुख्य विचार व्यक्त करने में कामयाब रहा -
बहुरूपता केवल तभी समझ में आता है जब बहुरूपता वास्तव में वस्तु से संबंधित होता है ।
यदि यह विषय का व्यवहार है, तो गतिशील प्रकार की जाँच बेहतर है।संक्षेप
इसलिए, मुझे आशा है कि आपने आज की पोस्ट से उपयोगी कुछ सीखा है। मुझे खुद पर यकीन है। उदाहरण के लिए, मुझे पता चला कि Google सर्च इंजन "En और kin Skywalker" को ठीक करने के लिए वास्तव में काफी स्मार्ट है , "क्या आपका मतलब है: En और kin Skywalker?" ओह और अभिमानी लोग! ऐसा नहीं है कि कॉपीराइट उन्हीं का है।मुझे यह भी पता चला कि ब्लॉग प्रविष्टि की आदर्श लंबाई शराब के दो गिलास है। यदि आप आगे बढ़ते हैं, तो आप लगभग असंगत रूप से शेख़ी करना शुरू करते हैं। हां, और डायल करने की गति नरक में जाती है।ऑल द बेस्ट।
मूल - जब बहुरूपता विफल हो जाता है। स्टीव येजे। स्टीवे के नशे में ब्लॉग किराए पर