ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग के विकास के पीछे क्या सोच थी?

Question

मुझे अपने हाथों पर कुछ वास्तविक नाय-क्यूरर्स मिल गए हैं, और मैं उन्हें कारण देने की कोशिश कर रहा हूं कि ओओपी पहले स्थान पर क्यों विकसित हुआ था। मुझे लगता है कि OOP सभी समस्याओं और परिस्थितियों के लिए सही नहीं है, लेकिन यह एक कारण के लिए विकसित किया गया था ...

मेरा अनुमान हो सकता है, कि उन कारणों में से कुछ होगा:

• अनुरक्षणीयता
• पुन: प्रयोज्य
• दस्तावेज़-क्षमता
• परिसर टेक्नोलॉजीज
• गतिशील क्रम में विस्तार की अमूर्त ...
• शायद कुछ चीजें जिनके बारे में मुझे अभी तक पता नहीं है ...

लेकिन मुझे वास्तव में इसका समर्थन करने के लिए बहुत कुछ नहीं है, और मैं सोच रहा था कि ओओपी पहले स्थान पर क्यों विकसित हुआ था, और यह इतिहास।

ओओपी विकसित करने की कोशिश कर रहे लोगों को क्या विकसित किया गया था? उन्हें ओओपी विकसित करने का क्या कारण था?

Answer 1

मैं हमेशा की राय है कि प्रोग्रामिंग उन्मुख वस्तु इतनी है कि हम तरीकों से जटिल समस्याओं के बारे में सोच सकता है बनाया गया था मनुष्य कि समझ सकते हैं आयोजित किया है:

दुनिया में सब कुछ एक वस्तु है, वस्तुओं गुण होते हैं, और कुछ वस्तुएं भी क्रियाएं कर सकती हैं (या उन पर किए गए कार्यों को)।

Answer 2

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

Answer 3

इसके लिए एक अच्छी किताब Object-Oriented Software Construction है बर्ट्रेंड मेयर द्वारा (व्यापक रूप से ऑब्जेक्ट उन्मुख प्रोग्रामिंग का एक आधारभूत पाठ माना जाता है)। विकिपीडिया पृष्ठ से:

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

Answer 4

पॉल ग्राहम कारणों में से एक अच्छा सूची है क्यों OOP जैसे लोगों:

http://www.paulgraham.com/noop.html

Answer 5

मुझे लगता है कि क्या पहली जगह में OOP motived इन तथ्यों (या मैं मान्यताओं कहना चाहिए रहे हैं?):

• हम स्वाभाविक रूप से वस्तुओं/चीजों की अवधि में लगता है
• वस्तुओं पर कब्जा करने के अच्छे हैं/मॉडल वास्तविकता
• वस्तुओं देव भर में समान रूप से इस्तेमाल किया जा सकता है। प्रक्रिया (आवश्यकता, विश्लेषण, कार्यान्वयन)

चाहे यह वास्तव में सच है, एक और सवाल है। Do We Think in Terms of Objects देखें।

OOP का सार

• वस्तु = पहचान + डेटा + व्यवहार

क्या सटीक OOP भाषा में उपलब्ध कराई गई सुविधाओं रहे हैं भी एक और सवाल है। wikipedia page देखें।

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

Answer 6

सिद्धांत एक तरफ, ओओपीएस को गोद लेने के लिए वास्तव में क्या किया गया था, विंडोज आधारित जीयूआई का आगमन था।

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

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

OOP की गोद लेने के बेहद OOP के रूप में इस सरल जीयूआई के लिए एक प्राकृतिक फिट है। आजकल हम इसे स्पष्ट और प्राकृतिक मानते हैं लेकिन यह हमेशा ऐसा नहीं था और निश्चित रूप से ओओपी को गोद लेने के समय प्रोग्रामर को एक बड़ी चुनौती माना जाता था। हालांकि नतीजा यह हुआ है कि 90 के उत्तरार्ध के बाद से सभी नए प्रोग्रामर ओओपी के साथ बड़े हो गए हैं क्योंकि परिणामस्वरूप जीयूआई को संभालने के लिए वास्तव में इसकी आवश्यकता है कि यह कोड के लिए डिफ़ॉल्ट तरीका है और इसके परिणामस्वरूप इसका उपयोग इंटरफ़ेस से व्यापक रूप से फैल गया है।

Answer 7

एलन के, जिसने "ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग" शब्द बनाया है, कुछ मौकों पर explained his thinking है।

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