क्या OO- प्रोग्रामिंग वास्तव में उतना ही महत्वपूर्ण है जितना कि कंपनियों को काम पर रखना? [बन्द है]

55

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

क्या OO वास्तव में महत्वपूर्ण है? मैं भी सी में एक प्रोग्रामिंग नौकरी के लिए एक साक्षात्कार था और आधा साक्षात्कार ऊ था।

वास्तविक दुनिया में, वास्तविक अनुप्रयोगों का विकास, ऑब्जेक्ट ओरिएंटेशन लगभग हमेशा उपयोग किया जाता है? क्या बहुरूपता जैसी प्रमुख विशेषताएं A LOT का उपयोग किया जाता है?

मुझे लगता है कि मेरा प्रश्न मेरी कमजोरियों में से एक है। यद्यपि मुझे OO के बारे में पता है, लेकिन मैं इसे अपने कार्यक्रमों में शामिल करने में सक्षम नहीं लगता।

object-oriented inheritance polymorphism

— एले
स्रोत

3

हालांकि सब कुछ नहीं खोया है। पहचानना एक समस्या है इसे सही करने के लिए पहला कदम है :)

— ईलिसियम जूल

37

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

— मच

1

हाँ यही है। ईमानदारी से।

— क्वांट_देव

6

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

— जोहल

1

हो हाँ वह कर सकता है। और मेरा विश्वास करो, यदि आपके पास OOP की वही समझ है जो आपके पास तब थी जब आपकी मास्टर डिग्री मिली थी, तो आपको संभवतः OOP के बारे में कुछ भी पता नहीं है।

— डेडलिंक

84

ओओपी एक प्रतिमान है जो आपके कार्यक्रम को बनाए रखने / समझने में असंभव होने के बिना बढ़ने की अनुमति देता है। यह एक ऐसा बिंदु है जो छात्रों को लगभग कभी नहीं मिलता है क्योंकि वे केवल दो सप्ताह की अवधि से लेकर दो महीने तक की सबसे छोटी परियोजनाएं करते हैं।

यह छोटी अवधि ओओपी के उद्देश्य को स्पष्ट करने के लिए पर्याप्त नहीं है, खासकर अगर परियोजना के लोग शुरुआती हैं। लेकिन बड़ी परियोजनाओं के लिए कुछ तौर-तरीकों से चिपके रहना महत्वपूर्ण है, मैं कहूंगा कि> कोड की 50,000 लाइनें। OOP इसका एकमात्र समाधान नहीं है, लेकिन यह उद्योग में सबसे अधिक उपयोग किया जाता है।

यही कारण है कि लोग आपको OOP जानना चाहते हैं।

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

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

यदि आप अभी तक "OOP" नहीं सोचते हैं, तो मैं आपको सुझाव दूंगा कि आप इसके बारे में कुछ किताबें पढ़ें और कंपनी में आवेदन करें जिसमें वास्तव में बड़ी परियोजनाएं नहीं हैं; अपने नियोक्ता के लिए उपयोगी काम करते हुए ओओपी के लिए अभ्यस्त होने के लिए (और जब तक वह आपको अपना वेतन दे रहा है, यह आपके लिए भी उपयोगी होगा)।

संपादित करें: हा, और मैं जोड़ूंगा कि मैंने पहले ही सी में ओओपी कोड लिखा था, भले ही यह सी का सबसे आम उपयोग नहीं है, यह मजबूत ज्ञान के साथ संभव है। आपको बस मैन्युअल रूप से vtables का निर्माण करना होगा।

और OOP तकनीक के पीछे, कुछ छिपा हुआ है: सॉफ्टवेयर डिज़ाइन। सॉफ्टवेयर डिजाइन, वास्तव में सी में किसी भी अन्य भाषाओं में सहायक है। कई रिक्रूटर्स आपके सॉफ़्टवेयर डिज़ाइन दक्षताओं का परीक्षण करेंगे, और OOP प्रश्न इसके लिए अच्छे हैं, लेकिन OOP मुख्य चीज़ नहीं है जिसका परीक्षण यहाँ किया जा रहा है। यही कारण है कि आपके पास सी नौकरी के लिए भी वे प्रश्न हैं।

— डेडलिंक
स्रोत

2

और हाँ .. जैसा कि मैंने पिछली टिप्पणी में लिखा था, मुझे लगता है कि मुझे OOP की सराहना करने के लिए एक बड़ी परियोजना पर काम करने की आवश्यकता है :)।

— एले

5

आपको ओटीपी होने के लिए vtables की आवश्यकता नहीं है। बस का उपयोग करके structऔर C में उस संरचना पर काम करने वाले कार्य OOP हैं।

— eda-qa मोर्ट-ओर-वाई

2

@ eda-qa mort-ora-y स्ट्रक्चर आपको ओओपी फ़ंक्शनैलिटी नहीं देता है। बहुरूपता? इनहेरिटेंस? क्या इसका मतलब आपके लिए कुछ है? ठीक है, तो, कैसे आप एक व्यावहारिक रूप से आभासी कार्यों को लागू करते हैं?

— deadalnix

2

@deadalnix: आप उन्हें उसी तरह कार्यान्वित करते हैं। .NET और Java एकाधिक वंशानुक्रम करते हैं। आपको पता होना चाहिए कि पहले C ++ कंपाइलर बिल्कुल भी कंपाइलर नहीं थे, वे अनुवादक थे जिन्होंने C ++ कोड लिया और इसे C कोड में बदल दिया जो C कंपाइलर को पास किया गया था। Google "CFront"।

— gbjbaanb

3

जावा और नेट एक से अधिक अमानवीयता नहीं करता है। और हाँ, C ++, C में स्वचालित रूप से अनुवाद योग्य है, लेकिन यह केवल पूरी तरह से असंबंधी या नहीं का उपयोग करने की समस्या से असंबंधित है। वास्तव में आपके पास है: आप आभासी कार्यों को बिना किसी व्यवहार्यता के लागू नहीं कर सकते।

— deadalnix

38

कंप्यूटर प्रोग्रामिंग के साथ भारी समस्या जटिलता को संभाल रही है, और आधुनिक कार्यक्रम वास्तव में बहुत जटिल हो सकते हैं, और यह केवल वृद्धि के लिए प्रकट होता है।

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

उदाहरण:

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

दूसरे शब्दों में, बहुत सारे ट्रिक्स जानना आवश्यक है यदि आप सॉफ्टवेयर के गैर-तुच्छ टुकड़ों पर काम करना चाहते हैं, तो अकेले या दूसरों के साथ (सबसे अधिक संभावना है)।

— उपयोगकर्ता 1249 को प्रकट करता है
स्रोत

7

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

— जोहल

3

यहां तक कि खुद को जानने वाला भी एक कठिन-सेट आवश्यकता नहीं है, कुछ क्षेत्रों (सी या हास्केल) में प्रक्रियात्मक और कार्यात्मक प्रतिमान पर्याप्त हैं। आपको अभी भी मॉडर्लाइज़ेशन और एपीआई डिज़ाइन सीखने की ज़रूरत है।

— रायनोस

@ रेयानोस, सी में आपके पास फ़ंक्शन पॉइंटर्स हैं जो आपको स्पष्ट रूप से करने की अनुमति देते हैं कि ओओ आंतरिक रूप से क्या करता है। इसी तरह हास्केल पैटर्न का उपयोग करता है जो स्पष्ट रूप से वह करता है जो संकलक जावा में करता है।

@ThorbjornRavnAndersen यह OO शैली C और हास्केल लिखने के लिए थोड़ा आला है। मैं सिर्फ यह कह रहा हूं कि पुन: उपयोग कोड को प्रक्रियात्मक और कार्यात्मक प्रतिमान में किया जा सकता है।

— Raynos

3

@mathepic मैं यह नहीं कह रहा हूँ कि किसी को OO हैस्केल (या चाहे वह मौजूद हो) लिखना चाहिए। मैं कह रहा था कि आपको ऊ जानने की जरूरत नहीं है। जटिलता (एफपी) को संभालने के अन्य तरीके हैं

— रेयानोस

14

हां, मुख्य रूप से क्योंकि शायद व्यावसायिक विकास (जावा और .NET) में उपयोग किए जाने वाले दो सबसे लोकप्रिय विकास मंच ऑब्जेक्ट ओरिएंटेड हैं और इसका मतलब है कि, ओओ का बहुत अधिक उपयोग किया जाता है (जिसमें बहुरूपता, विरासत और अन्य सब कुछ शामिल है)।

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

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

— जॉन हॉपकिंस
स्रोत

2

आपको ओओ के बारे में कंपनियों को 'परवाह नहीं' करने के लिए कॉल करना होगा - अच्छी कंपनियां पुन: प्रयोज्य / बनाए रखने योग्य कोडबेस के बारे में परवाह करती हैं, और ओओ पैटर्न ऐसा करने के लिए मान्यता प्राप्त तरीका है।

— होरसकॉल

1

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

— जॉन हॉपकिंस

खैर, कोबोल OO से पहले के आसपास था। मैं स्मॉलटाक पर टिप्पणी नहीं कर सकता, लेकिन मुझे लगता है कि अगर इसे नहीं उठाया गया था, तो इसके साथ समस्याएँ रही होंगी।

— होरसकॉल

1

@ हॉर्सकॉल - वास्तव में कोबोल और ओओ एक ही समय (50 के दशक के अंत तक) के आसपास अस्तित्व में आए, लेकिन भले ही हम यह मान लें कि ओओ ने 70 या 1980 के दशक तक पकड़ना शुरू नहीं किया था (यदि आप सी ++ की प्रतीक्षा करते हैं) यदि यह है कि कंपनियों के लिए एक बड़ी बात यह है कि यह 90 के दशक के अंत तक (जावा के साथ) क्यों नहीं पकड़ा गया। इसका उत्तर यह है कि ओओ के अलावा एक अनुरक्षण कोड आधार होने के तरीके हैं - कंपनियां बनाए रखने योग्य कोड की परवाह करती हैं लेकिन एक बिल्ली की त्वचा के लिए एक से अधिक तरीके हैं और ओओ एकमात्र समाधान नहीं है।

— जॉन हॉपकिंस

प्लेटफार्मों को खुद को OO कहना अजीब है। Clojure OO नहीं है। स्कैला में कुछ ओओ तत्व हैं जो मुझे लगता है, लेकिन एक कार्यात्मक तरीके से सबसे अच्छा उपयोग किया जाता है। F # एक ही तरह का सौदा है। F # में OO कोड लिखना सिर्फ गंदा है।

— सारा

7

वास्तविक जीवन में, वास्तविक जीवन प्रोग्रामिंग सिद्धांत से अलग है।

हां, यदि आप OO प्रतिमान को पॉलिश करते हैं और हमेशा अपने दिमाग के पीछे रखते हैं, तो आप कोड लिखने में बेहतर कर सकते हैं जो प्रबंधनीय, समझने योग्य और आसानी से एक्स्टेंसिबल है।

दुर्भाग्य से, वास्तविक दुनिया में यह है:

परियोजना समय दबाव
प्रक्रियात्मक रूप से उन्मुख टीम के सदस्य
क्रॉस-स्थित टीम, कई विक्रेता
विरासत कोड जो भी कोई अभिविन्यास नहीं है
जब तक यह काम करता है, कोड कैसे लिखा जाता है, इसके बारे में कुछ देखभाल
यहां तक कि अगर कोड काम नहीं करता है, तो प्रेरणा इसे ठीक करना है, न कि "ओओ"
मॉड्यूल, प्लेटफ़ॉर्म सीमाएँ, चौखटे जो आपको अच्छा OO करने की अनुमति नहीं देते हैं

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

रियल-लाइफ OO धीमा आता है। यह मदद करता है यदि आप पढ़ते रहते हैं और समय के साथ इसे सुधारते रहते हैं।

— अमोल
स्रोत

6

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

— डेविड हास
स्रोत

खुशी है कि मैं अकेला नहीं हूँ! धन्यवाद .. मैं उस पुस्तक पर एक नज़र डालूँगा :)।

— एले

6

यहां तक कि सी में कुछ नौकरियों के लिए, आपको ऑब्जेक्ट ओरिएंटेड डिज़ाइन (और शायद इससे बेहतर हो सकता है कि आपके कंपाइलर ने आपके लिए ऐसा किया हो), जैसा कि लिनक्स कर्नेल में ऑब्जेक्ट-ओरिएंटेड डिज़ाइन पर लेखों की हालिया श्रृंखला द्वारा किया गया है। ( भाग 1 , भाग 2 )

GTK + ऑब्जेक्ट-ओरिएंटेड डिज़ाइन पैटर्न का भी बहुत उपयोग करता है।

— केन ब्लूम
स्रोत

4

मुझे इस धारणा के साथ कुछ असहमति व्यक्त करनी होगी कि OO सब कुछ है - एक कह सकता है कि OO आपको शहरों का निर्माण करने की अनुमति देता है, लेकिन प्रक्रियात्मक कार्यक्रम ईंटें हैं।

एक सादृश्य के रूप में मेरा जवाब देने के लिए, सामान्य वस्तुओं की आवश्यकता होती है, सैनिक को प्रक्रियात्मक की आवश्यकता होती है। एक बार जब आप OO में पर्याप्त ड्रिल कर लेते हैं, तो आपको प्रक्रियाएँ मिल जाती हैं, और यदि वह आपकी विशेषज्ञता है और आप काफी अच्छे हैं, तो OO के बारे में चिंता न करें, क्योंकि किसी के लिए यह OO शतरंज गेम कोड लिखना काफी आसान है:

-findBestMove
-makeBestMove
-waitForPlayerInput

लेकिन फिर किसी को-बैकस्टबस्ट कोड कोड लिखना होगा और आप यह सुनिश्चित कर सकते हैं कि यह सिर्फ यही नहीं है:

foreach $move (@moves){
    $bestMove = ($move > $bestMove ? $move : $bestMove)
}
return $bestMove

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

— एलेक्स
स्रोत

4

जॉन हॉपकिंस ने लिखा है:

हां, मुख्य रूप से क्योंकि शायद व्यावसायिक विकास (जावा और .NET) में उपयोग किए जाने वाले दो सबसे लोकप्रिय विकास मंच ऑब्जेक्ट ओरिएंटेड हैं और इसका मतलब है कि, ओओ का बहुत अधिक उपयोग किया जाता है (जिसमें बहुरूपता, विरासत और अन्य सब कुछ शामिल है)।

जो बहुत कुछ है जो मैं कहने जा रहा था, लेकिन यह सिर्फ जावा और .Net नहीं है, C ++ हर जगह है, ऑब्जेक्टिव-सी OSX पर है, सभी शांत बच्चे रूबी या पायथन कर रहे हैं, और ये सभी चीजें और बहुत सारे अधिक वस्तु अभिविन्यास पर ध्यान केंद्रित किया है। बहुत सी नई भाषाएँ बहुपद हैं, इसलिए F # जैसा कुछ मुख्य रूप से एक कार्यात्मक भाषा है, लेकिन यह वस्तु अभिविन्यास का भी समर्थन करता है। यह हर जगह है, और कम से कम कुछ समझ होना बहुत उपयोगी है। हालांकि इसके बारे में बहुत अधिक झल्लाहट मत करो, सिर्फ विश्वविद्यालय के पाठ्यक्रम पूरे होने का मतलब है कि आप वास्तविक दुनिया में कोड विकसित करने के बारे में सीखना शुरू करने के लिए तैयार हैं :)

— eviltobz
स्रोत

3

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

BTW, C ++ ने OO का एक बड़ा और बदसूरत गड़बड़ कर दिया है, जबकि Objective C इसे सही करता है।

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

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

— पुनर्जीवित किया
स्रोत

C ++ एक बहु-प्रतिमान भाषा है लेकिन OO को बहुत अच्छी तरह से संभालती है .. नहीं?

— निक्को

1

मैं कहूंगा कि C ++ आपको एक विशाल बदसूरत गड़बड़ करने की क्षमता देता है। अगर सही तरीके से किया जाए तो इसकी सुंदरता इसकी सादगी है।

— मार्टिन

मूल बातें छोड़ना हमेशा भारी गड़बड़ देता है। C ++ के पास बस बड़ी मात्रा में मूल बातें हैं जिन्हें आपको समझने की आवश्यकता है। यही कारण है कि बड़े कार्यक्रमों के लिए C ++ का उपयोग करना संभव है। यह जरुरी है।

— tp1

@Ponk: BTW, C ++ ने OO की एक बड़ी और बदसूरत गड़बड़ कर दी है, जबकि Objective C इसे सही करता है। - मैंने ऑब्जेक्टिव सी की कोशिश नहीं की है, इसलिए मेरे पास आपको संदेह करने का कोई कारण नहीं है, लेकिन मैं इसके लिए अधिक गहन और ठोस तर्क कहां पा सकता हूं?

— जिम जी।

3

OOP सीखना सॉफ्टवेयर डेवलपमेंट सीखने जितना उपयोगी नहीं है। कोड पूरा 2 पढ़ें ।

यकीन है कि यह एक उपयोगी उपकरण है, लेकिन OOP वास्तव में छोटा है। सामान्य तौर पर जब कंपनियां और रिक्रूटर्स "ओओपी" कहते हैं, तो उनका मतलब "सॉफ्टवेयर डेवलपमेंट" होता है। यह एक सामान्य शब्द के रूप में इस्तेमाल किया जा रहा है।

रियल रिक्रूटर्स सॉफ्टवेयर के विकास और "OOP 'में" 3 साल का मिलान "टिकबॉक्स को जानने के बीच का अंतर बताएंगे।

— Raynos
स्रोत

हां, इस संदर्भ में ओओपी जीयूआई की तरह ही है, जैसे "आपको इस भूमिका के लिए 5 साल के जीयूआई अनुभव की आवश्यकता है"।

— gbjbaanb

1

उत्तर हाँ है, जैसा कि कई अन्य ने नोट किया है।

लेकिन, अगर आप गैर-ओओ प्रक्रियात्मक स्पेगेटी कोड के ढेर पर काम करना चाहते हैं, तो आप यह पता लगा सकते हैं कि वहाँ भी। मुझे लगता है कि आप OO के काम को पसंद करेंगे।

EDIT: बंदूकधारियों के उन्माद और हास्य की भावना के मेरे मामले को माफ कर दो। जैसा कि रेन्नोस ने कहा, सिर्फ इसलिए कि OO का मतलब यह नहीं है कि यह अच्छा है। OO का उचित अनुप्रयोग वास्तविक कार्य और विचार लेता है; इसका केवल उदाहरण होने का यह मतलब नहीं है कि कोई ऐप अच्छी तरह से बना है। और इसके विपरीत, मुझे यकीन है कि वहाँ अच्छी तरह से लिखित प्रक्रियात्मक कोड है। 90 और 2000 के माध्यम से कॉरपोरेट आईटी की दुकानों में मेरा अनुभव रहा है कि बहुत बुरा कोड लिखा गया था और शायद अभी भी मौजूद है। लेकिन ओपी के सवाल के करीब, मैंने देखा है कि होशियार डेवलपर्स, जब मौका दिया जाता है, तो और अधिक ओओ सिस्टम पर चला जाता है।

— बर्नार्ड डाय को दर्शाता है
स्रोत

3

गैर-ओओ कोड लागू करने के लिए -1 स्पेगेटी है। और वह OO काला जादू करके अच्छा "स्पेगेटी नहीं" बनाता है।

— रायनोस

@ रेयानोस यह एक उचित बिंदु है। और सिर्फ इसलिए कि कुछ OO का उपयोग नहीं करता है इसका मतलब यह बुरा नहीं है। मैं संपादित करूंगा।

— बर्नार्ड डाय

यह भी न केवल एक प्रक्रियात्मक बनाम प्रक्रियात्मक / ओओपी है, बल्कि कार्यात्मक प्रतिमान भी है।

— वैकल्पिक

मैंने un-maintainable OO ऐप्स पर काम किया है, जहाँ ऑब्जेक्ट्स कंफ़ेद्दी की तरह बिखरे हुए थे। OOP एक जादू की गोली नहीं है, यह आपके कोड को व्यवस्थित करने का सिर्फ एक अधिक परिभाषित तरीका है।

— gbjbaanb

2

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

— बर्नार्ड डाय

1

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

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

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

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

वर्तमान में मैं एक ऐसी कंपनी में काम कर रहा हूँ जहाँ कोई भी डेवलपर्स कभी भी OO को समझने की कोशिश नहीं करता है। यह व्यक्त करना कठिन है कि यह कितना निराशाजनक है। मुझे अपने ग्रीप कौशल में सुधार करना होगा, वास्तव में मेरे पास चयनित पाठ पर एक grep करने के लिए मेरे F12 कुंजी को असाइन किए गए HotScripts मैक्रो हैं। मैं अन्य निराशाओं को छोड़ दूँगा ...

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

लंबे उत्तर के लिए क्षमा करें, लेकिन मैंने आपके प्रश्न के अधिकांश दायरे को कवर करने की कोशिश की है :-)

— लुइस सोमरस
स्रोत

आपकी कहानियों के लिए बहुत-बहुत धन्यवाद .. मुझे उन्हें पढ़कर बहुत अच्छा लगा! वर्तमान में मैं एक C ++ प्रोजेक्ट पर काम कर रहा हूं और मैं इस अवसर का उपयोग संभावित तरीकों के बारे में सोचने के लिए कर रहा हूं जो मैं OO तकनीकों का उपयोग कर सकता हूं। यह इस समय अच्छा चल रहा है :)। आप जवाब के लिए +1। धन्यवाद।

— शराब

1

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

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

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

उस ने कहा, उन सिद्धांतों को केवल ओओपी में नहीं पाया जाता है (यह गणना सिद्धांत मान्य है, उन परिणामों पर आने के लिए अनंत संभव तरीके हैं)।

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

OOP के लिए पहले एक " भाषा सुविधा " के रूप में नहीं, बल्कि एक " कॉमन लेक्सिकॉन " के रूप में सोचें, जो सॉफ्टवेयर इंजीनियरों को सॉफ्टवेयर डिजाइन के लिए दृष्टिकोण देता है।

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

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

ओओपी भाषाओं में कैसे फिट बैठता है यह इस बात पर निर्भर करता है कि भाषा डिजाइनर अपने निर्माण में ओओपी सिद्धांत की व्याख्या कैसे करते हैं।

तो C ++ में "एनकैप्सुलेशन" "निजी सदस्य" (और "कैप्सूल" एक वर्ग बन जाता है), "प्रतिस्थापन" आभासी कार्यों को ओवरराइड या टेम्पलेट पैराड्राइज़ेशन / विशेषज्ञता आदि हो जाता है, जबकि डी में एक कैप्सूल "मॉड्यूल" (और प्रतिस्थापन) हो जाता है। कक्षाओं आदि के माध्यम से), इस प्रकार निश्चित प्रतिमान या पैटर्न किसी दिए गए भाषा में सीधे उपलब्ध है और किसी और में नहीं।

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

— एमिलियो गरवाग्लिया
स्रोत

0

ऑब्जेक्ट ओरिएंटेड भाषा आपको अपने कोड में ऑब्जेक्ट ओरिएंटेड डिज़ाइन रखने में मदद करती है, जो अच्छा है। लेकिन यह भी सच है कि इस तरह के डिज़ाइन को किसी भी अन्य प्रतिमान भाषा के साथ प्राप्त किया जा सकता है: ओओ-भाषाओं की लोकप्रियता (विशेषकर कंपनियों के बीच) का कारण संभवतः जावा और सी # की व्यावसायिक सफलता में है।

अगर मिस्टर गेट्स ने अपनी कंपनी शुरू कर दी होती, तो शायद हम नौकरी के लिए आवेदन करने से पहले SCHEME का अध्ययन करते।

— लोरेंजो स्टेला
स्रोत

स्कीम उसी वर्ष प्रदर्शित हुई जैसा कि माइक्रोसॉफ्ट ने किया था (हालांकि उससे पहले निश्चित रूप से अन्य एलआईएसपी थे)। इसके अलावा, जावा और सी # ने अपनी सफलता का श्रेय एलन के, विशेष रूप से स्मॉलटाक और सिमुला को दिया, साथ ही साथ C ++ की सफलता को भी माना।

— जेसनट्रू जूल

0

संक्षिप्त उत्तर हां है

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

— V4Vendetta
स्रोत

0

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

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

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

यदि विरासत और बहुरूपता कंपनी के लिए महत्वपूर्ण नहीं हैं , तो आपको अभी भी OO प्रश्न मिलने की संभावना है क्योंकि:

आपका साक्षात्कार एक एचआर व्यक्ति द्वारा किया जाता है, जो प्रोग्रामिंग के बारे में कुछ नहीं जानता है और एक चेकलिस्ट से प्रश्न पूछ रहा है। क्या आपके पास 3 साल का एक्स है, क्या आप मल्टीटास्क करते हैं, आदि।
आपको एक इंजीनियर द्वारा साक्षात्कार दिया जाता है जो यह सुनिश्चित करना चाहता है कि आप एक चट्टान के नीचे नहीं रह रहे हैं। OO लिंगुआ फ़्रैंका है, इसलिए आपसे इसके बारे में कुछ सरसरी सवाल पूछे जाएंगे।
आप एक इंजीनियर द्वारा साक्षात्कार कर रहे हैं जो साक्षात्कार में बहुत माहिर नहीं है। सामान्य तौर पर, इंजीनियरों को ट्रिविया और जटिलता पसंद होती है, इसलिए आपको बहुरूपता, वंशानुक्रम और GoF डिज़ाइन पैटर्न के बारे में बहुत सारे प्रश्न मिलेंगे क्योंकि ये बातें आपके साक्षात्कार करने वाले व्यक्ति के लिए दिलचस्प हैं।

— डान
स्रोत

डाउनवोट क्यों?

— डैन

-1

एक शब्द "हां" में।

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

— बाइनरी वॉरियर
स्रोत