क्या OOP कठिन है क्योंकि यह प्राकृतिक नहीं है?

Question

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

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

हम द्विभाजक के रूप में सोचते हैं (कभी-कभी ट्रिटेंट के रूप में, उदाहरण के लिए, "मैंने आपको फूल दिए") क्रिया जहां क्रिया एक क्रिया (संबंध) है जो कुछ परिणाम / कार्रवाई का उत्पादन करने के लिए दो वस्तुओं पर काम करती है। फोकस कार्रवाई पर है, और दो (या तीन) [व्याकरण] वस्तुओं को समान महत्व है।

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

न केवल संज्ञाओं पर ध्यान केंद्रित किया जाता है, बल्कि संज्ञाओं में से एक (इसे व्याकरणिक विषय कहते हैं) को अन्य (व्याकरणिक वस्तु) की तुलना में अधिक "महत्व" दिया जाता है। इस प्रकार किसी को टर्मिनलविंडो.शो (someText) या someText.show (terminalWindow) कहेंगे। लेकिन ऐसे तुच्छ निर्णयों के साथ लोगों पर कोई परिचालन परिणाम क्यों नहीं होता है, जब वास्तव में शो का मतलब होता है (टर्मिनलविंडो, someText)? [परिणाम ऑपरेशनल रूप से महत्वहीन हैं - दोनों ही मामलों में टेक्स्ट को टर्मिनल विंडो पर दिखाया गया है - लेकिन क्लास पदानुक्रम के डिजाइन में बहुत गंभीर हो सकता है और "गलत" विकल्प कोड को बनाए रखने के लिए जटिल और कठिन हो सकता है।]

इसलिए मैं तर्क दूंगा कि OOP (वर्ग-आधारित, एकल-प्रेषण) करने का मुख्य मार्ग कठिन है क्योंकि यह UNNATURAL है और यह इस बात से मेल नहीं खाता कि मनुष्य दुनिया के बारे में कैसे सोचते हैं। CLOS से सामान्य तरीके मेरे सोचने के तरीके के करीब हैं, लेकिन, अफसोस, यह व्यापक दृष्टिकोण नहीं है।

इन समस्याओं को देखते हुए, यह कैसे / क्यों हुआ कि OOP करने का वर्तमान मुख्यधारा का तरीका इतना लोकप्रिय हो गया? और क्या, अगर कुछ भी हो, तो इसका पता लगाने के लिए क्या किया जा सकता है?

Comments

OOP 'प्रोग्रामिंग' के लिए है, यह कंपाइलरों को आनंद लेने के लिए बनाया गया है। यह किसी भी तरह से वास्तविक दुनिया को मॉडल करने का एक तरीका नहीं है। OOP पढ़ाने के दौरान पशु वर्ग और आयत वर्ग जैसे वास्तविक दुनिया उदाहरणों का उपयोग करना आम है, लेकिन ये अवधारणा को सरल बनाने के लिए केवल उदाहरण हैं। दुर्भाग्य से, प्रोग्रामिंग भाषा और प्रतिमान गैर-विकासवादी और गैर-वैज्ञानिक फैशन में 'होते हैं'। कुछ अपवादों के साथ, भाषा डिजाइन प्रक्रिया आमतौर पर कुछ लोगों के सर्वोत्तम अनुमान का बच्चा होती है!

— NoChance

मैं इस दावे से असहमत हूं "OOP का ध्यान व्यक्तिगत कक्षाओं और उनके पदानुक्रमों को डिजाइन कर रहा है।" चूंकि मेबी यह ओओपी के एक निश्चित कार्यान्वयन (एस) का फोकस है, लेकिन मैंने उदाहरण के लिए पाया है कि गतिशील ओओपी भाषाओं में आमतौर पर बड़ी पदानुक्रम, या यहां तक ​​कि कक्षाएं नहीं होती हैं। खैर, OOP की परिभाषा भविष्य में बदल सकती है, वस्तु को भी बदलने की कोशिश है। wcook.blogspot.com/2012/07/proposal-for-simplified-modern.html

— Azder

ओओपी सिस्टम में वस्तुओं की पहचान कर रहा है और उन वस्तुओं के आधार पर कक्षाओं का निर्माण कर रहा है। कोई और रास्ता नही। यही कारण है कि मैं "ओओपी का ध्यान व्यक्तिगत कक्षाओं और उनके पदानुक्रमों को डिजाइन कर रहा हूं" से भी असहमत हूं।

— राडू मुरज़िया

डुप्लिकेट: क्या ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग वास्तव में वास्तविक दुनिया का मॉडल है?

— १२:०२ पर gnat

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

— साइमन लेहमन

Answer 1

OOP कुछ समस्याओं के लिए अप्राकृतिक है। तो प्रक्रियात्मक है। इतना कार्यात्मक। मुझे लगता है कि ओओपी में दो समस्याएं हैं जो वास्तव में कठिन लगती हैं।

1. कुछ लोगों को यह पसंद है कि यह कार्यक्रम के लिए एक सच्चा तरीका है और अन्य सभी प्रतिमान गलत हैं। IMHO हर किसी को एक बहु-भाषी भाषा का उपयोग करना चाहिए और उपप्रोम्बल के लिए सबसे अच्छा प्रतिमान चुना जो वे वर्तमान में काम कर रहे हैं। आपके कोड के कुछ हिस्सों में एक OO शैली होगी। कुछ कार्यशील होंगे। कुछ की सीधी प्रक्रियात्मक शैली होगी। अनुभव के साथ यह स्पष्ट हो जाता है कि किस प्रतिमान के लिए सबसे अच्छा है:

   ए। जब आप व्यवहार करते हैं, तो OO आम तौर पर सबसे अच्छा होता है, जिस स्थिति में वे संचालित होते हैं, और राज्य की सटीक प्रकृति एक कार्यान्वयन विवरण है, लेकिन इसका अस्तित्व आसानी से दूर नहीं किया जा सकता है। उदाहरण: संग्रह कक्षाएं।

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

   सी। कार्यात्मक सबसे अच्छा है जब आपके पास कुछ ऐसा हो जो घोषणात्मक रूप से लिखना काफी आसान हो, जैसे कि किसी भी राज्य का अस्तित्व एक कार्यान्वयन विवरण है जिसे आसानी से अमूर्त किया जा सकता है। उदाहरण: मानचित्र / समानता को कम करना।

2. ओओपी आमतौर पर बड़ी परियोजनाओं पर अपनी उपयोगिता दिखाता है जहां कोड के अच्छी तरह से समझाया टुकड़े होना आवश्यक है। शुरुआती परियोजनाओं में यह बहुत अधिक नहीं होता है।

Comments

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

— जियोर्जियो

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

— जियोर्जियो

OOP वास्तव में एक अलग अक्ष पर प्रक्रियात्मक / कार्यात्मक है; यह कोड को व्यवस्थित करने और इनकैप करने के तरीके से निपटता है, न कि संचालन का वर्णन कैसे करें। (आप हमेशा एक निष्पादन प्रतिमान के साथ ओओपी के साथी होते हैं। हां, ओओपी + कार्यात्मक भाषाएं हैं।)

— डोनल फैलो

क्या यह नहीं कहा जा सकता है कि OOP सिर्फ वे बक्से हैं जिन्हें हमने प्रक्रियात्मक सामान में रखा है?

— एरिक रेपेन

OOP में, आप अभी भी विधियाँ लिख सकते हैं। प्रक्रियात्मक प्रोग्रामिंग की तुलना में OOP कमजोर क्या है?

— मर्ट अक्काया

Answer 2

IMHO यह व्यक्तिगत स्वाद और सोचने के तरीकों का सवाल है। मुझे OO से कोई समस्या नहीं है।

हम (या कम से कम I) हमारे द्वारा सामना की जाने वाली चीजों के बीच संबंधों के संदर्भ में दुनिया की अवधारणा करते हैं, लेकिन OOP का ध्यान व्यक्तिगत कक्षाओं और उनके पदानुक्रमों को डिजाइन कर रहा है।

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

ध्यान दें, रोजमर्रा की जिंदगी में, रिश्ते और कार्य ज्यादातर उन वस्तुओं के बीच मौजूद होते हैं जो OOP में असंबंधित वर्गों के उदाहरण होते थे।

यदि वस्तुओं के बीच कोई संबंध है, तो वे संबंधित हैं, प्रति परिभाषा। OO में आप इसे दो वर्गों के बीच संबंध / एकत्रीकरण / उपयोग निर्भरता के साथ व्यक्त कर सकते हैं।

हम द्विभाजक के रूप में सोचते हैं (कभी-कभी ट्रिटेंट के रूप में, उदाहरण के लिए, "मैंने आपको फूल दिए") क्रिया जहां क्रिया एक क्रिया (संबंध) है जो कुछ परिणाम / कार्रवाई का उत्पादन करने के लिए दो वस्तुओं पर काम करती है। ध्यान क्रिया पर है, और दो (या तीन) [व्याकरणिक] वस्तुओं का समान महत्व है।

लेकिन उनके पास अभी भी संदर्भ में उनकी अच्छी तरह से परिभाषित भूमिकाएं हैं: विषय, वस्तु, क्रिया आदि "मैंने आपको फूल दिए हैं" या "आपने मुझे फूल दिए" समान नहीं हैं ("फूल ने आपको मुझे दिया" का उल्लेख नहीं किया गया है:) -)

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

मैं इससे असहमत हूं। आईएमएचओ अंग्रेजी वाक्य "बिल, गो टू हेल" के bill.moveTo(hell)बजाय कोड में स्वाभाविक रूप से अधिक पढ़ें move(bill, hell)। और पूर्व वास्तव में मूल सक्रिय आवाज के लिए अधिक अनुरूप है।

इस प्रकार किसी को यह तय करना होगा कि कोई टर्मिनलविंडो .show (someText) या someText.show (टर्मिनेटो) कहेगा या नहीं

फिर से, टर्मिनल को कुछ पाठ दिखाने के लिए पूछना या पाठ को टर्मिनल दिखाने के लिए पूछना समान नहीं है। IMHO यह बहुत स्पष्ट है जो एक और अधिक प्राकृतिक है।

इन समस्याओं को देखते हुए, यह कैसे / क्यों हुआ कि OOP करने का वर्तमान मुख्यधारा का तरीका इतना लोकप्रिय हो गया?

शायद इसलिए कि OO डेवलपर्स के बहुमत OO को आपसे अलग तरह से देखते हैं?

Comments

+1 सीधे वस्तुओं और उनके महत्व के बीच एलन का से संदेश का उल्लेख करने के लिए

— bunglestink

@zvrba, वास्तव में, अन्य OO पायनियर भी थे, लेकिन इस चर्चा के बिंदु के बगल में है। "सबसे स्वाभाविक बात यह है कि पाठ को दिखाया जाना चाहिए।" - अब आप उसी निष्क्रिय आवाज का उपयोग कर रहे हैं जिसका आपने दावा किया है कि ओओपी में "अप्राकृतिक" है।

— पेटर तोर्क

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

— पीटर टॉरक

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

— पेर्ट टॉरक

@zvrba, एक कार वास्तव में अपनी मर्जी से शुरू नहीं होती है - सिर्फ एक Carवस्तु के रूप में, start()जब इसकी विधि किसी ने स्पष्ट रूप से बताई हो ।

— पेर्ट टॉरक

Answer 3

कुछ प्रोग्रामर OOD को कठिन पाते हैं क्योंकि वे प्रोग्रामर यह सोचना पसंद करते हैं कि कंप्यूटर के लिए समस्या को कैसे हल किया जाए, इस बारे में नहीं कि समस्या को कैसे हल किया जाए।

... लेकिन OOP का ध्यान व्यक्तिगत कक्षाओं और उनके पदानुक्रमों को डिजाइन करना है।

OOD इसके बारे में नहीं है। OOD यह पता लगाने के बारे में है कि चीजें कैसे व्यवहार करती हैं और बातचीत करती हैं।

हम द्विभाजक के रूप में सोचते हैं (कभी-कभी ट्रिटेंट के रूप में, उदाहरण के लिए, "मैंने आपको फूल दिए") क्रिया जहां क्रिया एक क्रिया (संबंध) है जो कुछ परिणाम / कार्रवाई का उत्पादन करने के लिए दो वस्तुओं पर काम करती है। ध्यान क्रिया पर है, और दो (या तीन) [व्याकरणिक] वस्तुओं का समान महत्व है।

OOD पर ध्यान हमेशा कार्रवाई पर होता है, जहां क्रियाएं वस्तुओं का व्यवहार होती हैं। वस्तुएं उनके व्यवहार के बिना कुछ भी नहीं हैं। OOD की एकमात्र वस्तु बाधा यह है कि सब कुछ के द्वारा किया जाना है।

मैं कर्ता को अधिक महत्वपूर्ण नहीं देखता, फिर वह चीज जो उसके लिए की जाती है।

लेकिन ऐसे तुच्छ निर्णयों वाले लोगों पर कोई परिचालनात्मक परिणाम क्यों नहीं होता है जब वास्तव में इसका मतलब होता है शो (टर्मिनलविंडो, someText)?

मेरे लिए एक अलग संकेतन के साथ एक ही बात है। आपको अभी भी यह तय करना है कि शो-एर कौन है और शो-ई कौन है। एक बार जब आप यह जान लेते हैं, तो ओओडी में कोई निर्णय नहीं है। विंडोज शो टेक्स्ट -> Window.Show (टेक्स्ट)।

वहाँ बहुत सारा सामान (विशेषकर विरासत क्षेत्र में) यह OO है जब ऐसा नहीं है। उदाहरण के लिए C ++ कोड की एक बड़ी मात्रा है जो OOD के एक अंजीर को लागू नहीं करता है।

ओओडी आसान है एक बार जब आप मानसिकता से बाहर निकल जाते हैं तो आप कंप्यूटर के लिए एक समस्या हल कर रहे हैं। आप सामान रखने वाली चीजों के लिए समस्याओं को हल कर रहे हैं।

Comments

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

— तर्क

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

— एसके-तर्क

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

— एसके-तर्क

@ एंटोनियो2011 ए, कोई एकल प्रोग्रामिंग या मॉडलिंग प्रतिमान नहीं है जो सभी संभावित समस्या डोमेन को कुशलतापूर्वक कवर कर सकता है। OOP, फ़ंक्शनल, डेटाफ़्लो, फ़र्स्ट-ऑर्डर लॉजिक, जो भी हो - वे सभी समस्या डोमेन-विशिष्ट प्रतिमान हैं और इससे अधिक कुछ नहीं। मैं केवल समस्या को हल करने के लिए विविधता और खुले दिमाग वाले दृष्टिकोण की वकालत कर रहा हूं। एक एकल प्रतिमान के लिए अपनी सोच को कम करना सिर्फ बेवकूफी है। एक सार्वभौमिक दृष्टिकोण के लिए निकटतम बात, आपको एक शब्दार्थिक ढांचे तक सीमित नहीं करना है, en.wikipedia.org/wiki/Language-oriented_programming

— SK-Logic

@Calmarius आप कंप्यूटर के लिए प्रोग्रामिंग को आसान क्यों बनाएंगे? वह मूर्खतापूर्ण है। यह मनुष्य को कठिन परिश्रम करना है।

— मैट एलेन

Answer 4

हो सकता है, मैं बात करने में सक्षम नहीं हूँ, लेकिन:

ओओपी पर पहली पुस्तक (90 के दशक की शुरुआत में, बोरलैंड की पास्कल के लिए पतली पुस्तिका) को पढ़ना मैं बस अपनी सादगी और क्षमता से चकित था। (इससे पहले, मैं कोबोल, फोरट्रान, असेंबली भाषा और अन्य प्रागैतिहासिक सामान का उपयोग कर रहा था।)

मेरे लिए, यह बहुत स्पष्ट है: एक कुत्ता एक जानवर है, एक जानवर को खाना चाहिए, मेरा कुत्ता एक कुत्ता है, इसलिए इसे खाना चाहिए ...

दूसरी तरफ, प्रोग्रामिंग स्वयं स्वाभाविक रूप से अप्राकृतिक (यानी कृत्रिम) है। मानव भाषण कृत्रिम है (मुझे दोष न दें, हम सभी ने दूसरों से हमारी भाषाएं सीखी हैं, अंग्रेजी जानने वाले व्यक्ति को कोई नहीं जानता है), भी। कुछ वैज्ञानिकों के अनुसार, मानव का दिमाग उस भाषा से बनता है जिसे उसने पहले सीखा है।

मैं मानता हूं, आधुनिक ओओ-भाषाओं में कुछ निर्माण थोड़ा अजीब हैं, लेकिन यह विकासवाद है।

Comments

कोबोल से फोरट्रान, फिर असेंबली (और बाकी) में जाने के लिए आपके लिए वास्तव में क्या काम था?

— रूक

गलत आदेश। वास्तव में, मैं बेसिक से शुरू कर रहा हूं, फिर फोरट्रान और फिर असेंबली और कोबोल चले गए (हां, यह सही क्रम है: असेंबली फर्स्ट)। मेरे जीवन का पहला कंप्यूटर एक "विशाल" मेनफ्रेम, 256kB मेमोरी का था, इसके कंसोल को टाइपराइटर, इसे पंच कार्ड के साथ फीड करना, क्योंकि मैं इसका ऑपरेटर था। जब मैं एक सिस्टम प्रोग्रामर बनने के लिए पर्याप्त बढ़ गया था, तो पीसी-एटी नामक एक संदिग्ध चीज मेरे डेस्क पर आ गई थी। इसलिए मैंने जीडब्ल्यू-बेसिक, टर्बो-पास्कल, ... इत्यादि में डुबकी लगाई थी।

— नेरवर

मैं उस पर भरोसा नहीं कर रहा था। आपके नौकरी के लिए अधिक डोमेन; कारण मैं कई लोगों (किसी को भी वास्तव में) को नहीं जानता, जो COBOL (व्यवसाय उन्मुख), फोरट्रान (वैज्ञानिक डोमेन), कोडांतरक (अधिक सीएस उन्मुख) और फिर उन अन्य लोगों से निपटते हैं। फिर भी वे पेशेवर प्रोग्रामर हैं या नहीं।

— रूक

कोई रहस्य नहीं: टीमों और परियोजनाओं में शामिल होना जहां लैगेज दृष्टिकोण पर निर्णय पहले किया गया था। और कुछ गैर-तुच्छ स्तर की जिज्ञासा के उपकरण जो वे उपयोग कर रहे थे।

— नेरवर

Answer 5

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

तब मैंने SICP को पढ़ा और एक नई समझ में आया कि यह वास्तव में डेटा प्रकारों और उन तक पहुंच को नियंत्रित करने के बारे में था। सभी समस्याएं मैंने दूर कर दी थीं क्योंकि वे एक झूठे आधार पर आधारित थे, कि ओओपी में आप दुनिया की मॉडलिंग कर रहे हैं।

मैं अभी भी बहुत मुश्किल है कि इस झूठे आधार ने मुझे अचंभित कर दिया (और कैसे मैंने अपने आप को इसे देखने दिया)।

Comments

दुनिया को मॉडल बनाने की कोशिश के खतरे को इंगित करने के लिए धन्यवाद।

— सीन मैकमिलन

Answer 6

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

Comments

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

— पेटर तोर्क

@ Péter Török, बिल्कुल मेरी बात। एक भी औपचारिकता नहीं है जो सब कुछ कवर करती है। आपको उन सभी का उपयोग करना होगा, उनकी सभी डरावनी भीड़ में। और यही कारण है कि मैं एक भाषा-उन्मुख प्रोग्रामिंग में विश्वास करता हूं - यह एक ठोस कोड इकाई में विभिन्न, अक्सर असंगत औपचारिकताओं को अपनाने की अनुमति देता है।

— तर्क

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

— कालेब

"श्रेणीबद्ध वर्गीकरण" जैसे शब्द का उपयोग करके, मुझे लगता है कि आप सोच रहे हैं, ठीक है, विरासत। वंशानुक्रम वास्तव में तर्क के लिए कठिन है। यही कारण है कि लोग विरासत पर रचना का उपयोग करने का सुझाव देते हैं।

— फ्रैंक शीयर

@ फ्रेंक: वास्तविक दुनिया में कई प्रकार के पदानुक्रमित टैक्सोनॉमी हैं, जिनमें से विरासत केवल एक है। इस सब को ठीक से करने के लिए OOP (जैसे, ऑन्कोलॉजिकल रीजनिंग) की तुलना में बेहतर टूल की आवश्यकता होती है और इससे सहस्राब्दी के

— डोनल फैलो

Answer 7

हम (या कम से कम I) हमारे द्वारा सामना की जाने वाली चीजों के बीच संबंधों के संदर्भ में दुनिया की अवधारणा करते हैं, लेकिन OOP का ध्यान व्यक्तिगत कक्षाओं और उनके पदानुक्रमों को डिजाइन कर रहा है।

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

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

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

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

Answer 8

यह OOP के साथ गलत क्या है का केवल एक हिस्सा है।

अनिवार्य रूप से, फ़ंक्शन द्वितीय श्रेणी के नागरिक बन जाते हैं, और यह खराब है।

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

Comments

OOP मुझे बहुत स्वाभाविक लगता है, वास्तव में प्रोग्रामिंग कार्यों के बारे में किसी अन्य तरीके से सोचना मेरे लिए कठिन है। फिर भी, वर्षों से मुझे यह समझ में आया है कि OOP क्रियाओं के ऊपर संज्ञाओं को समाप्त कर देता है। 2006 से इस शेख़ी ने मुझे इस भेद को समझने में मदद की: स्टीवे-yegge.blogspot.com/2006/03/…

— जिम इन टेक्सास

Answer 9

OOP कठिन नहीं है। क्या यह अच्छी तरह से उपयोग करने के लिए मुश्किल बनाता है यह एक अच्छी समझ है कि यह किसके लिए अच्छा है, जहां प्रोग्रामर यादृच्छिक मैक्सिमम सुनते हैं, और चार सांसों के दिव्य गिरोह, धन्य मार्टिन फाउलर, या का आशीर्वाद प्राप्त करने के लिए अपनी सांस के तहत खुद को दोहराते हैं। जो भी वे पढ़ते रहे हैं।

Answer 10

संपादित

सबसे पहले मैं यह कहना चाहूंगा कि मुझे ओओपी कठिन या अन्य प्रोग्रामिंग प्रतिमानों की तुलना में कठिन नहीं लगा। प्रोग्रामिंग स्वाभाविक रूप से कठिन है क्योंकि यह वास्तविक दुनिया से समस्याओं को हल करने की कोशिश करता है और वास्तविक दुनिया बेहद जटिल है। दूसरी ओर, जब मैंने यह प्रश्न पढ़ा तो मैंने खुद से पूछा: क्या OOP अन्य प्रतिमानों की तुलना में "अधिक स्वाभाविक" है? और इसलिए अधिक प्रभावी?

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

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

मैंने मुख्य रूप से ओओपी भाषाओं (सी ++, जावा) के साथ काम किया है, लेकिन मुझे अक्सर यह महसूस होता है कि मैं पास्कल या एडा का उपयोग कर के रूप में उत्पादक हो सकता हूं, भले ही मैंने उन्हें बड़ी परियोजनाओं के लिए कभी कोशिश नहीं की।

विरोध करें कि OOP के साथ जहां आपको पहली बार एक ऑब्जेक्ट (संज्ञा) ढूंढनी है और इसे किसी अन्य ऑब्जेक्ट पर कुछ कार्रवाई करने के लिए कहें।

[कट गया]

इसलिए मैं तर्क दूंगा कि OOP (वर्ग-आधारित, एकल-प्रेषण) करने का मुख्य मार्ग कठिन है क्योंकि यह UNNATURAL है और यह इस बात से मेल नहीं खाता कि मनुष्य दुनिया के बारे में कैसे सोचते हैं। CLOS से सामान्य तरीके मेरे सोचने के तरीके के करीब हैं, लेकिन, अफसोस, यह व्यापक दृष्टिकोण नहीं है।

जब मैंने इस अंतिम पैराग्राफ को और अधिक ध्यान से पढ़ा तो मुझे अंत में आपके प्रश्न का मुख्य बिंदु समझ में आया और मुझे अपने उत्तर को स्क्रैच से दोबारा लिखना पड़ा। :-)

मुझे अन्य OO प्रस्तावों के बारे में पता है, जहां कई वस्तुओं को केवल एक के बजाय एक संदेश प्राप्त होता है, अर्थात संदेश प्राप्त करते समय कई ऑब्जेक्ट एक सममित भूमिका निभाते हैं। हाँ, यह मेरे लिए एक अधिक सामान्य और शायद अधिक प्राकृतिक (कम प्रतिबंधात्मक) OOP दृष्टिकोण लगता है।

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

Answer 11

विशेष रूप से OOP प्रतिमान की तलाश करना बंद करें और कुछ जावास्क्रिप्ट पर प्रयास करें।

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

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

लेकिन मैं अकेले OOP के साथ ऐसा नहीं कर रहा हूँ और JS कुछ परिभाषाओं द्वारा OOP को 'ठीक से' भी नहीं कर रहा है, जो मुझे प्रफुल्लित करने वाला लगता है। मेरी राय में ऐप के विकास के उच्च स्तर के लिए उचित, आपकी स्थिति के लिए जो भी काम करता है, उसके प्रतिमान को मोड़ने की शक्ति है और यदि हम परवाह करते हैं तो हम कक्षाओं का ठीक-ठीक अनुकरण कर सकते हैं। लेकिन इस मामले में, मैं OOP के साथ कार्यात्मक (पास हैंडलर पास) के पहलुओं को मिला रहा हूं।

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

इसलिए मुझे लगता है कि मैं जो कह रहा हूं वह यह है: यह एक स्विच स्टेटमेंट की तरह की समस्या नहीं है। यह मिक्स एंड मैच है। समस्या यह है कि आप चाहते हैं कि यह विश्वास करने वाली भाषाएं और फैड्स हैं, जो एक चीज है। उदाहरण के लिए, एक जूनियर जावा देव वास्तव में OOP की सराहना कैसे कर सकते हैं, जब उन्हें लगता है कि वे हमेशा डिफ़ॉल्ट रूप से ठीक से कर रहे हैं?

Answer 12

जिस तरह से मुझे समझाया गया था वह टोस्टर और कार के साथ था। दोनों में स्प्रिंग्स होते हैं, इसलिए आपके पास एक "स्प्रिंग" ऑब्जेक्ट होगा और वे अलग-अलग आकार, ताकत और जो भी होंगे, लेकिन वे दोनों "स्प्रिंग्स" होंगे और फिर उस रूपक को कार पर बढ़ाते हुए, क्या आपके पास बहुत सारे पहिए थे (पहियों, जाहिर है, प्लस स्टीयरिंग व्हील, ect) और इससे बहुत कुछ समझ में आया।

आप तब प्रोग्राम को वस्तुओं की एक सूची के रूप में सोच सकते हैं, और यह कल्पना करना बहुत सरल है "फिर यह उन चीजों की सूची है जो सामान करते हैं, इसलिए यह उन निर्देशों की सूची जैसा नहीं है जिन्हें आपने पहले देखा था"

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

Comments

स्प्रिंग्स लाखों रूपों में आते हैं, जिनमें से सभी समान कार्य करते हैं । मैं कहूंगा कि यह कार्यात्मक प्रोग्रामिंग के लिए एक आदर्श उदाहरण है।

— l0b0

Answer 13

यह वर्गीकरण के माध्यम से दुनिया के बारे में सोचने का स्वाभाविक तरीका है। ओओ के बारे में यह अधिक या कम है। OOP कठिन है क्योंकि प्रोग्रामिंग कठिन है।

Comments

लेकिन क्या आप इस हिसाब से वर्गीकृत करते हैं कि कुछ वस्तुओं में सामान्य विशेषताएं हैं या सामान्य व्यवहार हैं? क्या वह सब कुछ है, जिसमें किसी व्यक्ति का नाम और उपनाम है? क्या वह सब कुछ है जो एक जानवर चलता है?

— zvrba

जब वर्गीकरण की बात आती है, तो एक निश्चित व्यवहार करने में सक्षम होना एक विशेषता है। ज़ेब्रा और घोड़े प्रजनन कर सकते हैं, लेकिन संतान एक संकर है। जब तक आप जानते हैं कि वे एक ही प्रजाति नहीं हैं तब तक संभोग क्रिया के आधार पर इस परिणाम की भविष्यवाणी करना बहुत मुश्किल है।

— जेएफओ

@zvrba: टिप्पणी में प्रस्तुत प्रश्न का मेरा उत्तर है it doesn't matter। हर चीज का एक नाम और एक उपनाम होता है जो हर कार्यक्रम के लिए एक व्यक्ति होता है जो केवल लोगों की परवाह करता है। किसी भी कार्यक्रम के लिए जिसे लोगों या गैर-लोगों का कोई ज्ञान नहीं है, यह एक है IHasNameAndSurname। वस्तुओं को केवल समस्या को हल करने की आवश्यकता है।

— टॉम डब्ल्यूएपी

@ जेफ ओ भी एक ही प्रजाति / नस्ल / जनसंख्या के भीतर भिन्नता है और कोई आदर्श (आवश्यक) उदाहरण नहीं है। तो, हाँ OO वास्तव में प्रकृति के रूप में नहीं है, लेकिन यह एक अच्छा फिट है कि मनुष्य स्वाभाविक रूप से कैसे सोचते हैं।

— टॉम हैटिन -

Answer 14

मुझे लगता है कि कुछ कठिनाई तब होती है जब लोग वास्तविकता का प्रतिनिधित्व करने के लिए ओओपी का उपयोग करने की कोशिश करते हैं। हर कोई जानता है कि एक कार में चार पहिए और एक इंजन होता है। हर कोई जानता है कि कारें कर सकती हैं Start(), Move()और SoundHorn()।

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

Answer 15

जटिलता का प्रबंधन करने के लिए, हमें मॉड्यूल में समूह कार्यक्षमता की आवश्यकता होती है, और यह सामान्य रूप से एक कठिन समस्या है। यह पूंजीवाद के बारे में पुरानी कहावत की तरह है, OOP वहां से सॉफ्टवेयर को व्यवस्थित करने के लिए सबसे खराब व्यवस्था है, बाकी सब कुछ जो हमने कोशिश की है।

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

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

Comments

क्या आपने कभी उचित मॉड्यूल सिस्टम देखा है? आप कैसे कह सकते हैं कि OOP सबसे अच्छी चीज उपलब्ध है? SML मॉड्यूल बहुत अधिक शक्तिशाली होते हैं। लेकिन, यहां तक ​​कि एडीए पैकेज अधिकांश मामलों के लिए पर्याप्त हैं, यहां तक ​​कि ओओपी के एक छोटे संकेत के बिना भी।

— तर्क

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

— कार्ल बेवेलफेल्ट

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

— एसके-लॉजिक

"यह पूंजीवाद के बारे में पुरानी कहावत की तरह है, OOP सॉफ्टवेयर को व्यवस्थित करने के लिए सबसे खराब व्यवस्था है, इसके अलावा जो कुछ हमने कोशिश की है, उसे छोड़कर।": शायद हम लंबे समय से कोशिश नहीं कर रहे हैं। :-)

— जियोर्जियो

मुझे लगता है कि आप 'लोकतंत्र' का मतलब: quotationspage.com/quote/364.html

— nicodemus13

Answer 16

नहीं । प्रोग्रामिंग का उपयोग करके समस्याओं को हल करने के कई तरीके हैं: कार्यात्मक, प्रक्रियात्मक, तार्किक, ओओपी, अन्य।

वास्तविक दुनिया में, कभी-कभी, लोग कार्यात्मक प्रतिमान का उपयोग करते हैं, और कभी-कभी, हम प्रक्रियात्मक प्रतिमान का उपयोग करते हैं, और इसी तरह। और कभी-कभी हम मिला करते थे। और अंततः हम उन्हें एक विशेष शैली या प्रोग्रामिंग के प्रतिमान के रूप में दर्शाते हैं।

"सब कुछ एक सूची या एक आइटम" प्रतिमान भी है, जिसका उपयोग LISP में किया जाता है। मैं कार्यात्मक प्रोग्रामिंग से एक अलग चीज के रूप में उल्लेख करना पसंद करता हूं । PHP सहवर्ती सरणियों में इसका उपयोग करती है।

OOP और "सब कुछ एक सूची या आइटम है" प्रतिमानों को अधिक प्राकृतिक प्रोग्रामिंग शैलियों में से 2 माना जाता है , जैसा कि मुझे कुछ आर्टिफिशियल इंटेलिजेंस कक्षाओं में याद है।

मेरे लिए अजीब लगता है, "OOP प्राकृतिक नहीं है", हो सकता है कि जिस तरह से आप सीखते हैं, या जिस तरह से आपको OOP के बारे में सिखाया गया है वह गलत है, लेकिन खुद OOP नहीं।

Answer 17

इन समस्याओं को देखते हुए, यह कैसे / क्यों हुआ कि OOP करने का वर्तमान मुख्यधारा का तरीका इतना लोकप्रिय हो गया? और क्या, अगर कुछ भी हो, तो इसका पता लगाने के लिए क्या किया जा सकता है?

OOP लोकप्रिय हो गया क्योंकि यह आपके प्रोग्राम को व्यवस्थित करने के लिए उच्च स्तर पर अमूर्त स्तर पर लोकप्रिय प्रक्रियात्मक भाषाओं की तुलना में इसे प्रस्तुत करने के लिए उपकरण प्रदान करता है। ऐसी भाषा बनाना भी अपेक्षाकृत आसान था, जिसमें विधियों के अंदर प्रक्रियात्मक संरचना थी, और उनके आसपास की वस्तु-उन्मुख संरचना थी। इस प्रोग्रामर को जो पहले से ही जानते थे कि प्रक्रियात्मक रूप से ओओ सिद्धांतों को एक समय में कैसे लेना है। इससे बहुत सारे OO-in-name-only प्रोग्राम हुए, जो एक या दो कक्षा के अंदर लिपटे हुए प्रक्रियात्मक कार्यक्रम थे।

OO को अलग करने के लिए, एक ऐसी भाषा का निर्माण करें, जो आज के अधिकांश प्रोग्रामर से जानकर आसानी से संक्रमण करना आसान बना दे (ज्यादातर प्रक्रियात्मक, थोड़ा OO के साथ), अपने पसंदीदा प्रतिमान के लिए। सुनिश्चित करें कि यह सामान्य कार्य करने के लिए सुविधाजनक एपीआई प्रदान करता है, और इसे अच्छी तरह से बढ़ावा देता है। लोग जल्द ही आपकी भाषा में X-in-name-only प्रोग्राम बना रहे हैं। फिर आप यह उम्मीद कर सकते हैं कि लोगों को वास्तव में एक्स करने में अच्छा होने में वर्षों और साल लगेंगे।

Comments

ओपी का तर्क नहीं है कि ओओ सामान्य रूप से खराब है और उसे अलग किया जाना चाहिए लेकिन "ओओपी करने का वर्तमान मुख्यधारा का तरीका" सबसे स्वाभाविक एक नहीं है ("कई प्रेषण" की तुलना में)।

— जियोर्जियो

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

— शॉन मैकमिलन

Answer 18

मुझे लगता है कि OOP और OOP भाषाओं में भी समस्याएं हैं।

यदि इसे सही तरीके से समझें, तो OOP ब्लैक बॉक्स (ऑब्जेक्ट) के बारे में है, जिसमें उन पर पुश बटन होते हैं जिन्हें पुश किया जा सकता है (विधियाँ)। इन ब्लैक बॉक्स को व्यवस्थित करने में मदद के लिए कक्षाएं बस वहां हैं।

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

एक और बिंदु यह है कि कंप्यूटर केवल क्रमिक रूप से निर्देशों को निष्पादित करता है। मान लेते हैं कि आपके पास एक वस्तु है VCRऔर Televisionआप वीडियो कैसे खेलेंगे? आप शायद कुछ इस तरह लिखें:

connect(television, vcr);
vcr.turnOn();
television.turnOn();
insert(vcr, yourFavoriteCasette);
vcr.play();
while (vcr.isPlaying()) {} // Wait while the VCR is playing the casette.
vcr.eject();
vcr.turnOff();
television.turnOff();

यह यह सरल होगा, लेकिन इसके लिए आपको कम से कम 3 प्रोसेसर ( या प्रक्रियाएं ) की आवश्यकता होगी : एक आपकी भूमिका निभाता है, दूसरा वीसीआर है, तीसरा टीवी है। लेकिन आम तौर पर आपके पास केवल एक कोर होता है (कम से कम आपकी सभी वस्तुओं के लिए पर्याप्त नहीं)। कॉलेज में, मेरे बहुत से सहपाठियों को समझ नहीं आया कि जब पुश बटन एक महंगा ऑपरेशन करता है तो जीयूआई क्यों जमा करता है।

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

Answer 19

MVC पैटर्न के आविष्कारक द्वारा आविष्कार डीसीआई (डेटा, संदर्भ और इंटरैक्शन) पर एक नज़र डालें ।

DCI का लक्ष्य (विकिपीडिया से उद्धृत) है:

• दे दो प्रणाली व्यवहार प्रथम श्रेणी की स्थिति, ऊपर वस्तुओं (nouns)।
• तेजी से बदलते सिस्टम व्यवहार (सिस्टम क्या करता है) के लिए कोड को धीरे-धीरे अलग-अलग डोमेन ज्ञान (सिस्टम क्या है) के लिए साफ-साफ अलग-अलग करने के बजाय, दोनों को एक वर्ग इंटरफ़ेस में संयोजित करने के लिए।
• क्लास की सोच की बजाय लोगों की मानसिक प्रतिमानों के करीब रहने की एक वस्तु शैली का समर्थन करना।

यदि आप कुछ कोड देखना चाहते हैं, तो लेखकों द्वारा यहां एक अच्छा लेख दिया गया है और एक छोटा सा उदाहरण कार्यान्वयन (.NET) है । यह बहुत आसान है जितना यह लग सकता है, और बहुत स्वाभाविक लगता है।

Answer 20

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

जैसा कि यह किताबों और अन्यत्र दशकों से प्रचारित है, मैं इससे भी असहमत हूँ। फिर भी, मुझे लगता है कि न्यागार्ड और डाहल ऐसे थे जिन्होंने इसे इस तरह से रखा था, और मुझे लगता है कि वे इस बात पर ध्यान केंद्रित कर रहे थे कि समय के विकल्पों की तुलना में सिमुलेशन डिजाइन करने के बारे में सोचना कितना आसान था।

(...) लेकिन OOP का ध्यान व्यक्तिगत कक्षाओं और उनके पदानुक्रमों को डिजाइन करना है।

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

"ऑब्जेक्ट के सरलीकृत, आधुनिक परिभाषाओं और" ऑब्जेक्ट ओरिएंटेड "के लिए एक प्रस्ताव http://wcook.blogspot.com.br/2012/07/proposal-for-simplified-modern.html

इन समस्याओं को देखते हुए, यह कैसे / क्यों हुआ कि OOP करने का वर्तमान मुख्यधारा का तरीका इतना लोकप्रिय हो गया?

शायद यही कारण है कि QWERTY कीबोर्ड लोकप्रिय हो गए थे या उसी कारण DOS ऑपरेटिंग सिस्टम लोकप्रिय हो गया था। चीजें केवल अपने गुणों के बावजूद लोकप्रिय वाहनों पर सवारी करती हैं, और स्वयं लोकप्रिय हो जाती हैं। और कभी-कभी, किसी चीज़ के समान लेकिन बदतर संस्करणों को वास्तविक चीज़ मान लिया जाता है।

और क्या, अगर कुछ भी हो, तो इसका पता लगाने के लिए क्या किया जा सकता है?

एक बेहतर दृष्टिकोण का उपयोग करके एक कार्यक्रम लिखें। OO दृष्टिकोण का उपयोग करके एक ही कार्यक्रम लिखें। पहले वाले के पास हर पहलू में उत्तरार्द्ध की तुलना में बेहतर गुण हैं जो महत्वपूर्ण है (सिस्टम के गुणों और इंजीनियरिंग गुणों दोनों)। दिखाएँ कि कार्यक्रम चुना गया प्रासंगिक है और प्रस्तावित दृष्टिकोण अन्य प्रकार के कार्यक्रमों के लिए लागू होने पर गुणों की उच्च गुणवत्ता को बनाए रखता है। अपने विश्लेषण में कठोर रहें और आवश्यक होने पर सटीक और स्वीकृत परिभाषा का उपयोग करें।

अंत में, अपने निष्कर्ष हमारे साथ साझा करें।

Answer 21

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

विरासत और इंटरफ़ेस पदानुक्रम "चीजें" हैं जो उप-घटकों के रूप में वस्तुओं का उपयोग करती हैं। यह वस्तुओं का वर्णन करने का एक विशेष तरीका है, वस्तुओं की सामान्य समझ प्राप्त करने का तरीका नहीं है।

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

इसके विपरीत, एक वस्तु जो एक प्रक्रिया का प्रतिनिधित्व करती है, जैसे "एन्क्रिप्ट" या "संपीड़ित" या "सॉर्ट", एक "क्रिया" की तरह दिखता है।

कुछ वस्तुओं का उपयोग नाम के रूप में उनकी भूमिका के लिए किया जाता है, उदाहरण के लिए जावा में "स्थिर" फ़ंक्शन को रखने के लिए एक जगह।

मुझे इस तर्क से सहमत होने की इच्छा है कि जावा ऑब्जेक्ट विधि पर बहुत अधिक है, ऑब्जेक्ट पर प्रेषण के साथ। यह संभवतः इसलिए है क्योंकि मैं प्रेषण को नियंत्रित करने के लिए हास्केल के प्रकार की कक्षाएं पसंद करता हूं। यह एक प्रेषण सीमा है और जावा की एक विशेषता है, लेकिन अधिकांश भाषाएं, या यहां तक ​​कि अधिकांश ओओ लैंगगेज भी नहीं हैं।

Answer 22

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

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

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

यदि आप खराब लिखित प्रक्रियात्मक कोड के साथ ठीक से लिखे गए OO कोड की तुलना करते हैं, तो आप हमेशा गलत निष्कर्ष पर आएंगे। बहुत कम परियोजनाएं ऑब्जेक्ट ओरिएंटेड डिज़ाइन का वारंट करती हैं। यदि आप आईबीएम हैं और एक बड़ी परियोजना का प्रबंधन करते हैं जिसे कई डेवलपर्स द्वारा वर्षों तक बनाए रखा जाना चाहिए, तो ऑब्जेक्ट ओरिएंटेड के लिए जाएं। यदि आप एक क्लाइंट के लिए एक छोटा ब्लॉग या शॉपिंग वेबसाइट लिख रहे हैं, तो दो बार सोचें।

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

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