गुणों की धारणा को शामिल करने के लिए OOP कैसे विकसित हुआ


12

मैं एक C ++ बैकग्राउंड से आया हूं और अपनी वर्तमान नौकरी में C # बाहर जा रहा हूं और मैं अभी बहुत सारे Q & A को पढ़ रहा हूं कि सार्वजनिक क्षेत्र और संपत्तियों और सभी के आगे और पीछे भिन्नताओं और अवतारों में क्या अंतर है। बुनियादी प्रश्न (जैसे यह एसओ पोस्ट और सभी संबंधित जुड़े प्रश्न )। उन सभी प्रश्नों को व्यावहारिक मतभेदों के संदर्भ में संबोधित किया जाता है जो एक संपत्ति प्रणाली के अस्तित्व को प्रदान करते हैं, लेकिन मुझे लगता है कि इस विषय पर दृष्टिकोण करना अच्छा होगा कि सभी भाषाओं के डिजाइनरों ने पहले गुणों का समर्थन करने का फैसला किया था जगह में सोच रहे थे (विकिपीडिया लेख में सूची की जाँच यहाँ)। OOP C ++ / Java से कैसे विकसित हुआ, यह जानने के लिए कि विकिपीडिया लेख क्या दिलचस्प तरीके से पहचानता है कि विधियों और सदस्य के बीच एक मध्यभूमि के रूप में पहचान करता है:

"यह है कि, गुण सदस्य कोड (विधियों) और वर्ग के सदस्य डेटा (उदाहरण चर) के बीच मध्यवर्ती होते हैं, और गुण सार्वजनिक क्षेत्रों की तुलना में उच्च स्तर के एन्कैप्सुलेशन प्रदान करते हैं।"

MSDN आगे की पृष्ठभूमि जोड़ता है:

"हालांकि गुण तकनीकी रूप से विधियों के समान हैं, वे अपने उपयोग परिदृश्यों के संदर्भ में काफी भिन्न हैं। उन्हें स्मार्ट फ़ील्ड के रूप में देखा जाना चाहिए। उनके पास फ़ील्ड के कॉलिंग सिंटैक्स और विधियों का लचीलापन है।"

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


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

OO विशेषज्ञों के एक दौर में आपका प्रश्न शीर्षक उत्तेजक हो सकता है, और जो आप वास्तव में पूछ रहे थे, उससे विचलित हो सकते हैं। ऐसा नहीं है कि मैं अपने आप को एक OO विशेषज्ञ के रूप में देखता हूं, मैं कई सालों से सिर्फ "OO उपयोगकर्ता" हूं।
डॉक्टर ब्राउन

यह एक सिंथैटिक न्युटी है, जिसे मैं पायथन में 'पैरामीटर-कम तरीकों' से C ++ में जाने से चूक गया हूं। आईएमओ के BMI = bob.weight/sq(bob.height)बिना अच्छे अच्छे पढ़ता है ()
OJFord

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

जारी रखना: संपत्ति विंडो कोड लिखने के बिना वस्तुओं को कॉन्फ़िगर करने का एक तरीका था। इसे आरएडी विकास कहा जाता था। इस लिंक में VB6 गुण विंडो का स्क्रीनशॉट है: microsoft.com/mspress/books/WW/sampchap/4068.aspx
फ्रैंक हिलमैन

जवाबों:


5

यह एनकैप्सुलेशन और यूनिफॉर्म एक्सेस प्रिंसिपल के बारे में है।

एक वस्तु संदेश को मौजूदा डेटा को वापस करके या एक विधि चलाकर संदेश का जवाब देने में सक्षम होना चाहिए, लेकिन प्रेषक को यह बताने में सक्षम नहीं होना चाहिए कि कौन सा है। या यदि आप प्रेषक की ओर से इसे देखते हैं: प्रेषक को मौजूदा डेटा तक पहुंचने में सक्षम होना चाहिए या एक समान इंटरफ़ेस के माध्यम से एक विधि चलाना चाहिए।

इसे प्राप्त करने के कई तरीके हैं:

  • डेटा से पूरी तरह से छुटकारा पाएं, बस विधियाँ हैं (समाचारपत्र ऐसा करता है)

    • उपरोक्त का एक कम कट्टरपंथी रूप: सार्वजनिक इंटरफ़ेस में डेटा से छुटकारा पाएं , यानी डेटा को हमेशा निजी बनाएं, सार्वजनिक इंटरफ़ेस में, केवल तरीकों का खुलासा करें (स्मॉलटॉक, रूबी ऐसा करें)
  • पूरी तरह से तरीकों से छुटकारा पाएं, बस डेटा है (स्वयं यह करता है, "विधियाँ" सिर्फ Methodऑब्जेक्ट हैं जिन्हें चर चर दिया जाता है, उदाहरण चर आभासी प्रेषण के साथ देखे जाते हैं)

  • विधियों और डेटा के बीच कोई वाक्यात्मक या शब्दार्थ भेद न करें (स्काला ऐसा करता है, किसी फ़ील्ड को एक्सेस करना तर्क की सूची के बिना विधि को कॉल करने से कृत्रिम रूप से अप्रभेद्य है foo.bar) ( ), किसी फ़ील्ड को असाइन करना विशेष रूप से नामित विधि ( foo.bar = baz) को कॉल करने से वाक्यविन्यास है। के रूप में foo.bar_=(baz)यानी एक विधि नामित बुला foo_=, और केवल पढ़ने के लिए मान ओवरराइड हो सकता है या एक विधि द्वारा पैरामीटर सूची (यानी बिना लागू किया जा val foo) एक सुपर क्लास अधिरोहित जा सकता है में (या एक abstract valएक विधि के साथ एक उपवर्ग में लागू किया) def foo)

जावा, हालांकि, यूनिफ़ॉर्म एक्सेस सिद्धांत का पालन नहीं करता है। जावा में, डेटा तक पहुंचने और एक विधि चलाने के बीच अंतर करना संभव है। foo.barसे अलग है foo.bar()। इसका कारण यह है कि क्षेत्र और विधियां शब्दार्थ और वाक्यविन्यास रूप से भिन्न हैं।

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

तो, यह वास्तव में समस्या को ठीक नहीं करता है: आप चीजों तक पहुंचने के लिए तीसरे तरीके को जोड़कर चीजों तक पहुंचने के दो अलग-अलग तरीके ठीक नहीं कर सकते हैं! यहां तक ​​कि अगर तीसरा तरीका अन्य दो तरीकों में से एक जैसा दिखता है, तो भी आपके पास दो अलग-अलग तरीके होंगे। आप केवल एक को छोड़कर सभी अलग-अलग तरीकों से छुटकारा पाकर इसे ठीक कर सकते हैं या मतभेदों से छुटकारा पा सकते हैं।

विधियों, गुणों और क्षेत्रों के साथ एक भाषा होना पूरी तरह से ठीक है, लेकिन तीनों में समान पहुंच होनी चाहिए।


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

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

इस सवाल के बहुत अच्छे जवाब हैं लेकिन मुझे लगता है कि इसने प्रोग्रामिंग भाषाओं की प्रकृति के अधिक बुनियादी पहलुओं को खींच कर और यूएपी की प्रासंगिक औपचारिक अवधारणा के बारे में विस्तार से बताकर सिर पर कील ठोक दी। ठोस
jxramos

18

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

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


इसका ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग से कोई लेना-देना नहीं है, सिवाय इस बात के कि कोई प्रॉपर्टी किसी फ़ील्ड का एब्स्ट्रैक्शन है, और फ़ील्ड ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग का हिस्सा हैं। लेकिन ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग के लिए गुणों की आवश्यकता नहीं है, जैसा कि आप सही ढंग से ध्यान दें।
फ्रैंक हिलमैन

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

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

1
हा! यह मेरे लिए programmers.stackexchange का काफी परिचय है। योग्य, सादा ओएल स्टैकओवरफ़्लो में मेरे समकक्ष अनुभव की तुलना में बहुत अधिक गर्म: - दिन को मिलाने का अच्छा तरीका!
jxramos


11

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

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

एक से व्यावहारिक दृष्टिकोण, वहाँ दो काफी स्पष्ट मंशा है। आप C ++ बैकग्राउंड से आते हैं, इसलिए यदि आपके पास एक सार्वजनिक फ़ील्ड है - तो कहने की क्या ज़रूरत है ... टेक्स्ट बॉक्स में टेक्स्ट। जब आप अपना डिज़ाइन बदलना चाहते हैं तब क्या होता है ताकि "जब भी यह टेक्स्टबॉक्स बदलता है, तो ब्ला करें"? आपको उस फ़ील्ड को मारना है, एक फ़ंक्शन या दो बनाना है और उस तर्क को तार करना है, क्योंकि आप डेवलपर्स को "अपडेटटेक्स्टबॉक्स" के रूप में कॉल करने के लिए भरोसा नहीं कर सकते हैं। यह आपके एपीआई (और दुर्भाग्य से अभी भी .NET के गुणों के कार्यान्वयन में एक परिवर्तन है) के लिए एक बहुत ही टूटने वाला परिवर्तन है। इस प्रकार का व्यवहार विंडोज एपीआई में सभी जगह होता है। चूंकि यह Microsoft पर एक बड़ी बात है, इसलिए C # संभावना को कम दर्दनाक बनाना चाहता था।

अन्य बड़ी प्रेरणा जावा बीन्स और उनके परिजन हैं। जावा प्रतिबिंब का उपयोग करने के लिए GetXऔर SetXजोड़े को देखने के लिए कई फ्रेमवर्क बनाए गए थे और उन्हें आधुनिक गुणों की तरह प्रभावी ढंग से व्यवहार करते थे। लेकिन चूँकि वे वास्तविक भाषा निर्माण नहीं थे, इसलिए ये रूपरेखा नाजुक और अस्वाभाविक थी। यदि आप एक नाम टाइप करते हैं, तो चीजें चुपचाप टूट जाती हैं। यदि किसी को रिफलेक्ट किया जाता है, तो संपत्ति के दूसरी तरफ कुछ भी नहीं जाता है। और क्षेत्र के सभी / कर / सेट बायलरप्लेट क्रिया और थकाऊ था (जावा के लिए भी!)। चूँकि C # को काफी हद तक "Java with lesson learn" के रूप में विकसित किया गया था, इस तरह का दर्द उन पाठों में से एक था।

लेकिन सबसे बड़ी बात यह है कि संपत्ति की अवधारणा सफल रही है। यह समझना आसान है, इसका उपयोग करना आसान है। ये गोद लेने में बहुत मदद करते हैं, और एक उपकरण के रूप में , प्रोग्रामर ने पाया है कि गुण या तो कार्यों या क्षेत्रों की तुलना में अधिक सफाई से समस्याओं का एक सबसेट हल करते हैं।


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

9
@DeadMG - यह निश्चित रूप से सच है, लेकिन दूसरी ओर प्रोग्रामिंग भाषा कार्यान्वयनकर्ता अपरिवर्तनीय रूप से उस अप्रासंगिक औपचारिक बकवास से परिचित होने जा रहे हैं । यह सोचने के लिए कि यह उनके डिजाइन को प्रभावित नहीं करता है भोली है।
तेलेस्टिन डे

3
यह निश्चित रूप से "अप्रासंगिक औपचारिक बकवास नहीं है।" हालाँकि, लैम्बडा कैलकुलस को प्रारंभिक प्रोग्रामिंग भाषाओं के लिए बहुत अधिक नहीं माना गया है। यदि हां, तो सीपीयू शायद उस मानसिकता की ओर अधिक उन्मुख होगा।
फ्रैंक हिलमैन

3
@FrankHileman - मुझे पूरा यकीन है कि लिस्प ने इस पर विचार किया ...
Telastyn

4
@Telastyn - हाँ - और लिस्प मूल रूप से एक प्रोग्रामिंग भाषा नहीं माना जाता था, याद है?
फ्रैंक हिलमैन

3

विशेष रूप से, नेट में, गुण पुराने विज़ुअल बेसिक दिनों से उत्पन्न होते हैं, जैसा कि ऐसा होता है कि आज हम इसके बारे में सोचने के तरीके में वस्तु उन्मुख नहीं थे। यह काफी हद तक तत्कालीन नई COM प्रणाली के आसपास बना था जो सतही रूप से जरूरी नहीं कि सब कुछ कक्षाओं के रूप में व्यवहार करता था, लेकिन उन घटकों के संदर्भ में जो उन गुणों को उजागर करते थे जो कोड में लेकिन ग्राफ़िकल संपादकों में भी एक्सेस किए जा सकते थे। जब VB और नव निर्मित C # को .net में मिला दिया गया था, VB ने बहुत सारी OOP-features प्राप्त कीं और उन्हें हटाने के बाद से ही संपत्तियों को रखा गया, वे एक कदम पीछे की तरह होंगे - कल्पना करें कि जो स्वचालित कोड अपडेट टूल उनके पास Visual Studio में था अपने सभी गुणों को गेटर्स और सेटर्स के साथ बदलना और सभी COM-पुस्तकालयों के साथ संगतता को तोड़ना था। सभी में उनका समर्थन करना तर्कसंगत होगा।


मुझे नहीं लगता कि आपको सी # के वंश को अनदेखा करना चाहिए जो डेल्फी से आया था और इससे पहले, ऑब्जेक्ट के साथ ऑब्जेक्ट पास्कल और टर्बो पास्कल। ये ऑब्जेक्ट-ओरिएंटेड थे और इनमें गुण थे (हालांकि मुझे याद नहीं है कि ओपी में TP5.5 से गुण हैं या नहीं, चाहे वे लागू हों। संभवतः एंडर्स द्वारा उन्हें C # में जारी रखा गया था क्योंकि वे व्यावहारिक रूप से एक अच्छा विचार थे।
amaca

बहुत दिलचस्प है कि आप इस सवाल के घटक पहलू पर हिट करने के लिए केवल एक ही हुआ। मैंने सिर्फ अपने प्रश्न को एक साइट से जोड़ने के लिए एक टिप्पणी जोड़ दी जो कुछ संपत्ति-विधि-घटना मॉडल के भाग के रूप में सूचीबद्ध गुण है जो C # को संतुष्ट करता है। मैंने तब अपने घटक के कुछ गलत सकारात्मक लैंडिंग "घटक" के लिए फिर से अपना प्रश्न पृष्ठ खोजा, लेकिन आपका जवाब मुझे लगता है कि वास्तव में मैं इससे जुड़ा हुआ हूं।
jxramos

3

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

खेतों में गुणों के फायदे हैं:

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

क्योंकि गुण फ़ील्ड्स के अमूर्तन हैं, और सिंटैक्टिक सुविधा के लिए, C # जैसी भाषाओं ने गुणों के लिए फ़ील्ड सिंटैक्स अपनाया है।


2
विकिपीडिया लेख से पहली पंक्ति। "कुछ ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग भाषाओं में एक संपत्ति, वर्ग के सदस्य का एक विशेष प्रकार है ..."। तो आपका पहला वाक्य सादा गलत है। और शेष भाग प्रश्न का उत्तर नहीं देता है।
डॉक ब्राउन

1
@DocBrown: दिलचस्प प्रतिक्रिया। कई विकिपीडिया लेख स्पष्ट रूप से गलत हैं। मुझे लगता है कि आप इस विशिष्ट लेख के लेखक का बचाव कर रहे हैं?
फ्रैंक हिलमैन

1
ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग भाषाओं की सभी विशेषताएं ऑब्जेक्ट-ओरिएंटेड अवधारणाओं से संबंधित नहीं हैं।
फ्रैंक हिलमैन

1
यह इस तथ्य को नहीं बदलता है कि आप प्रश्न का उत्तर नहीं दे रहे हैं।
डॉक ब्राउन

3
यह ध्यान दिया जाना चाहिए कि यह सिर्फ सेटर नहीं है जो वैकल्पिक है। आपके पास सेटर केवल गुण हो सकते हैं।
तेलेस्टिन डे

2

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

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

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

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


मैं कुछ अंकों के साथ सहमत हैं और अन्य लोगों के साथ असहमत हैं, लेकिन समग्र संदेश एक अच्छा एक है: के बारे में एक वस्तु की जरूरत है की गणना करने के कुछ जानकारी है लेकिन अभी भी तकनीकी रूप से जानकारी है कि है है एक ऐसी कार्रवाई की जा सकती है के बजाय किया
छपरा

0

बिल्कुल कुछ भी नहीं। गुण और OOP का एक दूसरे से कोई लेना-देना नहीं है। गुण फ़ंक्शन फ़ंक्शन कॉल के लिए सिंटैक्टिक शुगर से अधिक कुछ नहीं हैं, और इसलिए बिल्कुल वही ओओपी-लगाव है जो फ़ंक्शन कॉल करता है- जो कि कहना है, कोई नहीं।

विकिपीडिया पूरी तरह से गलत है। आपके द्वारा जावा में देखे जाने वाले गेटमेम्बर / सेटमेम्बर पैटर्न सी # में गुणों के समान ही लाभ (और नुकसान) प्रदान करता है। और आप चाहे तो C में भी इस पैटर्न को दोहरा सकते हैं।

C # में गुण भाषा समर्थित सिंटैक्टिक-चीनी से ज्यादा कुछ नहीं हैं।


3
क्या आपने कभी क्लास या ऑब्जेक्ट संदर्भ के बाहर किसी भी प्रोग्रामिंग भाषा में संपत्ति की अवधारणा देखी है? मेरे पास नही है।
डॉक ब्राउन

1
@DocBrown: मैंने इसे लागू कर दिया है। तथ्य यह है कि, भाषा के लेखकों के लिए गुण बहुत कम मूल्य के लक्ष्य हैं, क्योंकि नियमित फ़ंक्शन कॉल में उनका सुधार कम है।
डेडएमजेड डेम

1
ओपी लोकप्रिय प्रोग्रामिंग भाषाओं में एक अवधारणा के रूप में गुणों के इतिहास के बारे में पूछ रहा था । और वास्तव में, ऐतिहासिक अर्थों में गुणों और ओओपी के बीच एक संबंध है।
डॉक ब्राउन

2
हो सकता है कि मैं संपत्तियों की इस अवधारणा को OOP प्रतिमान प्रति सेशन पर लिखने के लिए थोड़ा रैश था, लेकिन एक अवधारणा के रूप में यह निश्चित रूप से व्यक्तिगत भाषाओं और उनकी विशेषताओं को प्रसारित करता है। शायद मैं दोनों के बीच उचित ऑन्कोलॉजी को स्पष्ट करने के लिए संघर्ष कर रहा हूं। मैं प्रश्न के शीर्षक के माध्यम से सुझाव दे नहीं कर रहा हूँ कि गुण एक मौलिक सुविधा / की अवधारणा हैं OOP बनाता है या टूट जाता है OOP रीतिवाद, और अभी तक मैं समझ कर वे केवल इस OOP अंतरिक्ष जिसके कारण मैं इस तरह के रूप सवाल phrased में एक वास्तविकता है कि ।
jxramos

4
वे सी # में केवल सिंटैक्स चीनी नहीं हैं, वे अलग-अलग सदस्यों के रूप में विधानसभा मेटाडेटा में मौजूद हैं और आप उन गुणों के साथ काम कर सकते हैं जिन्हें आप फ़ील्ड के साथ नहीं कर सकते हैं, जैसे डेटाबाइंडिंग।
एंडी
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.