आपके अनुसार वह सुविधा क्या है जिसने ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग को इतना सफल बनाया है?
या कुछ अन्य सुविधा जिसे आप पेश करना पसंद कर सकते हैं।
इसके अलावा मैं यह जानना चाहूंगा कि अमूर्त डेटा प्रकार और ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग के बीच क्या संबंध है?
जवाबों:
मेरा सुझाव है कि ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग की सबसे महत्वपूर्ण विशेषता जटिलता प्रबंधन है ।
मानव मस्तिष्क केवल एक समय में इतनी सारी अवधारणाएं धारण कर सकता है - 7 +/- 2 स्वतंत्र वस्तुओं को याद रखने की अक्सर उद्धृत सीमा मन में आती है।
जब मैं काम पर एक 600kloc प्रणाली पर काम कर रहा हूं, तो मैं एक ही बार में पूरी चीज को अपने सिर में नहीं रख सकता। अगर मुझे ऐसा करना होता, तो मैं बहुत छोटे सिस्टम पर काम करने तक सीमित रहता ।
सौभाग्य से, मेरे पास नहीं है। विभिन्न डिजाइन पैटर्न और अन्य संरचनाएं जो हमने उस परियोजना पर उपयोग की हैं, का मतलब है कि मुझे एक ही बार में पूरी प्रणाली से निपटने की ज़रूरत नहीं है - मैं व्यक्तिगत टुकड़े उठा सकता हूं और उन पर काम कर सकता हूं, यह जानकर कि वे व्यापक अनुप्रयोग में फिट होते हैं अच्छी तरह से परिभाषित तरीकों में।
सभी महत्वपूर्ण ओओ अवधारणाएं जटिलता का प्रबंधन करने के तरीके प्रदान करती हैं।
एनकैप्सुलेशन - मुझे एक बाहरी एपीआई से निपटने दें जो मुझे विभिन्न सेवाओं के साथ प्रदान करता है, बिना यह चिंता किए कि उन सेवाओं को कैसे लागू किया जाता है।
अमूर्तता - मुझे आवश्यक विशेषताओं पर ध्यान केंद्रित करने और जो प्रासंगिक नहीं है उसे अनदेखा करें।
रचना - मुझे उन घटकों का पुन: उपयोग करने दें जो पहले से ही नए संयोजनों में बनाए गए हैं
बहुरूपता - मुझे इस बारे में चिंता किए बिना एक सेवा के लिए पूछें कि विभिन्न वस्तुओं को विभिन्न तरीकों से कैसे प्रदान किया जा सकता है।
वंशानुक्रम - मुझे एक अंतरफलक या कार्यान्वयन का पुन: उपयोग करने दें, केवल वही टुकड़े प्रदान करें जो पहले चले गए से अलग हैं।
सिंगल रिस्पांसिबिलिटी प्रिंसिपल - प्रत्येक ऑब्जेक्ट के उद्देश्य को स्पष्ट और संक्षिप्त रखने देता है, इसलिए इसके बारे में तर्क करना आसान है
लिसकोव प्रतिस्थापन प्रधान - चलो एक-दूसरे के लिए अजीब निर्भरता शुरू करके जाल नहीं बिछाते
ओपन / बंद सिद्धांत - आइए उन तरीकों में विस्तार और संशोधन की अनुमति दें जिनसे हमें मौजूदा कोड को तोड़ने का जोखिम न उठाना पड़े
निर्भरता इंजेक्शन - चलो अगले स्तर पर रचना लेते हैं और घटकों को एक साथ बहुत बाद में इकट्ठा करते हैं।
इंटरफ़ेस उन्मुख विकास - चलो अगले स्तर पर अमूर्तता लेते हैं और केवल अमूर्तता पर निर्भर करते हैं, कभी भी एक ठोस कार्यान्वयन पर नहीं।
ग्राफिकल यूजर इंटरफेस। अस्सी के दशक के उत्तरार्ध में, प्रारंभिक नब्बे के दशक में, जब मैक, अमीगा, अटारी एसटीएस, विंडोज और जीईएम ने चरित्र आधारित उपयोगकर्ता इंटरफेस को बदलना शुरू किया, यह स्पष्ट हो गया कि सी जैसी भाषाएं जीयूआई कार्यक्रम लिखने के लिए अच्छी तरह से अनुकूल नहीं हैं। जबकि पारंपरिक डेटा प्रोसेसिंग को "इनपुट डेटा -> प्रोसेसिंग -> आउटपुट डेटा" स्कीमा के रूप में माना जाता है, जो कि एक प्रक्रियात्मक भाषा में भी किया जा सकता है, ओयूएस सुविधाओं ने केवल जीयूआई की अंतर्निहित जटिलता को संभालने के लिए काम किया।
एनकैप्सुलेशन द्वारा प्रदान की गई डेटा छिपाना।
एक विशेषता जिसे अन्य किसी भी उत्तर द्वारा अभी तक उल्लेख नहीं किया गया है: डोमेन मॉडलिंग । क्योंकि लोग वस्तुओं के साथ या वस्तुओं को करने के बारे में सोचते हैं, और आंतरिक गुणों वाली वस्तुओं के बारे में, ऑब्जेक्ट-उन्मुख सॉफ़्टवेयर का उपयोग करके समस्या या वर्कफ़्लो को मॉडल करना बहुत आसान है। अनिवार्य रूप से, यह हमें कोड में संज्ञा, क्रिया और विशेषण से निपटने के लिए हमारी मौजूदा क्षमता का उपयोग करने की अनुमति देता है।
मुझे लगता है कि विरासत OOP का सबसे महत्वपूर्ण बिंदु है।
[गेम डेवलपमेंट से] आप एक ड्रॉबल क्लास जैसा कुछ बना सकते हैं, रेंडरिंग के तरीकों और विशेषताओं के साथ, और एक स्पेसशिप और प्लैनेट क्लास बना सकते हैं, जो ड्रॉबल से विरासत में मिली है। उन [और अन्य स्प्राइट बच्चे] से सभी वस्तुओं को लें, एक drawableObjArray में फेंक दें और प्रत्येक ऑब्जेक्ट के लिए ड्रॉ विधि को कॉल करें। आपको बस यह जानना होगा कि यह एक ड्रॉबल है।
अनावश्यक चीजों को छिपाने के लिए आवश्यक सेवाएं प्रदान करना। मेरी व्याख्या यहाँ देखें- अमूर्तता क्या है?
यह कुछ हद तक सफल है क्योंकि यह वस्तुओं में मानव मन के संगठन के उपयोग को प्रोत्साहित करता है। लोग आमतौर पर चीजों के रिश्तों को देखने में अच्छे होते हैं - मतभेद, समानता और व्यवहार जैसी चीजें। OO दुनिया के मानव अवधारणा की नकल करने के लिए विकासशील सॉफ्टवेयर को प्रोत्साहित करता है।
सॉफ्टवेयर विकास को हम दुनिया को देखने के तरीके के समान बनाते हुए हमारे मन की जटिलता को संभालना आसान बनाते हैं।
" ADT बनाम ऑब्जेक्ट्स " को यहां कई बार पूछा गया है। एक-पंक्ति का उत्तर है "ADTs और ऑब्जेक्ट एक-दूसरे के व्युत्क्रम हैं - एक अमूर्त क्या अन्य बड़े करीने से नहीं कर सकता है? प्रत्येक अलग-अलग तरीकों से लचीलेपन की अनुमति देता है।"
लंबे समय तक जवाब के लिए, विलियम कुक के अंडरस्टैंडिंग डेटा एब्सट्रैक्शन, रिविसिटेड देखें । संक्षेप में, ऑब्जेक्ट आपको आसानी से कुछ डेटम के कई कार्यान्वयन / प्रतिनिधित्व का उपयोग करने की अनुमति देते हैं (कुछ ऐसा जो सूची की तरह दिखता है एक सरणी, या एक आत्म-संतुलन वाला पेड़, या ...) हो सकता है, लेकिन नए संचालन को जोड़ना मुश्किल है (क्योंकि आप उस नए ऑपरेशन को आपके प्रत्येक निरूपण में जोड़ना होगा), जबकि ADT आपके डेटा प्रकार पर नए संचालन को जोड़ना आसान बनाते हैं, लेकिन कई क्रियान्वयन करना कठिन बनाते हैं।
संपादित करें: मैंने कहा था कि संदेश पास करना OO को सफल बनाता था। जोनास की टिप्पणी के आधार पर, यह सही नहीं है, क्योंकि ज्यादातर लोग जिन्हें ओओ मानते हैं, वे संदेश पारित करने का उपयोग नहीं करते हैं। चूंकि यह सही नहीं है, मैंने इसे अपने उत्तर से हटा दिया।
मेरी शीर्ष तीन विशेषताएं। वस्तु रचना - वस्तुओं को सहयोग करने की अनुमति देना। बहुरूपता - रनटाइम पर गतिशील व्यवहार का समर्थन करता है। वंशानुक्रम - कोड का पुन: उपयोग करके और तरीकों को ओवरराइड करने के माध्यम से व्यवहार को संशोधित करना।
ADT - आप पास्कल जैसी गैर-वस्तु-उन्मुख भाषाओं में भी हो सकते हैं। एक ढेर या कतार ADT के उदाहरण हैं।
सरल शब्दों में ओओपी पुन: प्रयोज्य और इनकैप्सुलेशन के लिए महत्वपूर्ण है जिसके परिणामस्वरूप बड़े फ्रेमवर्क का उत्पादन होता है जो इस युग में प्रोग्रामर के लिए जीवन को आसान बनाता है क्योंकि केवल एपीआई को कॉल कर सकते हैं और वह कर सकते हैं जो सबसे अधिक बार चाहते हैं।
जैसा कि उर प्रश्न OOP की 4 विशेषताओं के बारे में है, इसलिए आप कह सकते हैं
इसलिए 1. संदेश पासिंग और 3. बहुरूपता वास्तव में समर्थन कर रहे हैं 2. विरासत और 4. एनकैप्सुलेशन।
मेरी राय में, आखिरी तीन विशेषताएं एक बार सबसे महत्वपूर्ण हैं जो OOP के व्यापक प्रसार प्रभाव को प्रभावित करती हैं:
2. Inheritance
3. Polymorphism
4. Encapsulation
संपादित करें: एक और बिंदु दृश्य स्टूडियो और ग्रहण की तरह आईडीई और चित्रमय इंटरफ़ेस विकास वातावरण होगा। जैसे ही वे ओओपी भाषाओं को अपनाते हैं, इस प्रकार अधिक से अधिक डिजाइन ओओपी की ओर बढ़ जाते हैं।
और निश्चित रूप से ठोस सिद्धांत एक बार सॉफ्टवेयर उत्पादों को बनाने के लिए ठोस वितरित कर रहे हैं :)