मैं OOP नहीं जानता

मुझे नहीं पता कि ऑब्जेक्ट-ओरिएंटेड भाषाओं में कैसे प्रोग्राम किया जाए। सीखा नहीं है। 5 साल के औद्योगिक जावा प्रोग्रामिंग के बाद, मुझे अभी भी नहीं पता है कि ऑब्जेक्ट-ओरिएंटेड शैली में एक अच्छी प्रणाली कैसे बनाई जाए। मैं अभी नहीं समझता।

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

और यहाँ कुछ चीजें हैं जो मुझे गलत समझती हैं।

मुझे नहीं पता कि OOP क्या है

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

यह आम तौर पर स्वीकार किया जाता है कि ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग 4 बुनियादी सिद्धांतों पर आधारित है (जब मैं छोटा था, उनमें से केवल 3 थे, लेकिन तब पेड़ भी बड़े थे)। ये सिद्धांत:

• मतिहीनता
• कैप्सूलीकरण
• विरासत
• बहुरूपता

नियमों का एक सेट की तरह दिखता है, है ना? तो यहाँ यह है, 95% मामलों में नियमों का पालन किया जाना चाहिए? हम्म, चलो एक करीब देखो।

मतिहीनता

अमूर्त एक शक्तिशाली प्रोग्रामिंग उपकरण है। वास्तव में जो हमें बड़ी प्रणालियों का निर्माण करने और उन पर नियंत्रण बनाए रखने की अनुमति देता है। यह संभावना नहीं है कि हम कभी भी कम से कम आज के स्तर के कार्यक्रमों के करीब आएंगे यदि हम इस तरह के साधन से लैस नहीं थे। हालाँकि, अमूर्तता OOP से कैसे संबंधित है?

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

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

कैप्सूलीकरण

एनकैप्सुलेशन का ट्रम्प कार्ड कार्यान्वयन को छिपाने में है। केवल इंटरफ़ेस क्लाइंट कोड को देखता है, और केवल उस पर भरोसा कर सकता है। यह डेवलपर्स के हाथों को मुक्त करता है जो कार्यान्वयन को बदलने का निर्णय ले सकते हैं। और यह वास्तव में अच्छा है। लेकिन सवाल यह है कि OOP का इससे क्या लेना-देना है? उपरोक्त सभी प्रतिमानों में कार्यान्वयन को छिपाना शामिल है। सी में प्रोग्रामिंग करते समय, आप हेडर फ़ाइलों को इंटरफ़ेस आवंटित करते हैं, ओबेरॉन आपको फ़ील्ड और विधियों को मॉड्यूल के लिए स्थानीय बनाने की अनुमति देता है आखिरकार, कई भाषाओं में अमूर्तता बस रूटीन के माध्यम से बनाई गई है जो कार्यान्वयन को भी बाधित करती है। इसके अलावा, ऑब्जेक्ट-ओरिएंटेड भाषाएँ स्वयं अक्सर विशेष तरीकों के माध्यम से डेटा तक पहुंच प्रदान करके एनकैप्सुलेशन नियम का उल्लंघन करती हैं - जावा में गेटर्स और सेटर, सी # में गुण, आदि। (टिप्पणियों में, यह पाया गया कि प्रोग्रामिंग भाषाओं में कुछ ऑब्जेक्ट OOP के दृष्टिकोण से ऑब्जेक्ट नहीं हैं: डेटा ट्रांसफर ऑब्जेक्ट्स डेटा ट्रांसफर के लिए पूरी तरह से जिम्मेदार हैं, और इसलिए OOP के पूर्ण-निकाय निकाय नहीं हैं, और इसलिए, उनके लिए इनकैप्सुलेशन को बचाने की आवश्यकता नहीं है। दूसरी तरफ। , वास्तुकला के लचीलेपन को बनाए रखने के लिए पहुंच के तरीकों का सबसे अच्छा उपयोग किया जाता है। यह इतना आसान नहीं है।) इसके अलावा, कुछ ऑब्जेक्ट-ओरिएंटेड भाषाएं, जैसे कि पायथन, कुछ भी छिपाने की कोशिश नहीं करती हैं, लेकिन पूरी तरह से तर्कसंगतता पर भरोसा करती हैं। azrabotchikov इस कोड का उपयोग।

विरासत

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

तो, यहाँ यह है - कि दूसरों के बीच एक प्रतिमान के रूप में पीएलओ को अलग करता है? हम्म ... यदि हां, तो हम वास्तविक कोड में शायद ही कभी इसका उपयोग क्यों कर रहे हैं? याद रखें, मैं 95% कोड के बारे में बात कर रहा था जो प्रमुख प्रतिमान के नियमों का पालन करता है? मैं मजाक नहीं कर रहा हूँ कार्यात्मक प्रोग्रामिंग में, कम से कम 95% कोड दुष्प्रभाव के बिना अपरिवर्तनीय डेटा और फ़ंक्शन का उपयोग करता है। मॉड्यूलर में, लगभग सभी कोड तार्किक रूप से मॉड्यूल में पैक किए जाते हैं। स्ट्रक्चरल प्रोग्रामिंग अनुयायियों, दीजकस्ट्रा की पूर्वधारणाओं के बाद, कार्यक्रम के सभी हिस्सों को छोटे भागों में तोड़ने की कोशिश करते हैं। इनहेरिटेंस का उपयोग बहुत कम बार किया जाता है। शायद कोड के 10% में, शायद 50% में, कुछ मामलों में (उदाहरण के लिए, जब फ्रेमवर्क कक्षाओं से विरासत में मिला) - 70% में, लेकिन अधिक नहीं। क्योंकि ज्यादातर स्थितियों में, यह आवश्यक नहीं है ।

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

बहुरूपता

बहुरूपता शायद ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग के बारे में सबसे अच्छी बात है। बहुरूपता के लिए धन्यवाद, प्रकार व्यक्ति की एक वस्तु जब आउटपुट "एडम इम्पोलिटोविच शांडोर्किन" की तरह दिखता है, और टाइप प्वाइंट का एक ऑब्जेक्ट "[84.23 12.61]" जैसा दिखता है। यह वह है जो आपको "Mat1 * Mat2" लिखने और साधारण संख्याओं के उत्पाद के समान मैट्रिसेस का उत्पाद प्राप्त करने की अनुमति देता है। इसके बिना, इनपुट स्ट्रीम से डेटा पढ़ना संभव नहीं होगा, इसके बारे में चिंता किए बिना कि वे नेटवर्क से आते हैं, फ़ाइल या मेमोरी में लाइन। जहां कहीं भी इंटरफेस हैं, वहां भी बहुरूपता निहित है।

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

(हालांकि, यह मेरी राय है। आप हमेशा असहमत हो सकते हैं।)

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

OOP किसका कूलर है?

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

जावा और सी # में ओओपी के सार को बेहतर ढंग से समझने के लिए, आइए इस उदाहरण पर जाएं कि यह प्रतिमान अन्य भाषाओं में कैसे लागू किया जाता है।

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

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

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

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

जावास्क्रिप्ट। वैचारिक रूप से स्मालटाक के समान है, हालांकि यह एक अलग वाक्यविन्यास का उपयोग करता है। इनहेरिट करने के बजाय, यह प्रोटोटाइप का उपयोग करता है: यदि वांछित संपत्ति या कॉल की गई विधि ऑब्जेक्ट में ही नहीं है, तो प्रोटोटाइप ऑब्जेक्ट (सभी जावास्क्रिप्ट ऑब्जेक्ट्स का प्रोटोटाइप संपत्ति) के लिए अनुरोध पारित किया जाता है। एक दिलचस्प तथ्य यह है कि प्रोटोटाइप विधियों में से किसी एक को प्रतिस्थापित करके कक्षा के सभी वस्तुओं के व्यवहार को बदला जा सकता है (यह बहुत अच्छा लगता है, उदाहरण के लिए, एक स्ट्रिंग कक्षा के लिए `.toBASE64` विधि) को जोड़ना।

अजगर। सामान्य तौर पर, वह मुख्यधारा की भाषाओं के रूप में एक ही अवधारणा का पालन करता है, लेकिन जावास्क्रिप्ट या स्मॉलटॉक में भी किसी अन्य ऑब्जेक्ट के लिए विशेषता खोज के हस्तांतरण का समर्थन करता है।

हास्केल। हास्केल के पास कोई राज्य नहीं है, और इसलिए सामान्य अर्थों में कोई वस्तु नहीं है। फिर भी, वहाँ अभी भी एक प्रकार का OOP है: डेटा प्रकार (प्रकार) एक या अधिक प्रकार की कक्षाओं के हो सकते हैं। उदाहरण के लिए, हास्केल में लगभग सभी प्रकार इक वर्ग (2 वस्तुओं की तुलना करने के लिए जिम्मेदार) में हैं, और सभी संख्याएँ अतिरिक्त रूप से (संख्याओं में संचालन) और ऑर्ड (संचालन <, <=>, =>) हैं। मासिक धर्म की भाषाओं में, वर्ग प्रकार (डेटा) के अनुरूप होते हैं, और प्रकार इंटरफेस के अनुरूप होते हैं।

स्टेटफुल या स्टेटलेस?

लेकिन ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग के अधिक सामान्य सिस्टम पर वापस। जो मैं कभी नहीं समझ सकता था वह आंतरिक राज्य के साथ वस्तुओं का संबंध था। OOP का अध्ययन करने से पहले, सब कुछ सरल और पारदर्शी था: ऐसी संरचनाएं हैं जो कई संबंधित डेटा संग्रहीत करती हैं, प्रक्रियाएं (कार्य) हैं जो उन्हें संसाधित करती हैं। चलना (कुत्ता), वापस लेना (खाता, राशि)। फिर ऑब्जेक्ट्स आए, और यह भी कुछ भी नहीं था (हालांकि कार्यक्रमों को पढ़ना बहुत मुश्किल हो गया - मेरा कुत्ता चला गया [किसने?], और खाता पैसे निकाल रहा था [कहां से?])। तब मुझे डेटा छिपाने के बारे में पता चला। मैं अभी भी कुत्ते को चला सकता था, लेकिन मैं उसके भोजन की संरचना नहीं देख सकता था। भोजन ने कोई कार्रवाई नहीं की (आप शायद लिख सकते हैं कि भोजन खाना (कुत्ता) है, लेकिन मैं अभी भी अपने कुत्ते को खाना खाने के लिए पसंद करता हूं, और इसके विपरीत नहीं)। भोजन केवल डेटा है, और मुझे (और मेरे कुत्ते को) बस उन्हें एक्सेस करने की आवश्यकता है। सब कुछ सरल है । लेकिन पहले से ही 90 के दशक की पुरानी जींस में, प्रतिमान के ढांचे में फिट होना असंभव था।

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

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

मुझे अभी भी नहीं पता है कि किसी वस्तु को स्टेटलेस, स्टेटफुल कब बनाया जाना चाहिए, और जब सिर्फ डेटा कंटेनर। यह कभी-कभी स्पष्ट होता है, लेकिन अधिक बार नहीं।

टाइपिंग: स्थिर या गतिशील?

एक और बात जो मैं C # और जावा जैसी भाषाओं के साथ तय नहीं कर सकता, वह यह है कि वे सांख्यिकीय या गतिशील रूप से टाइप की जाती हैं। संभवतः अधिकांश लोग यह कहते हैं, “क्या बकवास है! बेशक स्टैटिकली टाइप्ड! संकलन समय पर प्रकारों की जाँच की जाती है! ” लेकिन क्या यह वास्तव में इतना आसान है? क्या यह सच है कि एक प्रोग्रामर, एक विधि के मापदंडों में टाइप X को निर्धारित करता है, यह सुनिश्चित किया जा सकता है कि टाइप X की वस्तुओं को हमेशा इसे स्थानांतरित किया जाएगा? सच - यह नहीं हो सकता, क्योंकि आप टाइप X के एक पैरामीटर को पास कर सकते हैं या उसके वंशज को X का तरीका बता सकते हैं। यह प्रतीत होता है, तो क्या? दसवीं कक्षा के वारिसों के पास अभी भी एक्स के तरीकों के तरीके होंगे, लेकिन काम के तर्क पूरी तरह से अलग हो सकते हैं। सबसे आम मामला यह है कि जब बच्चा वर्ग एक्स के अलावा अन्य जरूरतों के लिए अनुकूलित होता है, और हमारी पद्धति उस अनुकूलन पर भरोसा कर सकती है (यदि यह परिदृश्य आपके लिए अवास्तविक लगता है, तो प्लग-इन कुछ विकसित ओपन सोर्स लाइब्रेरी में लिखने का प्रयास करें - या आप कुछ खर्च करेंगे सप्ताह पुस्तकालय के वास्तुकला और एल्गोरिदम का विश्लेषण करने के लिए, या आप बस उचित हस्ताक्षर के साथ यादृच्छिक तरीके से कॉल करेंगे)। नतीजतन, कार्यक्रम काम करता है, लेकिन गति परिमाण के एक क्रम से गिरती है। हालांकि संकलक के दृष्टिकोण से, सब कुछ सही है। यह महत्वपूर्ण है कि स्काला, जिसे जावा का उत्तराधिकारी कहा जाता है, कई स्थानों पर डिफ़ॉल्ट रूप से केवल निर्दिष्ट प्रकार के तर्क को पारित करने की अनुमति देता है, हालांकि इस व्यवहार को बदला जा सकता है।

एक अन्य समस्या अशक्त मूल्य है, जिसे जावा में लगभग किसी भी वस्तु के स्थान पर और C # में किसी भी अशक्त वस्तु के स्थान पर पारित किया जा सकता है। अशक्त एक ही समय में सभी प्रकारों से संबंधित है, और एक ही समय में किसी से संबंधित नहीं है। null के पास कोई फ़ील्ड या विधियाँ नहीं हैं, इसलिए इसे करने के लिए कोई भी कॉल (null के लिए जाँच के अलावा) एक त्रुटि की ओर ले जाती है। ऐसा लगता है कि हर किसी के लिए इसका उपयोग किया जाता है, लेकिन तुलना के लिए, हास्केल (और स्काला) को विशेष प्रकार (शायद हास्केल, ऑप्शन इन स्काला) का उपयोग करने के लिए मजबूर किया जाता है ताकि वे अन्य भाषाओं में अशक्त लौट सकें। नतीजतन, वे अक्सर हास्केल के बारे में कहते हैं "इस पर एक कार्यक्रम संकलित करना मुश्किल है, लेकिन अगर यह अभी भी काम करता है, तो यह संभवतः सही ढंग से काम करता है।"

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

क्या अंतर है, ऐसे टाइपिंग का नाम क्या है, यदि सभी नियम अभी भी ज्ञात हैं? , . , : , ? Haskell, Lisp. - - . , — ( , Java C# ), , — .

...

, . , . ( , ) ( , ), — , … , . , , . , . , (, , ?).

, , , . , , .

, . Python C++, , . Java C# StringUtils. -- ad hoc ( ). . ( ) . 150 , — , , .

. — . - . HTTP URL, HttpConnection, Request… , . , . , — . .

, — . , , . , -, - . , .