ऑब्जेक्ट ओरिएंटेड एक अवधारणा है। यह अवधारणा कुछ विचारों पर आधारित है। इन विचारों के तकनीकी नाम (वास्तव में ऐसे सिद्धांत जो उस समय विकसित हुए थे और पहले घंटे से नहीं रहे हैं) पहले से ही ऊपर दिए गए हैं, मैं उन्हें दोहराने वाला नहीं हूं। मैं इसे सरल और गैर-तकनीकी के रूप में समझा रहा हूं जैसा कि मैं कर सकता हूं।
ओओ प्रोग्रामिंग का विचार यह है कि ऑब्जेक्ट्स हैं। वस्तुएं छोटी स्वतंत्र संस्थाएं हैं। इन इकाइयों में एम्बेडेड जानकारी हो सकती है या वे नहीं कर सकते हैं। अगर उनके पास ऐसी जानकारी है, तो केवल इकाई ही इसका उपयोग कर सकती है या इसे बदल सकती है। संस्थाएं एक-दूसरे के बीच संदेश भेजकर एक दूसरे के साथ संवाद करती हैं।मनुष्यों को इसकी तुलना करें। मनुष्य स्वतंत्र संस्थाएं हैं, उनके मस्तिष्क में संग्रहीत आंतरिक डेटा और संचार करके एक-दूसरे के साथ बातचीत (जैसे एक-दूसरे से बात करना)। अगर आपको किसी और के दिमाग से ज्ञान की आवश्यकता है, तो आप इसे सीधे एक्सेस नहीं कर सकते हैं, आपको उसे एक प्रश्न पूछना चाहिए और वह आपको बता सकता है कि आप क्या जानना चाहते हैं।
और यह मूल रूप से यह है। ओओ प्रोग्रामिंग के पीछे यह असली विचार है। इन इकाइयों को लिखना, उनके बीच संचार को परिभाषित करना और उन्हें एक आवेदन बनाने के लिए एक साथ बातचीत करना है। यह अवधारणा किसी भी भाषा से बंधी नहीं है। यह सिर्फ एक अवधारणा है और यदि आप अपना कोड सी #, जावा, या रूबी में लिखते हैं, तो यह महत्वपूर्ण नहीं है। कुछ अतिरिक्त काम के साथ इस अवधारणा को शुद्ध सी में भी किया जा सकता है, भले ही यह एक कार्यात्मक भाषा है लेकिन यह अवधारणा के लिए आपको जो कुछ भी चाहिए, वह प्रदान करता है।
विभिन्न भाषाओं ने अब ओओ प्रोग्रामिंग की इस अवधारणा को अपनाया है और निश्चित रूप से अवधारणाएं हमेशा बराबर नहीं होती हैं। कुछ भाषाएं उदाहरण के लिए अन्य भाषाओं को किस प्रकार मना करती हैं। अब कक्षाओं की अवधारणा शामिल अवधारणाओं में से एक है। कुछ भाषाओं में कक्षाएं होती हैं, कुछ नहीं करते हैं। एक वर्ग एक ब्लूप्रिंट है कि ऑब्जेक्ट कैसा दिखता है। यह किसी ऑब्जेक्ट के आंतरिक डेटा संग्रहण को परिभाषित करता है, यह किसी ऑब्जेक्ट को समझने वाले संदेशों को परिभाषित करता है और यदि विरासत है (ओओ प्रोग्रामिंग के लिए अनिवार्य नहीं है!), कक्षाएं भी परिभाषित करती हैं कि कौन से अन्य वर्ग (या कक्षाएं एकाधिक विरासत हैं अनुमत) इस वर्ग को विरासत में मिला है (और चुनिंदा विरासत मौजूद होने पर कौन सी गुण)। एक बार जब आप इस तरह के ब्लूप्रिंट बनाएंगे तो अब आप इस ब्लूप्रिंट के अनुसार ऑब्जेक्ट्स की असीमित मात्रा उत्पन्न कर सकते हैं।
ओओ भाषाएं हैं जिनमें कोई कक्षा नहीं है, हालांकि। वस्तुओं को फिर कैसे बनाते हैं? खैर, आमतौर पर गतिशील रूप से। जैसे आप एक नई खाली वस्तु बना सकते हैं और फिर गतिशील रूप से आंतरिक संरचना जैसे इंस्टेंस चर या विधियों (संदेश) को जोड़ सकते हैं। या आप अपनी सभी संपत्तियों के साथ पहले से मौजूद ऑब्जेक्ट को डुप्लिकेट कर सकते हैं और फिर इसे संशोधित कर सकते हैं। या संभवतः दो वस्तुओं को एक नए में मिलाएं। कक्षा आधारित भाषाओं के विपरीत ये भाषाएं बहुत गतिशील होती हैं, क्योंकि आप रनटाइम के दौरान गतिशील रूप से वस्तुओं को उत्पन्न कर सकते हैं, न कि डेवलपर ने कोड लिखना शुरू करने के बारे में सोचा है।
आमतौर पर इस गतिशीलता की कीमत होती है: अधिक गतिशील एक भाषा अधिक स्मृति (रैम) ऑब्जेक्ट्स बर्बाद हो जाती है और धीरे-धीरे सबकुछ धीमा हो जाता है क्योंकि कार्यक्रम प्रवाह बेहद गतिशील रूप से होता है और यदि संकलक के लिए प्रभावी कोड उत्पन्न करना कठिन होता है तो कोड या डेटा प्रवाह की भविष्यवाणी करने का कोई मौका नहीं है। जेआईटी कंपाइलर्स रनटाइम के दौरान उस के कुछ हिस्सों को अनुकूलित कर सकते हैं, एक बार वे प्रोग्राम प्रवाह को जानते हैं, हालांकि ये भाषाएं इतनी गतिशील रूप से होती हैं, कार्यक्रम प्रवाह किसी भी समय बदल सकता है, जेआईटी को सभी संकलन परिणामों को फेंकने और उसी कोड को फिर से संकलित करने के लिए मजबूर कर सकता है बार बार।
लेकिन यह एक छोटा कार्यान्वयन विस्तार है - इसका मूल ओओ सिद्धांत से कोई लेना देना नहीं है। यह कहीं भी नहीं कहा गया है कि वस्तुओं को गतिशील होने की आवश्यकता है या रनटाइम के दौरान बदला जाना चाहिए। विकिपीडिया यह कहता है कि बहुत अच्छी तरह से:
प्रोग्रामिंग तकनीक इस तरह की जानकारी छुपा, डेटा अमूर्त, कैप्सूलीकरण, प्रतिरूपकता, बहुरूपता, और विरासत के रूप में विशेषताओं में शामिल हो सकते हैं।
http://en.wikipedia.org/wiki/Object-oriented_programming
वे मई या वे नहीं हो सकता। यह सब अनिवार्य नहीं है। अनिवार्य केवल वस्तुओं की उपस्थिति है और उनके पास एक दूसरे के साथ बातचीत करने के तरीके होना चाहिए (अन्यथा वस्तुएं बेकार होंगी यदि वे एक दूसरे के साथ बातचीत नहीं कर सकते हैं)।
युप - हम इसके बारे में कभी नहीं लड़ेंगे! –