"शुद्ध OO भाषा" शब्द की औपचारिक परिभाषा?


13

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

डॉ। एलन के द्वारा पत्राचार के साथ शुरू करना उचित होगा , जिन्होंने शब्द को गढ़ा है (कोशिकाओं या अन्य जीवित वस्तुओं के लिए जैविक सादृश्य में प्रेरणा को नोट करें)।

कार्य के लिए निम्नलिखित तरीके हैं:

  1. प्रोग्रामिंग भाषाओं को सूचीबद्ध करके एक तुलनात्मक विश्लेषण दें, जो (या ऐसा करने में विफल) प्रदर्शन को परिभाषित करने के लिए कुछ गुण अद्वितीय और पर्याप्त हो सकते हैं (हालांकि स्मॉलटाक, स्काला, जावा , और इतने पर - संभव उदाहरण हैं लेकिन IMO इस तरह से लगता है कि वास्तव में पूर्ण नहीं है और न ही उपयोगी )
  2. एक औपचारिक परिभाषा दें (या इसके करीब, जैसे अधिक अकादमिक या गणितीय शैली में)।
  3. एक दार्शनिक परिभाषा दें जो पूरी तरह से ठोस भाषा या एक प्राथमिक प्रोग्रामिंग अनुभव के शब्दार्थ संदर्भ पर निर्भर करेगा (समुदाय द्वारा सफल स्पष्टीकरण का कुछ मौका होना चाहिए)।

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

इसके किसी भी संभावित सुधार की सराहना करेंगे। जैसा कि आप देख सकते हैं कि मैंने केवल "ऑब्जेक्ट" शब्द पर निर्भर परिभाषा बनाई है (अक्सर वस्तुओं के वर्ग के रूप में पूरी तरह से संदर्भित)।

[संपादित करें]

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

एनबी

कैसे जवाब दें :

  • यह मदद करता है यदि आप एक पुस्तक या एक संदर्भ निर्दिष्ट करते हैं जो शब्दावली और अवधारणाओं की आपकी समझ का समर्थन करता है / व्याख्या करता है (आमतौर पर एक अच्छी परिभाषा कवर करती है या प्राथमिक को छोड़कर सभी मिश्रित अवधारणाओं को संदर्भित करती है)।
  • यदि संभव हो तो अपने उत्तर / परिभाषा की एक इंडेंट श्रेणी का संकेत दें यदि यह अन्यथा स्पष्ट नहीं है (ऊपर देखें: 1 - भाषा उदाहरण के अनुसार, 2 - गणितीय तर्क, 3 - तकनीकी विवरण और प्रोग्रामिंग दर्शन)
  • वर्गीकरण महत्वपूर्ण है (और इसलिए भी क्योंकि शुद्ध-ऊ शब्द को OO शब्द में शामिल किया गया है), अन्य अच्छी तरह से ज्ञात कार्यप्रणाली से OO प्रतिमान के तत्वों को अनमिक्स करने का प्रयास करते हुए (और किसी भी तरह से भ्रमित / ओवरलैप नहीं करते हैं, उदाहरण के लिए, आमतौर पर मॉड्यूलर प्रोग्रामिंग के तत्वों को कवर किया जा सकता है) / OO प्रोग्रामिंग के साथ सन्निहित): OOP को अलग करने का प्रयास करें (जिसमें शामिल है या हो रहा है) कार्यात्मक प्रोग्रामिंग, तार्किक प्रोग्रामिंग (विशेष रूप से विशेष रूप से विशिष्ट), Abstarct डेटा प्रकार (ADT), मॉड्यूलर, मेटाप्रोग्रामिंग (जेनरिक और LISP के मैक्रोफेन्सर-टाइम), अनुबंध (उदाहरण के लिए एफिल), पहलू-उन्मुख (एओ), (डिक्स्ट्रक्टिव और कार्यात्मक वर्गीकरण के बीच अंतर के साथ-साथ दिज्क्स्ट्रा की संरचित की ऐतिहासिक परिभाषाएं स्पष्ट हैं)

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

तो, हां, केवल परिभाषा ही नहीं, बल्कि "अच्छी" परिभाषा देना मुश्किल है। लेकिन मैं आपके अनुभव और प्रत्यक्ष भागीदारी के कारण यहां यह पूछने में सकारात्मक हूं।


2
खैर, आपने खुद को पायथन के लिए जवाब दिया है। "नहीं"।
Psr

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

5
@JoachimSauer: उन्होंने स्क्वीक मेलिंग सूची के एक अन्य मेल में कहा कि "द बिग आइडिया मैसेजिंग" है और उन्हें इस बात का पछतावा है कि उन्होंने इसे कभी "ऑब्जेक्ट-ओरिएंटेड" कहा और इसे "मैसेज-ओरिएंटेड" कहा जाना चाहिए। उदाहरण के लिए, एर्लैंग एक पूरी तरह से ऑब्जेक्ट-ओरिएंटेड भाषा है, जो सभी "ऑब्जेक्ट्स", "मेथड्स", "इनहेरिटेंस", "क्लासेस", "प्रोटोटाइप" या कुछ इस तरह की अवधारणा के बिना डॉ। Kay के सभी मानदंडों को पूरा करती है। ।
जॉर्ग डब्ल्यू मित्तग सेप

1
यह एक अच्छा चित्रण हो सकता है कि वाक्य रचना एक OO भाषा को परिभाषित करने के लिए पर्याप्त नहीं है। यदि कोई यह दिखा सकता है कि OOP (जैसे कि एक उपकरण के रूप में) केवल शब्दार्थ (स्वतंत्र) है, तो यह (पूरी तरह से) मेरे प्रश्न को बदल देता है!
योहान याकिमोविच

2
@YauhenYakimovich यह OOP पर चर्चा करने में मूल समस्याओं में से एक है, हर किसी और उसके कुत्ते का अपना विचार है कि यह क्या है। इसके विपरीत, संरचित प्रोग्रामिंग और कार्यात्मक प्रोग्रामिंग प्रत्येक को बहुत सरलता से परिभाषित किया जा सकता है। इससे मुझे सवाल उठता है कि क्या ओओ में विज्ञान के बजाय धर्म के समान गुण हैं।
रिकी क्लार्कसन

जवाबों:


19

OO, एलन Kay के अनुसार संदेश पारित होने के बारे में है, और यह बात है। आप देखेंगे कि बहुरूपता और एनकैप्सुलेशन जैसे गुण वास्तव में संदेश पारित होने से प्राप्त होते हैं।

अब वह रुख वास्तव में बहुत चरम पर है, क्योंकि इसका मूल रूप से मतलब है कि केवल स्मॉलटाक और भाषाएं एक जैसे होंगे।

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

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

फिर, IMHO भाषा की शुद्धता एक ताकत से अधिक कमजोरी है। OO चांदी की गोली नहीं है। एक भी प्रतिमान नहीं है।


2
+1 के लिए "OO एक चांदी की गोली नहीं है"।
एंड्रेस एफ।

1
@AndresF। ध्यान दें कि ओओपी के व्यावहारिक मूल्य और साथ ही प्रोग्रामिंग से संबंधित अन्य सैद्धांतिक ज्ञान वास्तव में एक प्रश्न का हिस्सा नहीं है। यह बहुत स्पष्ट है कि कोई बहुत ही सफल तरीके से कोड लिख सकता है w / o प्रोग्रामिंग तकनीकों या सिद्धांतों (और आसपास के अन्य) की किसी भी गहरी समझ। न तो OO भाषाओं के आवेदन गुणों पर चर्चा की जाती है, आदि
Yauhen Yakimovich

@YauhenYakimovich ओह, मुझे पता है। अगर यह ऑफ-टॉपिक होता तो मैं जवाब नहीं देता। फिर भी, मुझे इस बात से सहमति है कि मैं इससे सहमत हूं।
एंड्रेस एफ।

@AndresF। यकीन है कि :-) "OO एक चांदी की गोली नहीं है" सबसे अधिक सच है और साथ ही साथ हमारे पास एक परिपूर्ण प्रोग्रामिंग भाषा की कमी है। लेकिन क्या वास्तव में OOP चांदी की गोली नहीं बनाता है? एक अच्छी बग रिपोर्ट के रूप में मुझे लगता है कि विस्तृत और सटीक शब्दावली इसका जवाब देने का तरीका है। मैंने इसके साथ काम करने में इतना समय लगाया है कि मैं इसे अगले स्तर पर लाने के लिए उत्सुक हूं। क्या OOP सिर्फ विचारों की एक प्रति है जो एक प्रोग्रामिंग बुक से दूसरे में पेस्ट की जाती है?
योहान याकिमोविच

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

6

मैं इसे एक ऐसी भाषा के रूप में परिभाषित करता हूं जो OOP कंस्ट्रक्शन का उपयोग करता है और कुछ नहीं (उसी तरह से जो शुद्ध FP भाषा अपरिवर्तनीय डेटा के साथ शुद्ध कार्यों का उपयोग करता है और कुछ नहीं)।

विशेष रूप से:

  • आपके द्वारा संचालित प्रत्येक इकाई एक प्रथम श्रेणी की वस्तु है - अर्थात कोई आदिम नहीं, कोई संकेत नहीं, कोई सरणियाँ आदि।
  • केवल एक चीज जो आप किसी वस्तु के साथ कर सकते हैं, उस पर कॉल एक (संभावित बहुरूपी) विधि है (= संदेश भेजना)। कोई अन्य ऑपरेशन मौजूद नहीं है।
  • सभी डेटा एनकैप्सुलेटेड हैं - अर्थात कोई सार्वजनिक फ़ील्ड एक्सेस नहीं, आपको किसी ऑब्जेक्ट पर विधियों के माध्यम से जाना चाहिए
  • यदि आपके पास प्रथम श्रेणी के कार्य हैं, तो उन्हें भी ऑब्जेक्ट होना चाहिए - इसलिए आपको कुछ ऐसा करने की आवश्यकता होगीfunctionObject.call(param1,param2)
  • कोई वैश्विक चर नहीं - यदि आप ऐसा कुछ चाहते हैं, तो आपको वर्तमान वैश्विक वातावरण का प्रतिनिधित्व करने के लिए किसी वस्तु का उपयोग करने की आवश्यकता होगी, जैसे environment.getValue("myThing")कि चर को किसी वर्ग वस्तु में रखा जाए।

ध्यान दें कि यह अभी भी काफी कुछ विकल्प छोड़ता है:

  • क्लास-आधारित बनाम प्रोटोटाइप-आधारित ऑब्जेक्ट मॉडल
  • इनहेरिटेंस कैसे लागू किया जाता है (यदि बिल्कुल)
  • चाहे आपके पास तरीकों पर एकल या एकाधिक प्रेषण हो
  • चाहे आपकी वस्तुएं सांख्यिकीय रूप से या गतिशील रूप से टाइप की गई हों
  • विधि कॉल के लिए उपयोग किया जाने वाला सटीक सिंटैक्स (जैसे आप गेटर्स / सेटर आदि के लिए कुछ सिंटैक्टिक शुगर हो सकता है)।

1
ये अच्छी परिभाषाएँ हैं, लेकिन मात्र वाक्यविन्यास के साथ वस्तु वास्तविकता को भ्रमित नहीं करते हैं। सिर्फ इसलिए कि कार्यों और वैश्विक चर का एक अनुकूल वाक्यविन्यास है, वे वास्तव में दिल की वस्तु हो सकते हैं।
ddyer

@ddyer - यह सही है अगर यह वास्तव में सिर्फ वाक्यविन्यास है, लेकिन मुझे लगता है कि यदि वाक्यविन्यास भी अलग-अलग शब्दार्थों का परिचय देता है तो यह "शुद्धता" को तोड़ सकता है। उदाहरण के लिए, wrt ग्लोबल वैरिएबल एक वैरिएबल वैरिएबल globalVariableNameको एक्सेस करने के लिए किसी ऑब्जेक्ट पर मेथड कॉल से एक अलग सिमेंटिक है, जो शुद्ध OOP में गैर-लोकल वैल्यू तक पहुंचने का एकमात्र तरीका होगा।
मिकेरा

मुझे लगता है कि "सब कुछ" को योग्य होने की आवश्यकता है। यदि किसी भाषा में कोई चिंतनशील क्षमता नहीं है (उदाहरण के लिए, यह किसी अमूर्त नाम से किसी ऑब्जेक्ट की विधि का संदर्भ नहीं दे सकता है, या इसे किसी चर में संग्रहीत कर सकता है), तो क्या तरीकों को भी ऑब्जेक्ट होने की आवश्यकता है? संदर्भ वस्तुएं हैं? क्या संदर्भ और वस्तुएं भी अलग-अलग चीजें हैं?
जोकिम सॉर

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

"क्लास-आधारित बनाम प्रोटोटाइप-आधारित ऑब्जेक्ट मॉडल": लेकिन मैं कहूंगा कि दोनों मामलों में आपके पास कुछ प्रकार का वर्गीकरण है, अर्थात आप एक समान संरचना और व्यवहार के साथ वस्तुओं का समूह बनाते हैं।
जियोर्जियो

4

तथाकथित ओओ भाषाओं के बारे में चर्चा हमेशा दिमाग से धोया गया है। अर्थात:

"किसी ने मुझे बताया है कि भाषा X OO है, इसलिए इसलिए भाषा X OO के बराबर है, फिर भाषा X की सुविधाओं का अभाव करने वाली प्रत्येक भाषा संभवतः OO नहीं हो सकती है। और क्योंकि मैं अपना कोड भाषा X में लिख रहा हूं, तो मैं जो कुछ भी कर रहा हूं वह OO है। "

ऑब्जेक्ट-ओरिएंटेड डिज़ाइन शब्द 3 चीजों को उबालता है:

  1. स्वायत्त वस्तुओं के साथ मॉड्यूलर डिजाइन जो कार्यक्रम के बाकी हिस्सों के बारे में अनावश्यक जानकारी नहीं जानते हैं, उर्फ संभव के रूप में ढीले युग्मन के रूप में।
  2. जानबूझकर और आकस्मिक दोनों बाहरी पहुंच को रोकने के लिए वस्तुओं के अंदर डेटा का इनकैप्सुलेशन।
  3. वस्तुओं के बीच स्पष्ट रूप से निर्दिष्ट निर्भरता। ढीली युग्मन प्राप्त करने के लिए, लेकिन कार्यक्रम को बनाए रखने और विस्तार करने के लिए आसान बनाने के लिए भी।

1) शुद्ध प्रोग्राम डिज़ाइन है, इसे किसी भी प्रोग्रामिंग भाषा में प्राप्त किया जा सकता है। हालाँकि, कुछ भाषाओं में सहायक सुविधाएँ होती हैं जैसे कक्षा / संरचना और निजी खोजशब्द।

2) मुख्य रूप से प्रोग्राम डिज़ाइन है, हालांकि पूरी तरह से भाषा समर्थन के बिना हासिल नहीं किया जा सकता है, क्योंकि आपको आकस्मिक उपयोग से बचाने के लिए निजी / स्थिर जैसे भाषा तंत्र की आवश्यकता होती है।

3) मुख्य रूप से प्रोग्राम डिज़ाइन है। आम तौर पर तीन अलग-अलग निर्भरताएं होती हैं: "ऑब्जेक्ट एक्स में ऑब्जेक्ट वाई", "ऑब्जेक्ट एक्स एक तरह का वाई" और "ऑब्जेक्ट एक्स ऑब्जेक्ट वाई के साथ इंटरैक्ट करता है"। इन निर्भरताओं के साथ मदद करने के लिए बहुत सारी भाषा सुविधाएँ हैं: विरासत / बहुरूपता, अमूर्त आधार वर्ग और इतने पर।

अब, यदि हम ऊपर देखें तो हम देख सकते हैं कि आपको OO प्रोग्राम लिखने के लिए किसी भी भाषा की विशेषताओं की आवश्यकता है। सुविधाएँ अभी इसे बहुत आसान बनाती हैं।

उपरोक्त लक्ष्यों को कुछ मैला पिछड़ा-तर्क का उपयोग करके प्राप्त नहीं किया जा सकता है: सिर्फ इसलिए कि आप क्लास कीवर्ड का उपयोग करते हैं, आपके प्रोग्राम को स्वचालित रूप से एक मॉड्यूलर डिज़ाइन नहीं मिलता है। सिर्फ इसलिए कि आप विरासत का उपयोग करते हैं, इसका मतलब यह नहीं है कि आपकी वस्तु निर्भरता समझ में आती है। OO सुविधाओं वाली भाषा अभी भी class TheWholeBloodyProgram"एनिमल इनहेरिट्स कैट" जैसी चीजों की अनुमति देती है ।

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

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

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


क्या आप स्पष्ट कर सकते हैं कि आपकी परिभाषा किस प्रकार से भिन्न है, उदाहरण के लिए अमूर्त डेटा प्रकार के साथ प्रोग्रामिंग? मुझे लगता है कि आप सही रास्ते पर हैं, लेकिन मैं अभी तक ट्रेन नहीं देख सकता!
Jörg W Mittag

@ JörgWMittag यह जरूरी नहीं है कि पारंपरिक, ADT: s को ऑब्जेक्ट-ओरिएंटेड डिज़ाइन का उपयोग करते हुए लिखा जा सकता है, जिसमें उचित एनकैप्सुलेशन, सेटर / गेटर्स, इनहेरिट करने के तरीके आदि शामिल हैं। लेकिन इन्हें OJ डिज़ाइन के संबंध में भी लिखा जा सकता है। ->

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

@ लुंडिन: JörgWMittag द्वारा एक अन्य उत्तर के लिए एक टिप्पणी के रूप में पोस्ट किए गए पेपर में एडीटी और ओओ के बीच एक (आईएमओ) दिलचस्प तुलना है।
जियोर्जियो

मुझे कुछ यूएमएल पुस्तकों से याद है (शायद) एक अतिरिक्त बिंदु 0. सार (बहुपत्नीवाद, विरासत, एकत्रीकरण, आदि के रूप में अंतर-वस्तु संबंधों के लिए आवश्यक अमूर्त सूत्रीकरण के महत्व पर जोर देना)।
योहान याकिमोविच

2

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

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

  • एक वस्तु कुछ राज्य रखती है और उस राज्य पर कुछ कार्य प्रदान करती है।

इस मामले में, भी intयोग्य है। आखिरकार, जब आप C ++ में टेम्प्लेट कोड लिखते हैं, जो या तो आदिम या ऑब्जेक्ट को स्वीकार कर सकता है, तो यह तर्क करना मुश्किल हो जाता है कि किसी भी पर्याप्त तरीके से प्राइमेटिव अलग हैं। Vector v1, v2; v1 + v2;इसके बजाय सार्थक रूप से कुछ भी अलग नहीं है int v1, v2; v1 + v2;(भद्दे आरंभीकरण शब्दार्थ को छोड़कर, किसी को मानना ​​चाहिए)। इसके अलावा, यह लैम्ब्डा और ऐसी चीजों को ऑब्जेक्ट होने की अनुमति देता है, जैसा कि वे राज्य को पकड़ते हैं- उनकी कैद- और उस राज्य पर एक फ़ंक्शन की पेशकश करते हैं, जिसे लैम्ब्डा कहते हैं।

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


2
मुझे इस तरह के भेद की कोई आवश्यकता नहीं है। लेकिन दूसरी बात, उनकी एक ही पहचान है कि किसी अन्य वस्तु का पता / संदर्भ तुलना है। तथ्य यह है कि आप एक ही राज्य के साथ दो वस्तुओं को अलग नहीं कर सकते हैं, पते की तुलना के अलावा, नए से दूर है और सभी वस्तुओं पर लागू होता है।
डेडएमजी सेप

5
-1। एक बेकार और अनावश्यक शेख़ी के साथ शुरू होता है शीघ्र ही विज्ञापन hominem हमले और केवल एक चीज भी दूर से तथ्यात्मक (की परिभाषा पर स्विच करता है OOP ) गलत है। कृपया एक सार डेटा प्रकार और एक वस्तु के बीच अंतर के लिए विलियम आर। कुक द्वारा परिकल्पित डेटा एब्सट्रैक्शन पर पढ़ें ।
जोर्ग डब्ल्यू मित्तग

1
"मुझे इस तरह के भेद की कोई आवश्यकता नहीं है।": लेकिन यह अंतर वस्तुओं की आमतौर पर स्वीकृत विशेषताओं में से है। बेशक, आप किसी वस्तु की अपनी धारणा विकसित कर सकते हैं जो कि आमतौर पर स्वीकार किए जाने वाले से अलग है। आप इसे करने के लिए पूरी तरह से स्वतंत्र हैं।
जियोर्जियो

2
@ Jörg मैं अलग करने के लिए भीख माँगती हूँ। मैं इस पोस्ट से पूरी तरह सहमत नहीं हूं लेकिन पहले पैराग्राफ में "बेकार" या "शेख़ी" को चेतावनी देना असंगत है। OOP के लिए परिभाषा पर कोई सार्वभौमिक सहमति नहीं है। यह एक सरल और व्यापक रूप से स्वीकृत तथ्य है। बाकी पोस्ट OOP की एक परिभाषा है। निश्चित रूप से सबसे व्यापक रूप से इस्तेमाल नहीं किया गया है, न ही मैं जो दे सकता हूं, लेकिन, जैसा कि डेडएमजी ने कहा, वास्तव में काफी उपयोगी है।
कोनराड रुडोल्फ

2
@KonradRudolph: वह पैराग्राफ बहुत अलग है जब मैंने अपनी टिप्पणी लिखी थी, जिसमें प्रोग्रामर की तुलना जो कि नस्लवादियों के लिए वाक्यविन्यास की परवाह करते थे, यहां तक ​​कि नाम से इस साइट के एक विशिष्ट उपयोगकर्ता का उल्लेख करना भी शामिल था।
जोर्ग डब्ल्यू मित्तग

0

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

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

कौन सी भाषाएं शुद्ध हैं? एक मात्र उम्मीदवार जो मन में आता है वह है छोटेटॉक।


क्या रूबी शुद्ध OO भाषा नहीं है?
zxcdw

2
@zxcdw (और ddyer): यह वास्तव में समस्या है: किसी के पास "शुद्ध OO" की औपचारिक परिभाषा नहीं है, इसलिए कोई भी उस प्रश्न का निश्चित उत्तर नहीं दे सकता है।
जोकिम सॉर
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.