👩🏾‍🤝‍👩🏼 👏🏼 👈 एक "फ्लैट" ऑब्जेक्ट मॉडल या "सिंटैक्टिक शुगर" के लायक क्या है 🏟️ 🕘 🐁

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

"ऑब्जेक्ट" प्रकार के टर्मिनल चिन्ह (शब्द) को परिभाषित किया गया है। अभिव्यक्ति "प्रकार का ऑब्जेक्ट" टर्मिनल प्रतीक "का मतलब केवल यह है कि इस शब्द के लिए विशेष शाब्दिक निर्माण उपलब्ध हैं, भाषा स्तर पर व्यक्त किए गए हैं, हम उनमें से केवल दो पर विचार करेंगे - असाइनमेंट और विधि मंगलाचरण।
टर्मिनल सिंबल "ऑब्जेक्ट" का मान कुछ इकाई का संदर्भ है, जिसका विवरण निम्नलिखित पैराग्राफ में दिया गया है।
ऑपरेशन "=" परिभाषित किया गया है - संदर्भ द्वारा असाइनमेंट। एक टर्मिनल प्रतीक (टर्म 1) को दूसरे (टर्म 2) को सौंपने का अर्थ है टर्म 1 से टर्म 2 तक एक ही इकाई के लिंक की नकल करना।
एक इकाई, जो एक शब्द का अर्थ है, कई विधियां हैं। विधि को कहा जाता है और लेक्सिकल कंस्ट्रक्शन का उपयोग करके इसे मापदंडों को पारित किया जाता है "।" और "()", जो, उदाहरण के लिए, term.method(param1, param2) ।
एक इकाई में (अन्य) संस्थाओं का एक अव्यवस्थित सेट होता है जो इसकी स्थिति को बनाते हैं।
कम से कम एक इकाई है जो आपको किसी दिए गए प्रारंभिक राज्य के साथ विधियों के एक सेट के साथ अन्य संस्थाओं को बनाने की अनुमति देती है।
कम से कम एक इकाई है जो आपको राज्य और एक इकाई से दूसरे में तरीकों का एक सेट कॉपी करने की अनुमति देती है।
प्रतिलिपि बनाने के दौरान तरीके और राज्य के तत्व (पृष्ठ 7) को प्रतिस्थापित नहीं किया जाता है यदि इकाई में उसी नाम के साथ समान हैं जिसमें प्रतिलिपि बनाई गई है।

ऑब्जेक्ट मॉडल, जिसका विवरण 1-8 पैराग्राफ में दिया गया है, हम "फ्लैट ऑब्जेक्ट मॉडल" नाम देते हैं।
आम तौर पर, ऊपर-परिभाषित मॉडल को बहुत सरल किया जाता है, उदाहरण के लिए, आधार प्रकार से डिफ़ॉल्ट रूप से विरासत पर भी विचार नहीं किया जाता है, और प्रत्येक वस्तु में समर्थित एक विरासत तंत्र भी नहीं है - इसके लिए यह माना जाता है कि कोई पूर्वनिर्धारित इकाई है जो अन्य संस्थाओं के साथ इस क्रिया को कर सकती है।
एक वस्तु मॉडल एक भाषा को कॉल करने के लिए पर्याप्त है जो इसे ऑब्जेक्ट-ओरिएंटेड का समर्थन करता है। ओओपी के लक्षण वर्णन में वर्णित शब्द क्रमशः 4, 5, 6, और 7, 8 में पैराग्राफ, इनहेरिटेंस, और बहुरूपता को ध्यान में रखते हैं। शब्द " हैक " का अर्थ भाषा का शाब्दिक निर्माण होगा, जो आपको पैराग्राफ 1- में वर्णित नहीं तरीके से वस्तुओं पर कार्रवाई करने की अनुमति देता है। 8। मैं इस तथ्य पर तुरंत ध्यान आकर्षित करना चाहता हूं कि ऐसी भाषा के साधन जो इस भाषा के ऑब्जेक्ट मॉडल से स्वतंत्र हैं और सामान्य मामलों में अन्य उद्देश्यों के लिए जो वस्तुओं में हेरफेर करने से संबंधित नहीं हैं, को हैक नहीं माना जाएगा । उदाहरण के लिए, यदि हम C ++ कंपाइलर के शीर्ष पर निर्मित ऑब्जेक्टिव-सी कंपाइलर के कार्यान्वयन पर विचार करते हैं, तो मुख्य ऑब्जेक्ट-सी ऑब्जेक्ट मॉडल में हैक पर विचार करते समय सी ++ ऑब्जेक्ट मॉडल को ध्यान में नहीं रखा जाता है। आइए इस बात का एक संक्षिप्त विवरण दें कि कुछ भाषाएं, जिनमें वे भी शामिल हैं जो इतने लंबे समय पहले नहीं दिखाई दी थीं, हैक के साथ आगे बढ़ गईं थीं और ये हैक कितनी सफल थीं।

कोई हैक नहीं

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

 Object subclass: #Person instanceVariableNames: 'Family Name ' ...

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

आवश्यकतानुसार खाकी

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

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

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

एक बहुत ही दिलचस्प बिंदु यह है कि एक भाषा के ऑब्जेक्ट मॉडल की विवश सीमाएं दूसरे में कैसे चली गईं। PHP में एक ऑब्जेक्ट मॉडल होता है जो जावा मॉडल के समान ही वाक्यात्मक होता है। सब कुछ ठीक होगा, लेकिन उनके बीच एक छोटा सा अंतर है, जावा एक स्टेटिकली टाइप की गई भाषा है, और पीएचपी गतिशील है। PHP में ऐसी कोई चीज है जो फ़ंक्शन को पास करने के लिए तर्क के प्रकार को निर्दिष्ट करती है। लेकिन इस तथ्य के बावजूद कि जावा और पीएचपी में यह समान रूप से समान दिखता है, क्योंकि इन भाषाओं में विभिन्न प्रकार के टाइपिंग हैं, इस प्रकार के तर्क का संकेत पूरी तरह से अलग भूमिका निभाता है। जावा में, यह संकलक को बताता है कि संकलन करते समय तर्क के साथ क्या करना है, और PHP में यह परावर्तन का उपयोग करता है, अर्थात, एक रनटाइम जाँच करता है कि तर्क में ऐसा सुपरटेप है।

नीट हैक

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

शक्तिशाली हैक

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

 class SomeContext { public int number { private set; get; } public SomeContext(int initialNumber) { number = initialNumber; } public Addition addition { get { return new Addition(this); } } public class Addition { //      Addition public Addition(SomeContext context) { _contest = context; } public void add(int number) { _contest.number += number; //   private-,      } private SomeContext _contest; } } class Program { static void Main(string[] args) { SomeContext context = new SomeContext(9); SomeContext.Addition addToContext = context.addition; //      addToContext.add(6); Console.WriteLine(context.number); } }

बेशक, एक प्रतिनिधि का उपयोग करना, यह सरल होगा:

 class SomeContext { public int number { private set; get; } public SomeContext(int initialNumber) { number = initialNumber; } public Addition addition { get { return delegate(int what) { number += what; }; } } public delegate void Addition(int number); } class Program { static void Main(string[] args) { SomeContext context = new SomeContext(9); SomeContext.Addition addToContext = context.addition; // external delegate logic addToContext(6); Console.WriteLine(context.number); } }

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

हैक पर हैक

एक भी वस्तु मॉडल पर हैक्स उपयोगी और सुविधाजनक हो सकता है। लेकिन कुछ मामलों में उनमें से कई हैं और धारणा है कि वे अब प्रबंधनीय नहीं हैं। निश्चित रूप से सबसे ज्यादा हैक की गई भाषाओं में से एक है। ऐसा लगता है कि रचनाकार इस भाषा में जो कुछ भी संभव था, सब कुछ अलग करना चाहते थे, और इसके अलावा उन्होंने एक ही चीज़ को एक से अधिक बार चमकाने की कोशिश की। विशेष रूप से, इस वजह से, उदाहरण के लिए, एक ही कॉलबैक निर्माण को परिभाषित करने के चार अलग-अलग तरीके हैं । कुछ, ऐसा लगता है, ओवरकिल है ... लेकिन ये सभी निर्माण भाषा के सिंटैक्स का उपयोग करते हैं और इसलिए इसे अधिभारित करते हैं। Microsoft के लोगों ने C # भाषा ऑब्जेक्ट मॉडल को हैक करने का निर्णय लेने में कितनी मुश्किलें हैं, इसके बारे में और भी कई विषमताएँ बताई हैं:

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

बेशक, ये सभी हैक महत्वपूर्ण नहीं हैं, कम से कम C # में हैक किए गए एक सबसेट के रूप में कम या ज्यादा सामान्य ऑब्जेक्ट मॉडल है, और आप सामान्य से चिपके रह सकते हैं।

निष्कर्ष

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