2008-09-09 17 views
14

इसने कल रात मेरा ध्यान खींचा।दावा क्यों है कि सी # लोगों को ऑब्जेक्ट उन्मुख प्रोग्रामिंग नहीं मिलती है? (बनाम वर्ग उन्मुख)

नवीनतम ALT.NET Podcast पर स्कॉट बेलवेयर चर्चा करता है कि रुबी के विपरीत, सी #, जावा एट अल जैसी भाषाओं के बारे में चर्चा कैसे की जाती है। वास्तव में ऑब्जेक्ट उन्मुख नहीं हैं बल्कि "वर्ग-उन्मुख" वाक्यांश का चयन कर रहे हैं। वे इस भेद के बारे में बहुत अस्पष्ट शब्दों में बिना विस्तार से या पेशेवरों और विपक्ष पर चर्चा किए बिना बात करते हैं।

यहां वास्तविक अंतर क्या है और इससे कोई फर्क नहीं पड़ता? फिर अन्य वस्तुएं क्या हैं "वस्तु-उन्मुख"? यह बहुत रोचक लग रहा था, लेकिन मैं सिर्फ यह जानने के लिए रूबी सीखना नहीं चाहता कि क्या कुछ भी मुझे याद आ रहा है।

अद्यतन: कुछ उत्तर पढ़ने ऐसा लगता है नीचे के लोगों की तरह आम तौर पर सहमत है कि संदर्भ बतख टाइपिंग है के बाद। मुझे यकीन नहीं है कि मैं अभी भी समझता हूं कि दावा यह है कि यह अंततः इतना बदलता है। विशेष रूप से यदि आप पहले से ही ढीले युग्मन ब्ला ब्ला ब्लाह के साथ उचित tdd कर रहे हैं। क्या कोई मुझे एक आश्चर्यजनक चीज़ का उदाहरण दिखा सकता है जो मैं रूबी के साथ कर सकता हूं कि मैं सी # के साथ नहीं कर सकता और यह इस अलग ओप दृष्टिकोण का उदाहरण देता है?

उत्तर

15

यहां बतख टाइपिंग टिप्पणियां इस तथ्य के लिए अधिक जिम्मेदार हैं कि रूबी और पायथन अधिक गतिशील सी # से अधिक हैं। यह वास्तव में ओओ प्रकृति के साथ कुछ भी करने के लिए नहीं है।

क्या (मुझे लगता है) बेलवेयर का मतलब है कि रूबी में, सब कुछ एक वस्तु है। यहां तक ​​कि एक वर्ग। एक वर्ग परिभाषा एक वस्तु का एक उदाहरण है। इस प्रकार, आप रनटाइम पर व्यवहार को जोड़/बदल/हटा सकते हैं।

एक और अच्छा उदाहरण यह है कि न्यूल भी एक वस्तु है। रूबी में, सब कुछ एक वस्तु है। इस तरह के गहरे ओओ होने के कारण पूरे मज़ेदार मेटा-प्रोग्रामिंग तकनीकों जैसे method_missing की अनुमति मिलती है।

2

शायद वे बतख टाइपिंग और कक्षा पदानुक्रमों के बीच के अंतर के बारे में बता रहे हैं?

यदि यह एक बतख की तरह बतख और quacks की तरह चलता है, तो बस यह एक बतख का नाटक और इसे लात मारो। आप उस वस्तु पर यह कार्रवाई करने के लिए अनुमति दी:

सी # में, जावा आदि संकलक बारे में बहुत कुछ fusses?

ऑब्जेक्ट ओरिएंटेड बनाम क्लास ओरिएंटेड का अर्थ यह हो सकता है: क्या भाषा वस्तुओं या कक्षाओं के बारे में चिंता करती है?

उदाहरण के लिए: अजगर में, एक iterable वस्तु लागू करने के लिए, आप केवल एक विधि __iter__() है कि एक वस्तु एक विधि next() नामित किया है कि रिटर्न भी देनी होगी। यह सब कुछ है: कोई इंटरफ़ेस कार्यान्वयन नहीं है (ऐसी कोई चीज़ नहीं है)। कोई उपclassing नहीं। बस एक बतख/पुनरावर्तक की तरह बात कर रहे हैं।

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

0

मैं इस पर एक स्टैब ले जाऊंगा।

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

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

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

9

OOP

के तीन स्तंभ
  1. Encapsulation
  2. विरासत हैं
  3. बहुरूपता

एक भाषा उन तीन बातें यह एक OOP भाषा का पता लगा सकते हैं।

मुझे पूरा यकीन है कि भाषा एक्स का तर्क भाषा ए से बेहतर ओओपी करता है हमेशा के लिए चला जाएगा।

+0

युप - हम इसके बारे में कभी नहीं लड़ेंगे! –

10

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

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

0

यह वास्तव में संभव है कि इन लोगों को सी # और जावा में अन्य लोगों को सी # और जावा का समर्थन करने वाले ओओपी के विरोध में क्या दिखाई दे रहा है। अधिकांश भाषाएं विभिन्न प्रोग्रामिंग प्रतिमानों में उपयोग की जा सकती हैं। उदाहरण के लिए, आप सी # और योजना में प्रक्रियात्मक कोड लिख सकते हैं, और आप जावा में कार्यात्मक-शैली प्रोग्रामिंग कर सकते हैं। यह आप और क्या करने की कोशिश कर रहे हैं और भाषा का समर्थन करने के बारे में अधिक है।

2

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

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

1

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

के लिए सी # लोग काफी OO नहीं किया जा रहा के रूप में ... दिल में ले .. बस वही जो आप बोलते हैं जब आप शब्दों के लिए मुश्किल में पड़ रहे हैं के रूप में इसे ले नहीं है। रूबी ज्यादातर लोगों के लिए करता है।
अगर मुझे वर्तमान दशक में लोगों को सीखने के लिए एक भाषा की सिफारिश करनी पड़ी .. यह रूबी होगी। मुझे खुशी है कि मैंने किया .. हालांकि कुछ लोग पाइथन का दावा कर सकते हैं। लेकिन यह मेरी राय की तरह .. आदमी! : डी

+0

"अंतर्निहित स्ट्रिंग क्लास कोज़ में नई विधियां जोड़ना आपको ऐसा लगता है"। श्वास, और एमएस ने इसकी बात सुनी और सी # में एक्सटेंशन विधियों को जोड़ा। – gbjbaanb

+0

आप इसे सी # 4.0 के साथ प्यार करेंगे :) अब स्थिर और गतिशील भाषाओं के बीच गंदे पानी। Google ने एंड्रॉइड पीडीसी फ्यूचर ऑफ सी # – Gishu

3

अपडेट: इसकी नई लहर .. जो अब तक हम सब कुछ कर रहे हैं, सुझाव देते हैं .. पॉडकास्ट और किताबों में काफी कुछ बढ़ रहा है .. शायद यही वह है जो आपने सुना है।

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

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

animal = Object.new     # create a new instance of base Object 

def animal.number_of_feet=(feet)  # adding new methods to an Object instance. What? 
    @number_of_feet = feet 
end 
def animal.number_of_feet 
    @number_of_feet 
end 

cat = animal.clone   #inherits 'number_of_feet' behavior from animal 
cat.number_of_feet = 4 

felix = cat.clone   #inherits state of '4' and behavior from cat 
puts felix.number_of_feet # outputs 4 

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

समस्याओं के बारे में हम कैसे सोचते हैं, इसके बुनियादी प्राइमेटिव को चुनौती देकर, 'असली ओओपी' एक तरह से 'मैट्रिक्स' जैसा है ... आप एक लूप में डब्ल्यूटीएफ जा रहा है। इस तरह की .. जहां कंटेनर का बेस क्लास या तो ऐरे या हैश हो सकता है, जिस पर 0.5 के किनारे यादृच्छिक संख्या उत्पन्न होती है।

class Container < (rand < 0.5 ? Array : Hash) 
end 

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

+0

गिशू पर इस शक्ति को "फाथॉम" करने की कोशिश करने के बजाय, मेटाप्रोग्रामिंग द्वारा सक्षम एक विस्तारित प्रोजेक्ट में हाथ क्यों नहीं मिला? यही कारण है कि मुझे सी # दुनिया (और इससे पहले जावा) से आने वाली अपनी संज्ञानात्मक बाधाओं को दूर करने में मदद मिली। अगर मुझे असली, मूर्त, व्यावहारिक और व्यावहारिक अनुभव नहीं मिला है, तो मुझे शायद यह एहसास नहीं हुआ होगा कि मैं किसी दिए गए प्रतिमान के गुणों का आकलन करने की कोशिश कर रहा था, जिसके बिना मैं सबसे ज्यादा प्रभावित हूं। –

1

मुझे नहीं लगता कि यह विशेष रूप से बतख टाइपिंग के बारे में है। उदाहरण के लिए सी # पहले से ही सीमित बतख-टाइपिंग का समर्थन करता है - एक उदाहरण यह होगा कि आप पर किसी भी कक्षा पर foreach का उपयोग कर सकते हैं जो MoveNext और Current लागू करता है।

बतख-टाइपिंग की अवधारणा जावा और सी # जैसी स्थिर टाइप की गई भाषाओं के साथ संगत है, यह मूल रूप से प्रतिबिंब का विस्तार है।

यह वास्तव में स्थैतिक बनाम गतिशील टाइपिंग का मामला है। दोनों उचित हैं- ओओ, उतनी ही चीज है जितनी। अकादमिक के बाहर यह वास्तव में बहस के लायक नहीं है।

बकवास कोड या तो लिखा जा सकता है। महान कोड या तो लिखा जा सकता है। बिल्कुल कुछ भी कार्यात्मक नहीं है कि एक मॉडल ऐसा कर सकता है जो दूसरा नहीं कर सकता है।

असली अंतर कोडिंग की प्रकृति में है। स्टेटिक प्रकार स्वतंत्रता को कम करते हैं, लेकिन लाभ यह है कि हर कोई जानता है कि वे किसके साथ काम कर रहे हैं। फ्लाई पर उदाहरण बदलने का अवसर बहुत शक्तिशाली है, लेकिन लागत यह है कि यह जानना मुश्किल हो जाता है कि आप क्या कर रहे हैं।

उदाहरण के लिए जावा या सी # इंटेलिजेंस के लिए आसान है - आईडीई संभावित रूप से संभावनाओं की एक ड्रॉप सूची उत्पन्न कर सकता है। जावास्क्रिप्ट या रूबी के लिए यह बहुत कठिन हो जाता है।

कुछ चीजों के लिए, उदाहरण के लिए एक एपीआई तैयार करना जो किसी और के साथ कोड करेगा, स्थिर टाइपिंग में एक वास्तविक लाभ है। उदाहरण के लिए, उदाहरण के लिए तेजी से प्रोटोटाइप का उत्पादन, लाभ गतिशील हो जाता है।

अपने कौशल टूलबॉक्स में दोनों की समझ रखने के लायक है, लेकिन जहां कहीं भी आप वास्तविक गहराई में उपयोग कर रहे हैं उसे समझने के लिए कहीं भी महत्वपूर्ण नहीं है।

4

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

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

तो इस अर्थ में सी # और अन्य स्थैतिक रूप से टाइप की गई ओओ भाषाएं सच नहीं हैं ओओ, साइन था में "सत्य" encapsulation की कमी है।

+0

यह एक दिलचस्प दृष्टिकोण है। लेकिन यहां तक ​​कि अजगर या रूबी में आपको कन्स्ट्रक्टर में अपनी निर्भरताओं को इंजेक्शन देना चाहिए। तो यदि आपके पास कुकीएटिंग सेवा पर निर्भरता है तो आपको कुछ इंजेक्ट करना होगा! यहां तक ​​कि अगर किसी भी तरह दुभाषिया आपके लिए इसका ख्याल रखता है और शून्य को इंजेक्ट करता है तो सेवा कॉल कर रहा है। EatCookie() एक त्रुटि का कारण बन जाएगा। यह केवल तभी काम करेगा जब एक विशिष्ट कार्यान्वयन नहीं मिलता है जब एक स्टब प्रदान किया जाता है। यह ऐसा कुछ है जो सी # भी कर सकता है (हालांकि अधिक कठिनाई के साथ) –

+0

जॉर्ज, ओओ में कुछ भी नहीं है जो बताता है कि निर्भरताओं को कन्स्ट्रक्टर तर्कों के माध्यम से "इंजेक्शन" होना चाहिए - या यहां तक ​​कि होना चाहिए। यह डी ढांचे की उम्र में स्थिर भाषा प्रोग्रामिंग का पूर्वाग्रह है। यह एक विशेष सांस्कृतिक पूर्वाग्रह है और निर्भरता उलटा सिद्धांत के मूल्यों में परिलक्षित नहीं होता है। –

23

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

1

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

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

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

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

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

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

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

प्रोग्रामिंग तकनीक इस तरह की जानकारी छुपा, डेटा अमूर्त, कैप्सूलीकरण, प्रतिरूपकता, बहुरूपता, और विरासत के रूप में विशेषताओं में शामिल हो सकते हैं।

http://en.wikipedia.org/wiki/Object-oriented_programming

वे मई या वे नहीं हो सकता। यह सब अनिवार्य नहीं है। अनिवार्य केवल वस्तुओं की उपस्थिति है और उनके पास एक दूसरे के साथ बातचीत करने के तरीके होना चाहिए (अन्यथा वस्तुएं बेकार होंगी यदि वे एक दूसरे के साथ बातचीत नहीं कर सकते हैं)।

+0

@ मेक्ल: मैं ध्यान दूंगा कि अकादमियों के बाहर, आधुनिक दुनिया में संदेशों को पारित करने से संचारित वस्तुओं की अवधारणा। प्रौद्योगिकी के विकास के दौरान यह एक महत्वपूर्ण अवधारणा थी, लेकिन अब एक अलग अवधारणा के रूप में महत्वपूर्ण नहीं है। –

1

आपने पूछा: "क्या कोई मुझे एक आश्चर्यजनक चीज़ का उदाहरण दिखा सकता है जो मैं रूबी के साथ कर सकता हूं कि मैं सी # के साथ नहीं कर सकता और यह इस अलग ओप दृष्टिकोण का उदाहरण देता है?"

एक अच्छा उदाहरण सक्रिय रिकॉर्ड है, ओआरएम रेल में बनाया गया है। डेटाबेस स्कीमा के आधार पर मॉडल वर्ग गतिशील रूप से रनटाइम पर बनाए जाते हैं।

+0

मुझे गलत मत समझो, मैंने तब से रूबी सीखना शुरू कर दिया है और मुझे यह बहुत पसंद है लेकिन सक्रिय आरकॉर्ड वास्तव में ओओपी सिद्धांतों का एक उदाहरण है जो सी # में संभव नहीं है? यह ओओ की बजाय गतिशील भाषाओं की क्षमताओं का एक उदाहरण जैसा प्रतीत होता है। वैसे, सी # में कई लोकप्रिय ActiveRecord कार्यान्वयन हैं - सबसे लोकप्रिय मोनोरेल –

+0

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

+0

गॉचा, स्पष्टीकरण के लिए धन्यवाद –