OOP वास्तविक दुनिया में प्रमुख प्रोग्रामिंग मॉडल है?

Question

वस्तुएं कभी नहीं? खैर, शायद ही कभी

एसीएम के संचार के दृश्य अनुभाग में, मुझे " ऑब्जेक्ट्स नेवर? वेल, हार्ड एवर " शीर्षक से एक दिलचस्प लेख मिला । यह वस्तुओं-प्रथम या वस्तुओं-देर की तुलना में एक मौलिक रूप से अलग परिप्रेक्ष्य है। वह "ऑब्जेक्ट्स-कभी नहीं" या शायद "ऑब्जेक्ट्स-ग्रेजुएट स्कूल" का सुझाव देता है।

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

जब विश्वविद्यालयों में कुछ प्रोफेसर ओओपी के लाभों के बारे में बात करना चाहते हैं, तो वे कोड-पुन: उपयोग के बारे में बात करते हैं। एक और उदाहरण के रूप में, फिर से, वह दावा करता है, वास्तविक दुनिया में यह वास्तविक मामला नहीं है। विश्वविद्यालयों में दावा किए जाने की तुलना में कोड का पुन: उपयोग कठिन है:

मेरा दावा है कि ओओपी का उपयोग उतना प्रचलित नहीं है, जितना कि ज्यादातर लोग मानते हैं, कि यह उतना सफल नहीं है जितना कि इसके प्रस्तावक दावा करते हैं, और इसलिए, कि सीएस पाठ्यक्रम में इसका केंद्रीय स्थान उचित नहीं है।

मेरे लिए यह जानना दिलचस्प है कि स्टैक-ओवरफ्लो में लोग इस बारे में कैसे सोचते हैं? क्या OOP प्रोग्रामर के दृष्टिकोण से प्रमुख प्रोग्रामिंग मॉडल है?

अगर मुझे सिर्फ एक दृष्टिकोण का चयन / सीखना / उपयोग करना चाहिए, तो क्या यह ओओपी है या नहीं? क्यों?

Comments

"70% प्रोग्रामिंग एंबेडेड सिस्टम के लिए किया जाता है"? क्या वह प्रति परियोजना, प्रति डेवलपर या प्रति LOC है? मुझे लगता है कि एक्सेल में "ऑल प्रोगामिंग्स" का 70% काम होता है। यहां तक ​​कि गैर-प्रोग्रामर प्रोग्राम स्प्रेडशीट भी।

— लेनिप्रोग्राम्स

@ Lenny222: यदि आप मेरा अनुमान चाहते हैं, तो यह प्रोग्राम की वितरित प्रतियों का 70% एम्बेडेड सॉफ़्टवेयर में है, या ऐसा कुछ है। अब, कुछ एम्बेडेड सामान C ++ में किया जाता है, और अक्सर एक हैक-डाउन संस्करण होता है जो C और ऑब्जेक्ट्स को छोड़ देता है, इसलिए यह तर्कहीन लगता है कि एम्बेडेड कभी ऑब्जेक्ट-ओरिएंटेड नहीं है।

— डेविड थॉर्नले

मुझे लगता है कि प्रमुख प्रोग्रामिंग मॉडल लंबे समय से है और कीचड़ की बड़ी गेंद होगी।

— whatsisname

वह लेख "कक्षाओं" और "सबसिस्टम" के बीच एक विचित्र अंतर बनाता है जिसे मैं दूर से भी नहीं समझता। यह इस बारे में बात करता है कि DiskBrake extends BrakeOOP एक कार के लिए कितना अच्छा है, क्योंकि "वास्तविक दुनिया में" यह संचार "नेटवर्क सिग्नल और बस प्रोटोकॉल" द्वारा लागू किया जाता है - क्या, पसंद है DiskBrake implements BrakeInterface? शायद यह मेरा अपना << 43 साल का अनुभव है, लेकिन मेरे लिए उदाहरण लेखक के दावे को पूरी तरह से विफल करते हैं।

— OJFord

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

— चार्ल्स सल्विया

Answer 1

एसीएम के संचार के दृश्य अनुभाग में

यदि आप व्यावहारिक प्रोग्रामिंग में रुचि रखते हैं , तो ACM और पसंद की कार्यवाही अंतिम स्रोत है जिसे आप पढ़ना चाहते हैं। ये अक्सर [छद्म] -वैज्ञानिक प्रकाशन हैं जिनका वास्तविक दुनिया में कोई अनुप्रयोग नहीं है। प्रचार के लिए लेखक द्वारा भीड़ से खुद को अलग करने और अपने स्वयं के व्यक्ति को बढ़ावा देने के लिए ये अक्सर अपरंपरागत राय हैं।

मेरा दावा है कि ओओपी का उपयोग उतना प्रचलित नहीं है, जितना कि ज्यादातर लोग मानते हैं, कि यह उतना सफल नहीं है जितना कि इसके प्रस्तावक दावा करते हैं, और इसलिए, कि सीएस पाठ्यक्रम में इसका केंद्रीय स्थान उचित नहीं है।

मैं आपकी बात से असहमत हूं। ओओपी व्यापक रूप से फैला हुआ है और ठीक काम करता है। संख्या के आधार पर OOP- आधारित परियोजनाओं ने अन्य रणनीतियों के साथ किए गए विकास को पार कर लिया है (चलो आधुनिक समय, 15-20 साल के बारे में बोलते हैं)।

हालाँकि OOP चांदी की गोली नहीं है। यह कुछ घटनाओं के लिए काम करता है, दूसरों के लिए काम नहीं करता है। किसी भी अन्य दृष्टिकोण की तरह।

लेकिन मुझे एक बात का उल्लेख करने की आवश्यकता है कि एक पाठ्यक्रम में विभिन्न दृष्टिकोणों के ज्ञान का संचार होना चाहिए। यदि यह OOP- आधारित है, तो यह गलत है। यदि यह FP- आधारित है, तो यह गलत है। यह उन सभी को कवर करना चाहिए या इस विषय को पूरी तरह से नहीं छूना चाहिए।

पुनश्च क्यों प्रमुख है और क्या नहीं है के बारे में परवाह है? बस वही लें जो परियोजना के लिए उपयुक्त है और संख्या को "शोधकर्ताओं" पर छोड़ दें।

Comments

वे कम्प्यूटिंग के क्षेत्रों में शोध पत्र हैं जो अभी मुख्यधारा बनने के लिए नहीं हैं। अकादमिया को वास्तविक दुनिया में फ़िल्टर करने में आमतौर पर कई साल लगते हैं, हालांकि यह नियमित रूप से होता है।

— परिक्रमा

@DeveloperArt: कृपया ध्यान दें कि पेपर लेखक को सॉफ्टवेयर विकास में 43 साल का अनुभव है!

— एहसान

एलन Kay एक टिप्पणी जोड़ता है, cacm.acm.org/mag पत्रिकाओं /2010/9 / … पर - 'इसके विपरीत, मैंने कभी नहीं माना है कि ज्यादातर सिस्टम जो खुद को "ऑब्जेक्ट-ओरिएंटेड" कहते हैं, वे मेरे अर्थ के करीब हैं जब मैं मूल रूप से गढ़ा था अवधि।' - जो मेरी पोस्ट के लिए स्पर्शरेखा में बाँधता है - "OO? किसका OO?"

— फ्रैंक शियरर

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

— फ्रैंक शीयर

-1 कंप्यूटर विज्ञान शोधकर्ताओं को डराने वाले उद्धरण की आवश्यकता है? एसीएम छद्म विज्ञान प्रकाशित करता है? गंभीरता से?

— जेपरेट

Answer 2

यदि ओओपी एकमात्र प्रतिमान है जिसे आप जानते हैं, शायद आपको अधिक सीखना चाहिए। लेकिन वास्तव में, OOP का वास्तव में क्या मतलब है? क्या इसका मतलब जावा या सी ++ है? क्या इसका मतलब स्मॉलटाक है? क्या इसका मतलब है कि निपटान मूल्य स्लॉट और क्लोजर? (हाय, स्कीम!) क्या इसका मतलब संदेश भेजना है? (हाय, एरलांग!)

संक्षेप में, यह एक निर्बाध प्रश्न लगता है। "क्या OO उपयोगी है ?" एक बेहतर सवाल है। और, ठीक है, ऐसा लगता है। (निश्चित रूप से यह मेरे लिए है।)

Comments

+1 मुझे संदेह है कि व्यवहार में OOP का मतलब "कोड लिखने का एक अच्छा तरीका है जो वस्तुओं का उपयोग करने वाले" के अलावा कुछ भी नहीं है।

— लैरी कोलमैन

संदर्भित लेख को नहीं लगता कि एक ओओ भाषा का उपयोग ओओ उपयोग की गारंटी है और सवाल है कि क्या अन्य इंजीनियरिंग विषयों में मौजूद नहीं होने के बाद से प्रतिमान होना चाहिए।

— जेएफओ

शायद लेखक को विलियम कुक और मैथियास फेलिसन को पढ़ना चाहिए, जो बहुत समय बिताने के बारे में बात कर रहे हैं जो प्रोग्रामिंग में समान नहीं है।

— फ्रैंक शियरर

Answer 3

जहां सभी डेवलपर्स उन "70% प्रोग्रामिंग" कर रहे हैं? मुझे पता है कि सभी डेवलपर्स में से 1% से कम एंबेडेड सिस्टम पर काम कर रहे हैं।

तो, हमारे पास 3 विकल्प हैं:

1. मैं अद्वितीय हूं और आपके सभी दोस्त वास्तव में एम्बेडेड प्रोग्रामिंग करते हैं
2. वहाँ एक तहखाने में बंद डेवलपर्स की सेनाएँ हैं जो 70% कर रहे हैं
3. यह आँकड़ा बना हुआ है और लेख बकवास है

जब तक मुझे कुछ सबूत नहीं दिखते हैं कि विकल्प 1 या 2 वास्तव में सच है मैं विकल्प 3 के साथ जा रहा हूं।

(BTW, मैं आधुनिक मोबाइल विकास एम्बेडेड प्रोग्रामिंग पर विचार नहीं करता, और मोबाइल विकास अक्सर OO होता है, सभी Apple आपको iPhone के लिए विकसित करने के लिए * उद्देश्य * C का उपयोग करने के लिए मजबूर करता है)

Comments

एफडब्ल्यूआईडब्ल्यू, मुझे कुछ सेकंड लगे, और "प्रोग्रामिंग के 70%" के लिए आधा दर्जन संभव उपायों के साथ आया। लेखक ने सातवें का उपयोग किया है। (इसके अलावा, एम्बेडेड प्रोग्रामर बाहर हैं, वे बस एक ही स्थानों पर बाहर नहीं घूमते हैं, और अक्सर खुद को इलेक्ट्रिकल इंजीनियरों या प्रोग्रामर के बजाय ऐसा कुछ मानते हैं।)

— डेविड थॉर्नले

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

— Nir

मैं एक एम्बेडेड लड़का हूं। मैंने कई रिपोर्ट्स देखी हैं कि उत्पादित / शिप किए गए लगभग 99% प्रोसेसर एम्बेडेड सिस्टम के लिए हैं (यदि यह वास्तव में आवश्यक है तो मैं वापस आ सकता हूं और रिपोर्ट का हवाला दे सकता हूं)। ऐसा कहने के बाद, मुझे यकीन है कि लगभग 70% सभी प्रोग्रामिंग एम्बेडेड सिस्टम के लिए किया जाता है। मुझे लगता है कि शिप किए गए सभी प्रोसेसर का 50% 4-बिट और 8-बिट है, लेकिन ये संभवतः सभी प्रोग्रामिंग का 0.1% (या उससे कम) बनाते हैं। जैसा कि डेविड ने कहा, "70% प्रोग्रामिंग" के साथ आने के कई तरीके हैं। मुझे आश्चर्य नहीं होगा अगर संख्या 20-25% थी।

— रेडियन डेस

"आंकड़ों के साथ झूठ बोलना अभी भी झूठ है" के लिए +1; यह सच है, इतना सच है ...

— डोनाल्ड फैलो

Answer 4

मेरे पास इसका पालन करने के लिए तथ्य नहीं हैं, लेकिन OOP प्रमुख प्रोग्रामिंग मॉडल नहीं है। बस उन सभी इन-हाउस ऐप्स की कल्पना करें जो किसी व्यक्ति द्वारा विकसित किए गए थे, जिन्होंने विज़ुअल बेसिक कोर्स किया था, या एक्सेल में कुछ मैक्रो प्रोग्रामिंग किया था।

बहुत सारे अनुप्रयोग केवल अनिवार्य प्रोग्रामिंग कर रहे हैं जहां सभी तर्क एक ही वर्ग या दृश्य में ढेर हो गए हैं। यह संभवतः सभी उद्यमों में चलने वाले आंतरिक सरल अनुप्रयोगों का विशाल हिस्सा है।

इसमें कुछ भी गलत नहीं है, एक ही समस्या को हल करने के कई तरीके हैं। दूसरों की तुलना में कुछ बेहतर अनुकूल।

जैसा कि आपने बताया, OOP सभी परिदृश्यों के लिए उपयोगी नहीं है। अन्य मॉडल भी हैं।

Comments

तो फिर, वहाँ सवाल हो सकता है कि प्रमुख मॉडल के रूप में वर्णित करने के लिए क्या आवश्यक है। क्या यह "मॉडल X के साथ विकसित की गई एप्लिकेशन की राशि है" या क्या यह "मॉडल X के साथ विकसित कोड की मात्रा" है? किसी भी तरह से मुझे अभी भी लगता है कि ओओपी प्रमुख मॉडल नहीं होगा।

— मोर्टन

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

— परिक्रमा

Answer 5

OOP प्रमुख प्रोग्रामिंग मॉडल अप्रासंगिक है या नहीं, बस अलग-अलग मॉडल अलग-अलग मामलों में फिट होते हैं।

कोई चांदी की गोली नहीं है।

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

लेकिन, वास्तव में मेरे उत्तर की बात यह है, यह बताने के लिए क्या अच्छा है कि एक मॉडल या कोई अन्य प्रमुख है या नहीं, क्या तब नेत्रहीन इसका उपयोग करने के लिए अच्छा तर्क है? बेशक, यह नहीं है।

Comments

यदि कई लोग एक मॉडल का उपयोग करने का दावा करते हैं और ऐसा नहीं करते हैं, तो यह एक मुद्दा है। यह प्रश्न प्रचलित जैसा है क्योंकि यह प्रकट होता है और प्रभावी / बेहतर होने के बारे में नहीं है।

— जेएफओ

Answer 6

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

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

यह पूछने के लिए भी सार्थक नहीं है कि क्या ओओ उपयोगी है जब तक कि ऊपर दिए गए सवालों का जवाब नहीं दिया जाता है, अकेले हावी होने दें।

Answer 7

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

PS2: अगर मुझे केवल एक दृष्टिकोण का चयन / सीखना / उपयोग करना चाहिए, तो क्या यह OOP है या नहीं? क्यों?

यदि आप केवल एक सीखने जा रहे हैं तो आपको एक अलग क्षेत्र चुनना चाहिए।

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

Comments

यदि आप एक दृष्टिकोण सीखने की योजना बनाते हैं, तो एक अलग क्षेत्र चुनने की टिप्पणी के लिए +1। यह पागलपन है।

— Mat Nadrofsky

Answer 8

OOP निश्चित रूप से वास्तविक दुनिया में अधिक प्रभावी प्रोग्रामिंग मॉडल में से एक है।

चलो इसका सामना करते हैं, यहां तक ​​कि जो लोग डिजिटल हार्डवेयर डिजाइन करते हैं, चिप डिजाइनर खुद, सिस्टमविरल और सिस्टमसी की जोड़ी के लिए एक संक्रमण बना रहे हैं। ये ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग लैंग्वेज हैं।

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

Answer 9

मैं कहता हूँ नहीं।

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

OO पूरी तरह से स्व-निहित वस्तुओं के बीच से गुजरने वाले संदेश के बारे में माना जाता है, और हम इसे आज के कोड में देखते हैं, लेकिन बहुत बड़े स्तर पर - अर्थात हम इन वस्तुओं को dll या असेंबली या COM ऑब्जेक्ट के रूप में कार्यान्वित देखते हैं। 'अवयव' मैंने उनके रूप में वर्णित सुना है।

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

Answer 10

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

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

Answer 11

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

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